HLL Implementation Details

The National Marine Fisheries Service Policy Directive 32-110, "Use and Implementation of Electronic Signatures" outlines the following requirements for an approved electronic signature system:

1. Technical non-repudiation services
2. Legally binding the electronic transaction to an entity
3. Providing chain of custody audit trails
4. Providing an electronic receipt or acknowledgment of a successful submission
5. Collecting only necessary information in the electronic signature authentication process
6. Create a long-term retention and access policy
7. Periodic review and re-evaluation of the electronic signature process

This sections documents design details that address these requirements.

Binding the Transaction to an Entity and Non-repudiation

Requirements 1 and 2 above are addressed in the design of three component parts of the system:

• identity assertion, person proofing, and registration
• terms and conditions and signing ceremony
• document binding and document integrity

The Hawaii Longline Logbook E-signature Evaluation has concluded that OMB Assurance Level 2 (confidence exists in the asserted identity) was appropriate for the Hawaii Longline Logbook.  This was a considered decision justified by low likelyhood of occurrence, low and moderate impact of harm, and multiple and strong mitigating controls, including: multiple and sometimes counter-balancing sources of information; permitted entities with an ongoing trusted relationship with NMFS; a rigorous certification process for e-logbook applications; and unique identifiers on each e-logbook submission.  Note that the identity is established from association with a fishing permit holder, and not solely through the registration to submit logbooks electronically.

The proposed identity assertion, person proofing, and registration starts with a permit holder completing a NMFS electronic logbook agreement, establishing a linkage between the permit, the permit holder, and the fishing vessel operator who is authorized to submit electronic logbooks for that permit. more?_..._ (See Identity Assertion, Person Proofing and Registration for a broader discussion of these issues and alternatives.)

Terms and conditions presented during registration and the signing ceremony contribute to binding the transaction to the entity and non-repudiation. (See terms and conditions and signing ceremony for a broader discussion of these issues and alternatives.) Terms and conditions specified during the registration process include the following statement on the paper form just above the required signature block:

Terms and conditions presented during the signing ceremony (when the vessel operator has entered logbook data into the e-logbook program and is saving the data or when the vessel operator is exporting data to portable media for submission to NMFS) includes the following statement just above the required signature block:

The signer must make a willful act to demonstrate that they have read and agreed with the statement above. They must place a check mark in a check box that is labeled "I have read and understand the statement above." In addition to placing a check mark in the check box, the applicant must also type their name and their password to complete the electronic signing ceremony. Attempting to proceed to the next step of the electronic transaction without completing the above steps will cause the system to display a message instructing the applicant that they must read the terms and conditions statement, enter their name, and their password before their information will be accepted.

Technically the transaction data is bound to entity identity data by a shared identifier (permit number) in the registration data (electronic logbook agreement), the permit database, and in e-logbook submissions. Further binding could be established by asking the e-logbook vendor to correlate customer identities to the unique keys which are embedded in each installation of certified e-logbook software. (See document binding and integrity for a broader discussion of these issues and alternatives.)

Since the Hawaii Longline Logbook is not an online application no authentication token and protocol issues are involved in non-repudiation. Technical controls for document integrity and audit trails contribute to binding the transaction to the entity and non-repudiation, but those controls are more appropriately discussed in the next section.

Providing Chain of Custody Audit Trails

NMFS policy directive 32-110 specifies "...audit trails that ensure the chain of custody for the transaction. These audit trails should identify the sending location, sending individual or entity, date and time stamp of receipt, and other measures that will ensure the integrity of the document. These audit trails must validate the integrity of the transaction and prove: (1) that the connection between the submitter and NMFS has not been tampered with; and (2) how the document was controlled upon receipt by NMFS."

The proposed design implements the following audit trail controls for submission of e-logbooks via email:

1. The NMFS email interface program will run periodically (perhaps every 5 minutes), login to the postoffice, and open the inbox.
2. The email interface program will consider every message currently in the inbox, and for each message:
   1. Log receipt of the email message into audit trail tables.
   2. If the email message is recognized (recognized messages were generated by certified e-logbook software and submitted by registered permit holders).
      1. Generate a unique e-logbook message identier.
      2. Handle possible return-receipt-requested.
      3. Extract e-logbook message payload(s) (zip attachments)
         1. For each e-logbook payload:
         2. Log receipt of payload into audit trail tables.
         3. Unzip and unmarshall the payload, creating an e-logbook page object; if payload cannot be unzipped or unmarshalled the receipt is formed from the raw input data and unzip/unmarshall errors are noted and logged.
         4. Process the e-logbook page, inserting into the database (if possible) and creating a receipt (appropriate data checks are applied in this step and any errors noted in the receipt.)
         5. Return the receipt to the appropriate party.
         6. Log the result into audit trail tables.
