Page Comparison

...

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:

...

No authentication token and protocol issues are involved in this 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."

...

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 e-ticket software and submitted by registered permit holders).
      1. Generate a unique e-ticket message identier.
      2. Handle possible return-receipt-requested.
      3. Extract e-ticket message payload(s) (zip attachments)
         1. For each e-ticket payload:
         2. Log receipt of payload into audit trail tables.
         3. Unzip and unmarshall the payload, creating an e-ticket 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-ticket object, 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.)

Providing an Electronic Receipt or Acknowledgment of a Successful Submission

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

   Panel
   Dave or Dayna needs to describe the receipt and check that the statements below are accurate

2. Assuming that the data import was successful, or at least successful enough that the e-ticket'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
3. 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.

...

• 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.