Implementers of the STAR Transport Guidelines are encouraged to leverage Digital Signature standards that enable Non-Repudiation. Whether or not a business transaction requires Non-Repudiation is determined at the application level, but the physical implementation of Digital Signature required for Non-Repudiation occurs at the Transport level.

Signing a message lends itself to “Non-Repudiation of Origin”, in other words, the business partner receiving a message can prove at any later time that the message originated from a specific unique party. Signing a message can also guarantee that the message was received intact, byte-for-byte as sent.

Under the framework known as PKI (Public Key Infrastructure), a message sender signs each message using a specific Private Key. The Private Key is associated with a well-known Public Key, and the Public Key is known to be associated with a business partner’s computer system or one of the business partner’s employees.

“Non-Repudiation of Receipt” is a model of Non-Repudiation that requires a little more work than Non-Repudiation of Origin. To enable Non-Repudiation of Receipt, the receiver of a message creates a digest of the received message, signs the digest, and returns the signed digest within an acknowledgment to the original message. The business partner that originated the message can now prove later, that the message he/she sent was received intact by the intended business partner.

Auditing is useful for monitoring the security of the transport layer. Logs of messages can be reviewed to detect compromises of security or to document compliance with local security policies. Logging message information along with the disposition of such messages is a best practice for organizations that need to be able to audit activities for security policy compliance.

Signing a message provides a guarantee that a message was not altered in transit. By accepting and logging that message, a receiver keeps a record of the valid and invalid messages. If a message is invalidated, then it may be suspected of malicious tampering. Logging the entire message can help in tracking down and in prosecution when security issues arise.

When an originator needs to have assurance that a message was received, that organization could request a signed receipt acknowledgement. An audit trail of these receipt acknowledgements provides assurance that the receiver is the intended receiver.

Logging provides a record of messages that pass through the transport tier. This record is a tool that enables non-repudiation for transport of messages. Logging of all messages that specify non-repudiation is necessary to support the ability to audit the STAR Transport.

STAR does not require a specific format for logging the exchange of a message, but does specify the key fields [for those messages that are logged] which must be logged, which include time stamps, senders, receivers, message ID, and payload type. Additionally, a status field in the log record can indicate the message disposition and is recommended to track messages that are valid, have bad signatures, do not pass checksum, or other exception condition. STAR distinguishes between:

Simple logging of key fields and metadata of a message vs. saving a copy of the entire message.

STAR requires that the globally unique message ID be generated for each message, and that these message IDs must be logged as one of the key data fields related to the message. If the application does not generate the Message ID, then it must be generated by the transport.

Logging systems should make important key fields from the messages easily available. Logging systems must be able to display or export information with Timestamp formats that do not rely on local system time, but are expressed in a universal time format.

STAR recommends that logs are retained for at least 30 days. STAR recognizes that companies may retain logs for periods of several years or more, depending on the type of message.

STAR requires that all messages in transit be time-stamped using UTC (Coordinated Universal Time) in a fashion that relies on what is known as GMT (Greenwich Mean Time) and is often referred to as Zulu time. In other words, Timestamps that appear in the Headings of messages in transit must be in UTC/GMT format without local time-zone offsets. STAR does not require that messages be logged or stored using UTC/GMT, but as mentioned above, STAR requires that Logging systems when queried be able to display Timestamp information in UTC/GMT format without time-zone offsets.