3. These audit trail data items should be written to audit trail tables by the email interface application using a database account which has insert privileges to the database but does not have update or delete privileges. (And update and delete privileges on the audit trail tables should be carefully controlled by the database administrator.)

The proposed design implements the following audit trail controls for submission of physical media:

1. the NMFS employee who received the portable media will return to the office, login, and start a data import program.
2. The data import program will present the operator with fields to record where and when the portable media was delivered, who delivered it and who received it. The data import program will require this information before proceeding, and will institute appropriate data checks to ensure the most accurate data possible.  The data import program will record these fields as well as the login name of the operator, the time that the data import was run, and the raw uninterpreted contents of the submitted e-logbook file(s), into a NMFS database.
3. These audit trail data items should be written to audit trail tables by the data import application using a database account which has insert privileges to the database but does not have update or delete privileges. (And update and delete privileges on the audit trail tables should be carefully controlled by the database administrator.)
4. After the this audit trail information is recorded the data import program can proceed to interpret the e-logbook data stream and insert the data into NMFS operational database(s).

Providing an Electronic Receipt or Acknowledgment of a Successful Submission

The system proposed is not online and does not provide a user interface directly to the customer.  As proposed the electronic signature is executed by certified (trusted) software onboard the vessel, but, since the data is being submitted to satisfy NMFS record keeping and reporting regulations, it seems appropriate that any receipt be provided by NMFS and not by the e-logbook software vendor.  Accordingly, the proposed receipt process is as follows:

1. After the data import program has interpreted (or attempted to interpret) the submitted e-logbook data, the data import program writes a receipt file. The proposed receipt will consist of an exact recapitulation of the submitted data with the following additions:
   1. a "messages" element will be added to the XML as a child element of the top level "LogbookReport" element
      1. the messages element will contain one or more messages documenting success or failure(s) in the interpretation of the e-logbook submission; for example:
         • in the case of a successful data import one message would be returned which might look like:
           <messages>
           <message msgid="1000" severity_code="I" severity_desc="INFO">Ok</message>
           </messages>
         • in the case of a failed data import one or more messages would be returned to explain the failure which might look like:
           <messages>
           <message msgid="1179" severity_code="E" severity_desc="ERROR">Line 1 49 is not a recognized gear code</message>
           </messages>
   2. for each element in the returned XML which consists of a code, for example, gear code, the XML schema will provide an optional attribute for a name; when the XML is submitted from the vessel these optional attributes will not be present (and if they are present they will be ignored); when the XML is returned from the agency as a receipt, these optional attributes will be populated by the agency to indicate that the code was recognized and to confirm what the code represents; for example:
      • incoming XML markup for gear may look like <gear>91</gear>
      • outgoing (receipt) XML markup for gear may look like <gear name="Pot">91</gear>
2. The receipt file will be written back onto the portable media if that media is to be returned to the vessel operator
3. Assuming that the data import was successful, or at least successful enough that the e-logbook's permit could be ascertained, the receipt file will also be emailed directly by the data import program to the address of record for the permit holder
   1. The XML file will be an attachment to the receipt email message; the body of the receipt message will contain a synopsis of any "messages" elements contained in the receipt.
4. If the receipt file cannot be emailed directly to the address of record for the permit holder the operator executing the data import program is notified so that they can take steps to inform the submitter

Collecting Only Necessary Information in the Electronic Signature Authentication Process

Since the proposed system relies heavily on mitigating controls, no additional information is collected specifically for the e-signature process.

Create a Long-Term Retention and Access Policy

Retention and access policies already exist for this logbook data under NOAA file series 1505-11, Catch Statistics Files. This section discusses the special records management considerations which arise due to incorporation of an electronic signature.

NMFS policy directive 32-110 specifies

Electronic audit trails must provide a chain of custody for the secure electronic transaction that can be used to ensure the integrity of the document. The audit trail information may be needed for audits, disputes, or court cases many years after the transaction itself took place and long-term retention of not only the signed document but the accompanying audit trail should be addressed (See Sub-section 6 below).... As a general rule when the risk associated with a transaction increases the number of components tracked as part of the audit trail should increase.... The original
document along with it audit trail should not be deleted from the agency's records.... Additional information on audit trails can be found in the NARA guidelines for records management with regard to implementing electronic signatures Records Management Guidance for Agencies Implementing Electronic Signature Technologies.

NARA's Records Management Guidance for Agencies Implementing Electronic Signature Technologies section 4.1 establishes characteristics of trustworthy records in terms of reliability, authenticity, integrity, and usability. NARA advises that these characteristics are a matter of degree. Transactions that are critical to the agency business needs may need a greater assurance level that they are reliable, authentic, maintain integrity and are usable than transactions of less critical importance.

