NCBF Implementation Details (Larry)

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 Non-Commercial Bottomfish e-signature evaluation has concluded that OMB Assurance Level 1 (little or no confidence in the asserted identity) was appropriate for the Hawaii Longline Logbook. This was a considered decision justified by low likelyhood of occurrence, low impact of harm, emphasis on usability and public acceptance, and mitigating controls, including matching of the asserted identity with a specific fishing permit and the email address of record for that fishing permit. 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 initiating an online registration process to establish username and password credentials for e-signature. The registration web application will guide the permit holder through choosing a username and password, entering their fishing permit number and email address, and entering a CAPTCHA string. The registration program will verify the CAPTCHA string (as a defense against automated attacks) and then confirm that the email address supplied matches the email address-of-record for the specified fishing permit. If these tests are passed, the program will generate an email message to this address-of-record. The email message will contain a URL link unique for this particular registration transaction. When the email message has been sent to the address-of-record, the registration program will explain to the permit holder that they must now follow further instructions which will be supplied via email to complete their registration. The permit holder should now access their email, read the registration message, and click on the unique link enclosed. When they click on the enclosed link, the registration program will recognize the unique key in the URL and will accept that unique key as confirmation that the permit holder does have control of the email address-of-record.
(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 is submitting logbook data 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 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, and enter 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. (See document binding and integrity for a broader discussion of these issues and alternatives.)

The authentication tokens are username and password, and they are protected by Secure Socket Layer (SSL) transmission protocol. 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 the web:

1. Audit trail entries will be written for each registration submission, recording a timestamp, origin and destination IP addresses, username, permit number, email address-of-record, and generated email message.
2. Audit trail entries will be written upon receiving an HTTP request for the uniquely coded URL that indicates confirmation of control of the email address-of-record, recording a timestamp, origin and destination IP addresses, username, permit number, and the unique URL requested.
3. Audit trail entries will be written upon each e-signature transaction, recording a timestamp, origin and destination IP addresses, username, permit number, an e-signature transaction id, and the data submitted in the e-logbook entry which is being signed.
4. A receipt page will be displayed to the permit holder after each e-signature transaction, a copy of the receipt will also be sent via email to the permit holder's email address-of-record, and audit trail entries will be written, recording a timestamp, origin and destination IP addresses, username, permit number, an e-signature transaction id, and the text of the receipt. (See more detail in the Receipt section below.)

• These audit trail data items should be written to audit trail tables by the web 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.)

Providing an Electronic Receipt or Acknowledgment of a Successful Submission

Subsequent to each e-signature transaction, a receipt page will be displayed to the permit holder, and a copy of the receipt will also be sent via email to the permit holder's email address-of-record. The receipt will document the timestamp, username, permit number, the e-signature transaction id, and included a recapitulation of the submitted data with the following additions:

1. 1. A "messages" section will be added to document processing of the data submission:
      1. this section 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:

           Ok

         • in the case of a failed data import one or more messages would be returned to explain the failure which might look like:

           Line 1: 49 is not a recognized gear code
           Line 2: 412 is not a recognized species code

2. If the receipt cannot be emailed directly to the address of record for the permit holder appropriate NMFS operations personnel are notified so that they can take steps to inform the submitter and resolve the problem.

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 logbook data.  Electronic data submission does add audit trail data to the mix.  The existing retention and access policies will be revised to accommodate electronic submission audit trail data and protect that data from delete or update access.

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.