...
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:
...
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 NMFS employee who received the portable media will return to the office, login, and start a data import program.
- 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.
- 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.)
- 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:
- 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:
- a "messages" element will be added to the XML as a child element of the top level "LogbookReport" element
- 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>
- in the case of a successful data import one message would be returned which might look like:
- the messages element will contain one or more messages documenting success or failure(s) in the interpretation of the e-logbook submission; for example:
- 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>
- a "messages" element will be added to the XML as a child element of the top level "LogbookReport" element
- The receipt file will be written back onto the portable media if that media is to be returned to the vessel operator
- 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
- 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.
- 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 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.