• Reliability is established by capturing the content and context of the transaction and recording that content and context in database tables through a mechanism which allows inserts but which disallows updates or deletes.
• Authenticity is established by checking logbook-related data elements against permit-related data elements, and adding the results of that validity check as a part of the context of the logbook record, stored in the database through a mechanism which allows inserts but which disallows updates or deletes.
• Integrity is established by the database mechanism which allows database inserts but which disallows updates or deletes.
• Usability is established by the linkages among the permit records and the logbook records and the e-signature receipts. Using these linkages it is possible to connect the signer and the time of the signature with the details of the signed transaction.

The guidance document section 4.2 states "for a record to remain reliable, authentic, with its integrity maintained, and usable for as long as the record is needed, it is necessary to preserve its content, context, and sometimes its structure." The proposed e-signature enabled system preserves content (logbook data), context (audit trail data and permit data), and structure (links among related tables) by maintaining a historical record of all changes to its database tables.  Updates to the data result in inserts into history tables, leaving the prior values intact in the history records.  Deletions of data result in insertions into history tables that indicate that the prior data is no longer valid.  But in all cases, the history records allow reconstruction of a point-in-time view of the data.

The guidance document section 4.3 describes two approaches to ensuring the trustworthiness of electronically-signed records over time. This e-signature implementation will maintain documentation of record validity (including trust verification records, or audit trails) gathered at or near the time of record signing (the first approach specified).

The guidance document section 4.4 describes steps to ensure trustworthy electronically-signed records as follows:

• Create and maintain documentation of the systems used to create the records that contain electronic signatures.
  The Hawaii Longline Logbook system will be thoroughly documented with particular attention to e-signature aspects and audit trails that establish the trustworthiness of the e-signature.
• Ensure that the records that include electronic signatures are created and maintained in a secure environment that protects the records from unauthorized alteration or destruction.
  The eLogbook data, and the audit trail data supporting the trustworthiness of the e-signature, are implemented with the history mechanism described above to protect the records from unauthorized alteration or deletion.  Furthermore the database is secured according to industry norms for important government data, including regular offsite backup and periodic permanent archiving of backups.
• Implement standard operating procedures for the creation, use, and management of records that contain electronic signatures and maintain adequate written documentation of those procedures.
  Standard operating procedures will be implemented for the creation, use and management of these records.
• Create and maintain records according to these documented standard operating procedures.
  The new standard operating procedures will be diligently followed. 
• Train agency staff in the standard operating procedures.
  Agency staff will be trained.
• Obtain official disposition authorities from NARA for both the records that contain electronic signatures and for the associated records which are necessary for trustworthy records.
  Electronic data submission adds audit trail data to the logbook records already covered under file series 1505-11 (Catch Statistics Files), and, establishes a link to an associated file series 1504-11(Fishing Vessel Permit Files). File series 1505-11 is sufficiently broad to accommodate the addition of audit trail data. The existing retention and access policies do not need to be revised, as the new audit trail data elements are component parts of the same database which stores the logbook records. File series 1504-11 provides disposition authority for the associated permit records which are used to establish confidence in the identity of the party applying an e-signature, and that file series needs no changes as a result of this new association.

Other considerations raised in the guidance document include:

• 5.1 What new records may be created by electronic signature technology? and 5.2 How do agencies determine which of these electronic signature records to retain?
  The e-signature proposed does not create new types of records. It does add new data elements to existing records and create new associations between existing file series, but in this case the file series involved have been reviewed and no changes to existing retention and access policies are necessary. (The the guidance document was apparently written to cover a wide range of electronic signature technology; the e-signature technology proposed is on the simple end of the scale of technical sophistication.)
• 5.3 Transferring electronic signature record material from contractors to agencies.
  Not applicable.
• 5.4 When must an agency modify its records schedule to cover electronic signature records?
  No modification to the record schedule is necessary, as new records are not created by this e-signature, the e-signature itself requires no change to retention periods, and the e-signature does not significantly change the character of the record.
• 5.5 Special considerations relating to long-term, electronically-signed records that preserve legal rights.
  The e-signature proposed does not depend on technologies or formats which are likely to become obsolete. The e-signature, it's associated audit trails, and the receipt are all stored as human readable text in relational database tables.
• 5.6 NARA requirements for permanent, electronically-signed records.
  These are not permanent records, but, note that the receipt, which is stored as part of the e-signature, does contain the printed name of the signer as well as the date when the signature was executed.

Periodic Review and Re-Evaluation of the Electronic Signature Process

The proposed e-signature system should be reviewed annually for several years, as this technology is unfamiliar to the agency and our customers and we expect to learn from experience.