PKIX Working Group Michael E. McNeil Internet Draft GMT Document: Todd S. Glassey Category: Informational GMT Expires in six months: 17 November 1999 17 May 1999 Basic Event Representation Token v1 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract More and more, standards agencies that use PKI technologies developed and promulgated through the efforts of the IETF have come to ask for a finite method of representing a discrete instant in time as a referable event. The present document establishes defined data structures for requesting a Basic Event Representation Token (BERT), after it has been issued by a Trusted Timebase provider. Conventions used in this document Certain timing specific conventions are used in this document and are described in the references section in more detail. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ ]. McNeil, Glassey expires November 17, 1999 [Page 1] Internet-Draft 17 May 1999 Contents 1. Basic Event Representation Token (BERT) . . . . . . . . . . . . 4 1.1 Principles behind the Token . . . . . . . . . . . . . . . . . . 4 1.2 To ASN.1 or Not to ASN.1 . . . . . . . . . . . . . . . . . . . 4 2. BERT Reply Token (aka "the BERT") . . . . . . . . . . . . . . . 5 2.1 Reply Nonce (8 octets) . . . . . . . . . . . . . . . . . . . . 8 2.2 "Reply Token" Identifier (3 octets) . . . . . . . . . . . . . . 8 2.3 Reply Version (1 octet) . . . . . . . . . . . . . . . . . . . . 9 2.4 Reply Length (2 octets) . . . . . . . . . . . . . . . . . . . . 9 2.5 Reply Status (2 octets) . . . . . . . . . . . . . . . . . . . . 10 2.6 Reply Policy (8 octets) . . . . . . . . . . . . . . . . . . . . 10 2.7 Time-Space Coordinates . . . . . . . . . . . . . . . . . . . . 10 2.8 Time Certification . . . . . . . . . . . . . . . . . . . . . . 10 2.9 Timebase Identifier (1-256 octets) . . . . . . . . . . . . . . 11 2.10 Reply Certificate Identifier (1-256 octets) . . . . . . . . . 12 2.11 Reply Signature Length (2 octets) . . . . . . . . . . . . . . 12 3. BERT Request Token. . . . . . . . . . . . . . . . . . . . . . . 13 3.1 Request Nonce (8 octets) . . . . . . . . . . . . . . . . . . . 14 3.2 "Request Token" Identifier (3 octets) . . . . . . . . . . . . . 15 3.3 Request Version (1 octet) . . . . . . . . . . . . . . . . . . . 15 3.4 Request Length (2 octets) . . . . . . . . . . . . . . . . . . . 15 3.5 Request Status (2 octets) . . . . . . . . . . . . . . . . . . . 16 3.6 Request Policy (8 octets) . . . . . . . . . . . . . . . . . . . 16 3.7 Request Time (12 octets) . . . . . . . . . . . . . . . . . . . 17 3.8 Request Hash . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.9 Transaction Identifier (1-256 octets) . . . . . . . . . . . . . 18 3.10 Requestor Identifier (1-256 octets) . . . . . . . . . . . . . 19 3.11 Request Certificate Identifier (1-256 octets) . . . . . . . . 20 3.12 Request Signature Length (2 octets) . . . . . . . . . . . . . 20 4. Request Hash (list structure: 1-109 octets) . . . . . . . . . . 21 4.1 Length field (1 octet) . . . . . . . . . . . . . . . . . . . . 22 4.2 Hash Algorithm Identifier (2 octets) . . . . . . . . . . . . . 22 4.3 Hash field (0-32 octets) . . . . . . . . . . . . . . . . . . . 22 5. Time Certification (list structure: 1-1585 octets) . . . . . . 23 5.1 Time Certification Server Identifier (2-256 octets) . . . . . . 24 5.2 Time Certification Client Identifier (1-256 octets) . . . . . . 25 5.3 Time Certification Record Identifier (12 octets) . . . . . . . 25 5.4 Time Certification Network Identifier (4 octets) . . . . . . . 25 6. Signature (0-1024 octets) . . . . . . . . . . . . . . . . . . . 26 7. The Time Coordinate . . . . . . . . . . . . . . . . . . . . . . 27 7.1 UTC Time (12 octets) . . . . . . . . . . . . . . . . . . . . . 28 7.2 Leap Second Count (4 octets) . . . . . . . . . . . . . . . . . 29 7.3 Precision (4 octets) . . . . . . . . . . . . . . . . . . . . . 29 8. Spatial Coordinates . . . . . . . . . . . . . . . . . . . . . . 30 8.1 Precision (4 octets) . . . . . . . . . . . . . . . . . . . . . 32 8.2 Latitude (8 octets) . . . . . . . . . . . . . . . . . . . . . 33 8.3 Longitude (8 octets) . . . . . . . . . . . . . . . . . . . . . 33 8.4 Altitude (12 octets) . . . . . . . . . . . . . . . . . . . . . 34 McNeil, Glassey expires November 17, 1999 [Page 2] Internet-Draft 17 May 1999 9. Appendix: Time Representation . . . . . . . . . . . . . . . . . 35 9.1 NTP time representation format . . . . . . . . . . . . . . . . 35 9.2 UTC96 time format . . . . . . . . . . . . . . . . . . . . . . . 35 9.3 Leap Second Count and Precision . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 37 13. Full Statement . . . . . . . . . . . . . . . . . . . . . . . . 38 McNeil, Glassey expires November 17, 1999 [Page 3] Internet-Draft 17 May 1999 1. Basic Event Representation Token (BERT) The basic need to represent events in a number of standardized formats has long been known, but as technology deployment becomes more uniform around the world, these structures become the anchors of policy and proofing models for commerce, world wide. Because of this, the structure of the token produced is as important as the protocol that the user used to create it. With this concept in mind, this physical token structure is offered with regard to its potential for representing events in time and space. 1.1 Principles behind the Token The BERT tokens are designed to be what is referred to as light- weight. The intent of the use models for this token is that it will be used in environments where it may be subsumed into both legacy systems and newly erected structures. Because of this there are several important criteria concerning the use model that should be mentioned here. First, they are built to contain a single instance of an event stamp, not a full chain of event stream, although repetitive or recursive stamping can be used in a number of methods to achieve end-to-end non-repudiation via this structure. Second, the trust process is referenced against an external reference. This is to provide both strength and a service model wherein the token can be used to represent an event from a person identified by a publicly available CA source. 1.2 To ASN.1 or Not to ASN.1 The question as to the final representation format of the token is critical to a number of the use models. While ASN.1, like BNF in representing data, is an excellent mechanism, physical implementations of the services lead to less than robust models. For purposes of structures used in this document, each octet of data must be accounted for in detail. Since the tokens are intended to be used by machines as part of machine processes (that is, in large numbers over short periods of time), there is a need to maintain economies of scale and save space, thus the structure of the token was reduced to binary. McNeil, Glassey expires November 17, 1999 [Page 4] Internet-Draft 17 May 1999 2. BERT Reply Token (aka "the BERT") The Basic Event Representation Token (BERT) Reply Token (also known simply as "the BERT") results from a call to a host-borne API or as the result of a timestamping service called from some other service. The general idea is that the service interface would use a call such as Create BERT which would result in a BERT Request Token being prepared, possibly cryptographically signed, and forwarded by the Host API through the Host-Timebase Interface, designed local to the current host. (See section 3 for details about the Request Token.) The Timebase encapsulates the Request Token (less the Signature on the Request, if any) into the Reply Token it prepares, adds fields of its own, applies a cryptographic signature, then relays it back to the host for return by the Host API to the requestor application. The following table illustrates the fields of the BERT Reply Token: +-------------------------------+-------------------------------+ | Reply Nonce | "Reply Token" Identifier | +-------------------------------+-------------------------------+ | Reply Version | Reply Length --> | +-------------------------------+-------------------------------+ | Reply Status | Reply Policy | +-------------------------------+-------------------------------+ | UTC Time | Leap Second Count | +-------------------------------+-------------------------------+ | Precision | Latitude | +-------------------------------+-------------------------------+ | Longitude | Altitude | +-------------------------------+-------------------------------+ | Request Nonce * | "Request Token" Identifier * | +-------------------------------+-------------------------------+ | Request Version * | Request Length * | +-------------------------------+-------------------------------+ | Request Status * | Request Policy * | +-------------------------------+-------------------------------+ | Request Time * | Request Hash (list...) * | +-------------------------------+-------------------------------+ | Transaction Identifier * | Requestor Identifier * | +-------------------------------+-------------------------------+ | Request Cert. Identifier * | Request Signature Length * | +-------------------------------+-------------------------------+ | Time Cert. (list...) | --> Timebase Identifier | +-------------------------------+-------------------------------+ | Reply Cert. Identifier | Reply Signature Length | +-------------------------------+-------------------------------+ | Signature | +---------------------------------------------------------------+ *Requestor provided fields (encapsulated BERT Request Token). --> Indicates where Reply Length field effectively points. McNeil, Glassey expires November 17, 1999 [Page 5] Internet-Draft 17 May 1999 The following table provides more information concerning the field structure of the BERT Reply Token: BERT Reply Token (aka "the BERT") Octets: 119-4110 (575 typical) +------------------------------------------------------------------+ | Trusted Timebase originated | | Reply Nonce 8 (8) ** | | "Reply Token" Identifier 3 (3) ** | | Reply Version 1 (1) ** | | Reply Length 2 (2) ** | | Reply Status 2 (2) ** | | Reply Policy 8 (8) ** | | | | Time-Space Coordinates | | UTC Time 12 (12) ** | | Leap Second Count 4 (4) ** | | Precision 4 (4) ** | | Latitude 8 (8) ** | | Longitude 8 (8) ** | | Altitude 12 (12) ** | +------------------------------------------------------------------+ | Host API originated (encapsulated Request Token, less Signature) | | Request Nonce 8 (8) ** | | "Request Token" Identifier 3 (3) ** | | Request Version 1 (1) ** | | Request Length 2 (2) ** | | Request Status 2 (2) ** | | Request Policy 8 (8) ** | | Request Time 12 (12) ** | | | | Subtotal *** 108 (108) | | | | Request Hash (list...) 1-109 (24) ** | | Transaction Identifier (string) 1-256 (16) ** | | Requestor Identifier (string) 1-256 (16) ** | | Request Cert. Identifier (string) 1-256 (24) ** | | Request Signature Length 2 (2) ** | +------------------------------------------------------------------+ | Trusted Timebase originated | | Time Certification (list...) 1-1585 (87) ** | | Timebase Identifier (string) 1-256 (16) ** | | Reply Cert. Identifier (string) 1-256 (24) ** | | Reply Signature Length 2 (2) ** | +------------------------------------------------------------------+ | Signature 0-1024 (256*) | | | | Total 119-4110 (575) | +------------------------------------------------------------------+ Strings begin with a length byte and are not terminated by null. *Typical example of signature uses RSA encryption with 2048-bit key. **Indicates cryptographically signed fields. ***Constant width fields up to this point. McNeil, Glassey expires November 17, 1999 [Page 6] Internet-Draft 17 May 1999 Following is a bit-wise representation of the fields of the Reply Token, up to the beginning of the Time-Space Coordinate fields: (Offset = 0) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Nonce (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "Reply Token" Identifier | Reply Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Length | Reply Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Policy (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 24) Variable-width fields typically have an allocated size of from 1 to 256 octets and begin with a length byte containing the size of the immediately adjacent data field, which may be from 0 to 255 octets. The variable-width data field is not a string in the C sense, as the field does not end in a null octet and can contain any bit pattern. A bit-wise diagram illustrating this format follows (L symbolizes the length byte, which contains an 8-bit unsigned numeric value). 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ... L+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Variable-width data field... (0-255 octets) | Next field... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A null variable-width data field will appear as follows: 1 0 1 2 3 4 5 6 7 8 9 0 ... +-+ |0| Next field... +-+ McNeil, Glassey expires November 17, 1999 [Page 7] Internet-Draft 17 May 1999 The following sections describe the Timebase-originated fields of the Basic Event Representation Token (BERT) Reply Token in detail: 2.1 Reply Nonce (8 octets) Consists of random data that originates on the Timebase. Prepares the Basic Event Representation Token ("the BERT") for possible encryption as a whole. Increases resistance to known-text attacks. A bit-wise diagram of the Reply Nonce field follows: (Offset = 0) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Nonce (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 8) 2.2 "Reply Token" Identifier (3 octets) Identifies with a "magic" bit pattern the present token as a Basic Event Representation Token (BERT) Reply Token. 1. Basic Event Representation Token Identifier (magic) (2 octets) 2. BERT Reply Token Identifier (command code) (1 octet) A bit-wise diagram of the "Reply Token" Identifier fields follows: (Offset = 8) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BERT Identifier (magic no.) | Rep. Token ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 11) McNeil, Glassey expires November 17, 1999 [Page 8] Internet-Draft 17 May 1999 2.3 Reply Version (1 octet) 1. Major Version Number (high-order nibble) (4 bits) Indicates a non-backwards compatible version change has occurred with respect to earlier major numbers. 2. Minor Version Number (low-order nibble) (4 bits) Indicates a backwards-compatible version change has occurred with respect to earlier minor numbers. A bit-wise diagram of fields within the Reply Version follows: (Offset = 11) 1 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+ | Major | Minor | +-+-+-+-+-+-+-+-+ (Offset = 12) 2.4 Reply Length (2 octets) Length of the BERT Reply Token, from the beginning of the Token (the Reply Nonce field) to the start of the Timebase Identifier field. A bit-wise diagram of the Reply Length field follows: (Offset = 12) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 14) McNeil, Glassey expires November 17, 1999 [Page 9] Internet-Draft 17 May 1999 2.5 Reply Status (2 octets) Status flags from the Timebase regarding the Reply Token. Following are examples of such flags: o Success o Authentication of Requestor failed o Request Token signature successfully verified o BERT (Reply Token) was not signed o Policy request by Requestor cannot be satisfied A bit-wise diagram of bit fields within the Reply Status follows (note that specific bit-flag assignments are yet to be defined): (Offset = 14) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 16) 2.6 Reply Policy (8 octets) Timebase policy with regards to issuance of Reply Token. To be defined. A bit-wise diagram of fields within the Reply Policy follows (specific policy assignments and structure are to be defined): (Offset = 16) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 20) 2.7 Time-Space Coordinates See sections 7, 8 and 9 for details of BERT Time-Space Coordinates. 2.8 Time Certification See section 5 for details on Trusted Time Certification. McNeil, Glassey expires November 17, 1999 [Page 10] Internet-Draft 17 May 1999 2.9 Timebase Identifier (1-256 octets) The Timebase Identifier field is filled in by the Timebase while building the BERT Reply Token. The Timebase Identifier contains the name (including any optional Organization component) of the Timebase. The Timebase Identifier, while optional (its length field may contain null), if the Reply Token was signed by the Timebase, this field (together with the Reply Certificate Identifier field) should provide third party users with enough information for them to identify the certificate which was used in signing the Reply. Note that the Reply Length field (which is not the Length field below) contains the length of the Reply Token from the beginning (the Reply Nonce field) to the start of the Timebase Identifier. 1. Length field (1 octet) The length specified for the Timebase Identifier string does not include the length of the length field itself. 2. Timebase Identifier string (Variable: 0-255 octets) 1. Timebase Organization Name + Separator (":") (optional) 2. + Timebase Identifier string proper Examples of information which could go in this field: o ASCII identifier o Certificate thumbprint o Raw IP address o Other A bit-wise diagram of the Timebase Identifier string follows: (Offset = X) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ... L+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Variable-width data field... (0-255 octets) | Next field... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + L + 1) McNeil, Glassey expires November 17, 1999 [Page 11] Internet-Draft 17 May 1999 2.10 Reply Certificate Identifier (1-256 octets) The Reply Certificate Identifier field of the BERT, while optional (its length field may contain null), provides users of the Basic Event Representation Token with the capability of identifying the precise X.509 certificate used to cryptographically sign the Reply. 1. Length field (1 octet) Length specified does not include length of the length field. 2. Reply Certificate Identifier string (Variable: 0-255 octets) 1. Reply CertificateÆs CA Name + Separator (":") (optional) 2. + CA Certificate Identifier + Separator (":") (optional) 3. + Reply Certificate Identifier proper Examples of information which could go in this field: o ASCII identifier o Certificate thumbprint o Other A bit-wise diagram of the Reply Certificate Identifier follows: (Offset = X) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ... L+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Variable-width data field... (0-255 octets) | Next field... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + L + 1) 2.11 Reply Signature Length (2 octets) Length of the cryptographic Signature field of the Reply Token. This field is provided for convenience in parsing the Token. The length of the signature is determined by the X.509 certificate, and therefore the hash and PKI encryption algorithms and the key size. The Reply Signature Length is cryptographically signed along with the rest of the Reply Token excepting the Signature field itself. A bit-wise diagram of the Reply Signature Length field follows: (Offset = X) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + 2) McNeil, Glassey expires November 17, 1999 [Page 12] Internet-Draft 17 May 1999 3. BERT Request Token The following illustrates the structure of the Requestor (Host API) supplied BERT Request Token. (All fields but the Signature of the BERT Request Token are encapsulated within the BERT Reply Token.) +-------------------------------+-------------------------------+ | Request Nonce | "Request Token" Identifier | +-------------------------------+-------------------------------+ | Request Version | Request Length --> | +-------------------------------+-------------------------------+ | Request Status | Request Policy | +-------------------------------+-------------------------------+ | Request Time | Request Hash (list...) | +-------------------------------+-------------------------------+ | Transaction Identifier | --> Requestor Identifier | +-------------------------------+-------------------------------+ | Request Cert. Identifier | Request Signature Length | +-------------------------------+-------------------------------+ | Signature (optional) | +---------------------------------------------------------------+ --> indicates where Request Length field effectively points. Following is a bit-wise representation of the fields of the Request Token, up to the first variable-width field (Requestor Identifier): (Offset = 72) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "Request Token" Identifier | Req. Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Length | Request Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Policy (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Request Time (UTC96: extended-epoch UTC) (96) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 108) McNeil, Glassey expires November 17, 1999 [Page 13] Internet-Draft 17 May 1999 Variable-width fields typically have an allocated size of from 1 to 256 octets and begin with a length byte containing the size of the immediately adjacent data field, which may be from 0 to 255 octets. The variable-width data field is not a string in the C sense, as the field does not end in a null octet and can contain any bit pattern. A bit-wise diagram illustrating this format follows (L symbolizes the length byte, which contains an 8-bit unsigned numeric value). 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ... L+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Variable-width data field... (0-255 octets) | Next field... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A null variable-width data field will appear as follows: 1 0 1 2 3 4 5 6 7 8 9 0 ... +-+ |0| Next field... +-+ The following sections describe the fields of the Request Token: 3.1 Request Nonce (8 octets) Randomly generated data vector supplied by Host API which uniquely identifies this request. Helps forestall playback attacks. A bit-wise diagram of the Request Nonce field follows: (Offset = 72) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 80) McNeil, Glassey expires November 17, 1999 [Page 14] Internet-Draft 17 May 1999 3.2 "Request Token" Identifier (3 octets) Identifies with a "magic" bit pattern the present token as a Basic Event Representation Token (BERT) Request Token. (The Request Token including this Identifier may be embedded within a Reply Token.) 1. Basic Event Representation Token Identifier (magic) (2 octets) 2. BERT Request Token Identifier (command code) (1 octet) A bit-wise diagram of the "Request Token" Identifier fields follows: (Offset = 80) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BERT Identifier (magic no.) | Req. Token ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 83) 3.3 Request Version (1 octet) 1. Major Version Number (high-order nibble) (4 bits) Indicates a non-backwards compatible version change has occurred with respect to earlier major numbers. 2. Minor Version Number (low-order nibble) (4 bits) Indicates a backwards-compatible version change has occurred with respect to earlier minor numbers. A bit-wise diagram of fields within the Request Version follows: (Offset = 83) 1 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+ | Major | Minor | +-+-+-+-+-+-+-+-+ (Offset = 84) 3.4 Request Length (2 octets) Length of BERT Request Token, from the beginning of the Token (Request Nonce field) to the start of the Requestor Identifier. A bit-wise diagram of the Request Length field follows: (Offset = 84) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 86) McNeil, Glassey expires November 17, 1999 [Page 15] Internet-Draft 17 May 1999 3.5 Request Status (2 octets) Status flags from the Host API concerning the BERT Request Token. Following are examples of such flags: o BERT Request Token was not signed by Host API o Sign (or do not sign) BERT Reply Token ("the BERT") A bit-wise diagram of bit fields within the Request Status follows (note that specific bit-flag assignments are yet to be defined): (Offset = 86) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 88) 3.6 Request Policy (8 octets) Requestor (Host API) policy with regard to issuance of the BERT, as stated in the Request Token, and echoed back in the Reply Token. Following are examples of such flags: o Requested Signature Algorithm to be used in signing Reply Token o Requested Signing Key Length to be used in signing Reply Token o Requested Signing Certificate to be used in signing Reply Token o Request Tokens are (or are not) signed A bit-wise diagram of fields within the Request Policy follows (specific policy assignments and structure are to be defined): (Offset = 88) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 96) McNeil, Glassey expires November 17, 1999 [Page 16] Internet-Draft 17 May 1999 3.7 Request Time (12 octets) Time of request (local UTC time of call to Host API), as stated in the Host APIÆs own local system time, expressed using the UTC96 format, but without the leap second count or precision fields. (See sections 7, 8 and 9 for additional information about UTC96.) 1. Reserved bit; must be 0 (1 bit) 2. 63-bit extended-epoch UTC seconds count (~8 octets) 3. 32-bit NTP-style 2^(-32) UTC fractional seconds (4 octets) A bit-wise diagram of the fields within the Request Time follows: (Offset = 96) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| High-Order UTC Time seconds count (Epoch Word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Low-Order UTC Time seconds count (NTP style) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2^(-32) UTC fractional seconds (NTP style) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 108) R symbolizes the Reserved bit, which must be 0. 3.8 Request Hash See section 4 for details on the Request Hash list structure. McNeil, Glassey expires November 17, 1999 [Page 17] Internet-Draft 17 May 1999 3.9 Transaction Identifier (1-256 octets) The Transaction Identifier field of the BERT, while optional (its length field may contain null), provides later users of the Basic Event Representation Token with the capability of obtaining identifying information, bound within the BERT, concerning the information which was timestamped. The nature of this identifying information is up to the original caller of Create BERT to make the Event Stamp, and may include document filenames or transaction IDÆs. 1. Length field (1 octet) Length specified does not include length of the length field. 2. Transaction Identifier string (Variable: 0-255 octets) Examples of information which could go in this field: o ASCII identifier; e.g., document filename o Transaction identifying number o Other (thumbprint or the like) A bit-wise diagram of the Transaction Identifier string follows: (Offset = X) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ... L+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Variable-width data field... (0-255 octets) | Next field... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + L + 1) McNeil, Glassey expires November 17, 1999 [Page 18] Internet-Draft 17 May 1999 3.10 Requestor Identifier (1-256 octets) Contains the name (including any optional Organization component) of the Requestor. The Requestor Identifier field, while optional (its length field may contain null), if the Request Token was signed by the Host API, this field (together with the Request Certificate Identifier field) must provide the Timebase enough information for it to identify the certificate which was used to sign the Request. The Requestor Identifier field is filled in by the Host API while building the BERT Request Token, derived from the information it has concerning the User whose application issued the requesting API call. This (perhaps) User information may be used by the Host API to select the certificate which it (optionally) uses to sign the Request. The presence of the Request Identifier specifies a connection within the BERT (Reply Token) that associates it with (possibly) a User identity or a human name on into the future. Note that the Request Length field (which is not the Length field below) contains the length of the Request Token from the beginning (the Request Nonce field) to the start of the Requestor Identifier. 1. Length field (1 octet) Length specified does not include length of the length field. 2. Requestor Identifier string (Variable: 0-255 octets) 1. Requestor Organization Name + Separator (":") (optional) 2. + Requestor Identifier string proper Examples of information which could go in this field: o ASCII identifier o Certificate thumbprint o Raw IP address o Other A bit-wise diagram of the Requestor Identifier string follows: (Offset = X) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ... L+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Variable-width data field... (0-255 octets) | Next field... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + L + 1) McNeil, Glassey expires November 17, 1999 [Page 19] Internet-Draft 17 May 1999 3.11 Request Certificate Identifier (1-256 octets) The Request Certificate Identifier field of the BERT Request, while optional (its length field may contain null), provides the responding Timebase with the capability of identifying the precise X.509 certificate used to cryptographically sign the Request. 1. Length field (1 octet) Length specified does not include length of the length field. 2. Request Certificate Identifier string (Variable: 0-255 octets) 1. Request CertificateÆs CA Name + Separator (":") (optional) 2. + CA Certificate Identifier + Separator (":") (optional) 3. + Request Certificate Identifier proper Examples of information which could go in this field: o ASCII identifier o Certificate thumbprint o Other A bit-wise diagram of the Request Certificate Identifier follows: (Offset = X) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ... L+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Variable-width data field... (0-255 octets) | Next field... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + L + 1) 3.11 Request Signature Length (2 octets) Length of the cryptographic Signature field of the Request Token. This field is provided for convenience in parsing the Token; the length of the signature is determined by the X.509 certificate, and therefore the hash and PKI encryption algorithms and the key size. The Request Signature Length is cryptographically signed along with the rest of the Request Token excepting the Signature field itself. A bit-wise diagram of the Request Signature Length field follows: (Offset = X) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + 2) McNeil, Glassey expires November 17, 1999 [Page 20] Internet-Draft 17 May 1999 4. Request Hash (list structure: 1-109 octets) The BERT Request Hash list structure supports multiple requestor- supplied independent one-way hashes (also known as message digests) of a document or transaction data, consisting of a list of: o Up to three 256-bit (32-octet) hashes up to 106 octets o Or up to four 192-bit (24-octet) hashes up to 109 octets o Or a combination of hash types up to 109 octets max. The following illustrates the overall Request Hash list structure: Request Hash list structure 1-109 octets +------------------------------------------------------------------+ | Request Hash record (record no. 1) 3-35 octets | | 1. Length field (length + algorithm ID + hash) 1 octet | | 2. Hash Algorithm Identifier (IANA assigned) 2 octets | | 3. Hash field 0-32 octets | +------------------------------------------------------------------+ | Request Hash record (record no. 2) 3-35 octets | +------------------------------------------------------------------+ | Request Hash record (record no. 3) 3-35 octets | +------------------------------------------------------------------+ | End of Request Hash list | | Null length field implies end of list 1 octet | +------------------------------------------------------------------+ A diagram showing an example Request Hash list structure follows: (Offset = X) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|Alg| Variable-width Hash field... (0-32 octets) | L1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|Alg| Variable-width Hash field... | L2 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|Alg| Variable-width Hash field... | L3 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | etc. +-+-+-+-+-+-+-+-+-+-+ |0| +-+ (Offset = X + L1 + L2 + L3 + ... + 1) L symbolizes Length field of each record; contains record length. Alg symbolizes standard identifier for Hash algorithm being used. McNeil, Glassey expires November 17, 1999 [Page 21] Internet-Draft 17 May 1999 A detailed description of fields of the Request Hash record follows: 4.1 Length field (1 octet) Holds the binary length in octets of the entire Request Hash record; which is to say: size of the Length field (1 octet) + length of the Hash Algorithm Identifier (2 octets) + length of the Hash field. Null in the Length field implies the end of the Request Hash list, and the end of this record, truncated after the Length field. 4.2 Hash Algorithm Identifier (2 octets) Unique Identifier, using identifiers supplied by the IANA, for the hashing (message digest) algorithm whose hash is in the next field. 4.3 Hash field (0-32 octets) The Request Hash field contains a one-way hash or message digest of the requestorÆs document or data, according to the indicated hash algorithm. No check of the veracity of this hash is performed (none can occur since the document data is not supplied with the Request). The limit of 32 octets for this field is wholly arbitrary and not structural. Following are Hash field sizes for hashing algorithms which are supported in the Basic Event Representation Token: o Null (0 bits) (0 octets) o MD5 (128-bit hash) (16 octets) o SHA-1 (160-bit hash) (20 octets) McNeil, Glassey expires November 17, 1999 [Page 22] Internet-Draft 17 May 1999 5. Time Certification (list structure: 1-1585 octets) The next portion of the BERT Reply Token (initialized by the Timebase) deals with the Trusted Time Certification (TC) list structure, which provides logical identifying addresses for up to three Time Certification Servers and the Time Certification Clients whose time the Servers have verified via Trusted Time Certification. Organized as a "tree of trusted time" leading from a top of the hierarchy (NIST, in the USA) ultimately to the Timebase whose time was the basis for the given BERT, the Time Certification ServersÆ logged records of specific Trusted Time certifications that validate particular BERTs can be retrieved given the server and record identifiers which are included in the Time Certification records. Time Certification certifies time via two connection types: o Top of hierarchy --> Master Commercial Timing or Trust Center o Master Commercial Timing or Trust Center --> Timebase Following is an illustration of the Time Certification structure: Time Certification list structure 1-1585 octets +------------------------------------------------------------------+ | Time Certification record (record no. 1) 19-528 octets | | 1. TC Server Identifier: "ServerOrg:ServerID" 2-256 octets | | 2. TC Client Identifier: "ClientOrg:ClientID" 1-256 octets | | 3. TC Record Identifier (time of certification) 12 octets | | 4. Network Identifier 4 octets | +------------------------------------------------------------------+ | Time Certification record (record no. 2) 19-528 octets | +------------------------------------------------------------------+ | Time Certification record (record no. 3) 19-528 octets | +------------------------------------------------------------------+ | End of Time Certification list | | Null length field implies end of list 1 octet | +------------------------------------------------------------------+ McNeil, Glassey expires November 17, 1999 [Page 23] Internet-Draft 17 May 1999 A bit-wise diagram of an example Time Certification record follows: (Offset = X) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| TC Server Identifier... (0-255 octets) | L1+1 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| TC Client Identifier... (0-255 octets) | L2+1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TC Time of Certification | | (UTC96: extended-epoch UTC) | | (96 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = X + L1+1 + L2+1 + 12 + 4) L symbolizes Length of each Server and Client identifier string. The list of Time Certification records ends with a null length byte: +-+ |0| +-+ A description of the fields of Time Certification records follows: 5.1 Time Certification Server Identifier (2-256 octets) 1. Length field (1 octet) Length specified does not include length of the length field. Null implies the end of the list of Time Certification records (and the end of this record, truncated following this field). 2. TC Server Identifier string (Variable: 1-255 octets) 1. Server Organization Name + Separator (":") (optional) 2. + Server Identifier string proper Examples of information which could go in this field: o DNS Server, ASCII name o Raw IP address o Other (thumbprint or the like) McNeil, Glassey expires November 17, 1999 [Page 24] Internet-Draft 17 May 1999 5.2 Time Certification Client Identifier (1-256 octets) 1. Length field (1 octet) Length specified does not include length of the length field. 2. TC Client Identifier string (Variable: 0-255 octets) 1. Client Organization Name + Separator (":") (optional) 2. + Client Identifier string proper Examples of information which could go in this field: o ASCII identifier o Raw IP address o Other (thumbprint or the like) 5.3 Time Certification Record Identifier (12 octets) Uniquely identifies the Trusted Time Certification record on the Server for the certification supporting the time within a Reply Token. The Record Identifier is stated using the 96-bit extended UTC time format, specifying the moment on the Server at which the indicated Trusted Time Certification occurred. Structure of Time Certification time in 96-bit extended UTC format: 1. 64-bit extended-epoch UTC seconds count (8 octets) 2. 32-bit NTP-style 2^(-32) UTC fractional seconds (4 octets) 5.4 Time Certification Network Identifier (4 octets) Identifies the network method used by the Time Certification Server to certify time on the Time Certification Client. Network types supported for time certification include: o ACTS (Automated Computer Time Services) McNeil, Glassey expires November 17, 1999 [Page 25] Internet-Draft 17 May 1999 6. Signature (0-1024 octets) The final portion of both the Basic Event Representation Token (BERT) Reply Token and Request Token (the only portion of the two token types not cryptographically signed) is the Signature. The Signature is laid out in the format the public-key infrastructure cryptographic algorithm in use specifies. If the Token is not signed (as indicated within its Status field), the Signature field is null. A maximum of 1024 octets is allocated for the Signature, which may occupy less space. As an example of perhaps more normal utilization, using (say) the RSA algorithm with 2048-bit public-key encryption produces a signature field which is 256 octets in size. The Signature for BERT Request and Reply Tokens consists of a one- way hash (also known as message digest) computed based on the contents of the Token, derived from token data via a supported one- way hash algorithm. The hash data is thereafter encrypted according to the PKI certificate (algorithm plus private key) of the signer (Timebase for the Reply, Host API for Request). Most PKI toolkits place more information in the Signature than the encrypted hash. The total length of the data stored in the Signature field (i.e., the signature for the Token) is determined by the PKI algorithm and key size specified by the certificate used to sign Token. The Signature field for the Request Token is normally stripped away after verifying it and before encapsulating the Request within the Reply and appending the Reply TokenÆs Signature field to the end. Supported one-way hash/message digest algorithms include: O MD5 O SHA-1 Supported public-key encryption algorithms for Signature include: O RSA O DSA McNeil, Glassey expires November 17, 1999 [Page 26] Internet-Draft 17 May 1999 7. The Time Coordinate The following table illustrates the overall structure of the UTC96 time representation format (see the Appendix in section 9 for a discussion of properties and considerations regarding this system): +-+-------------------+---------------------+---------------------+ | | Time: | Time: | Time: | |R| High-Order UTC | Low-Order UTC | UTC Fractional | |e| Seconds Count | Seconds Count | Seconds | |s| (Epoch Word) | (NTP Style) | (NTP Style) | | | (31 Bits) | (32 Bits) | (32 Bits) | +-+-------------------+---------------------+---------------------+ | | Precision (32 Bits) | | Leap Second Count |----+----------------| | |Time| Reserved | | (32 Bits *) | | | | |(8*)| (24 Bits) | +---------------------+----+----------------+ *Indicates signed numeric values; all others are unsigned numeric. Res indicates Reserved bit (must be 0). The Leap Second Count and Precision fields are optional and may not appear in all usages of UTC96. Ditto for the spatial coordinates. Following is a bit-wise representation of the UTC96 Time fields: (Offset = 24) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | UTC Time (96) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leap Second Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Precision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 44) Following is a description of the fields of the UTC96 Time format: McNeil, Glassey expires November 17, 1999 [Page 27] Internet-Draft 17 May 1999 7.1 UTC Time (12 octets) Representation of the time of the Timebase at the moment that the Reply Token was issued. The time format is a binary 96-bit (12 octet) extended-epoch UTC seconds count, including 32 bits of fractional seconds. The highest order bit (bit 63) is reserved and must contain 0. The UTC Time is thus an unsigned numeric value. 1. Reserved bit; must be 0 (1 bit) 2. 63-bit extended-epoch UTC seconds count (~8 octets) 3. 32-bit NTP-style 2^(-32) UTC fractional seconds (4 octets) A bit-wise diagram of the fields within the UTC Time follows: (Offset = 24) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| High-Order UTC Time seconds count (Epoch Word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Low-Order UTC Time seconds count (NTP style) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2^(-32) UTC fractional seconds (NTP style) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 36) R symbolizes the Reserved bit, which must be 0. The Epoch Word appears as follows for Epoch 0 (began in AD 1900): 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R once again symbolizes the Reserved bit. The preceding epoch, Epoch -1 (ended at end of 1899), appears thus: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McNeil, Glassey expires November 17, 1999 [Page 28] Internet-Draft 17 May 1999 7.2 Leap Second Count (4 octets) Leap second count, specifying the (binary) whole-seconds difference between International Atomic Time (TAI) and Coordinated Universal Time (UTC), current at the moment the Reply Token was issued. The value is signed numeric, positive when leap seconds are additive. Leap Second Count and Precision are optional and may not appear in all usages of UTC96. Ditto for the spatial coordinates. If spatial coordinates appear, so also must Leap Second Count and Precision. A bit-wise diagram showing the Leap Second Count field follows: (Offset = 36) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leap Second Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 40) 7.3 Precision (4 octets) Binary representation specifying the degree to which the time in the Reply Token is estimated by the issuing Timebase to be accurate. The format consists of a 1-octet (8-bit) binary signed numeric value (together with 3 octets which are reserved) specifying a particular exponent beyond whose indicated point bits are not meaningful within the UTC Time. For example, a value of 0 specified for Time Precision means the UTC Time is accurate only to approximately a whole second. A value of -30 (minus 30) for the Time Precision, on the other hand, indicates the UTC Time is estimated accurate to about a nanosecond. As with NTP, it is recommended that bits beyond the meaningful limit (in UTC Time and other coordinates) be filled in with random values. 1. Signed numeric value, specifying UTC Time precision (1 octet) 2. Reserved (3 octets) A bit-wise diagram of the structure of the Time Precision follows: (Offset = 40) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time P. | Reserved (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 44) Leap Second Count and Precision are optional and may not appear in all usages of UTC96. Ditto for the spatial coordinates. If spatial coordinates appear, so also must Leap Second Count and Precision. McNeil, Glassey expires November 17, 1999 [Page 29] Internet-Draft 17 May 1999 8. Spatial Coordinates Paired with the requirement for a nonambiguous representation of time, especially the time that the Basic Event Representation Token (BERT) Reply Token was generated, there is the parallel need in certain use models for identifying the location at which the BERT was issued. The UTC96 Time format is thus optionally supplemented with a geographical coordinate representation structure, known as "UTC96 Time and Space format". Following are UTC96Æs dimensions: +-------------+---------------+---------------+--------------------+ | Dimension | Unit | Total Width | Fractional Field + +-------------+---------------+---------------+--------------------+ | Time | Seconds | 96 Bits | 32 Bits | | Latitude | Arc Seconds | 64 Bits | 32 Bits | | Longitude | Arc Seconds | 64 Bits | 32 Bits | | Altitude | Meters | 96 Bits | 32 Bits | +-------------+---------------+---------------+--------------------+ Spatial coordinates are optional and may not appear in all usages of UTC96. Ditto for the Leap Second Count and Precision. If the spatial coordinates appear, so also must Leap Second Count and Precision. Following is a diagram illustrating the overall structure of UTC96Æs Spatial representation format. First is a Precision field congruent with that which ends UTC96Æs Time format, but with the Reserved portion utilized. Following are the spatial coordinates, which are expressed in geocentric terms: latitude, longitude, and altitude. McNeil, Glassey expires November 17, 1999 [Page 30] Internet-Draft 17 May 1999 +---------------------+ | Precision (32 Bits) | |----+-----+-----+----| |Time|Lati |Longi|Alti| | |tude |tude |tude| |(8*)|(8*) |(8*) |(8*)| +-+--+-----+-----+----+---------------------+ | | Latitude | Latitude | |N| | | | | Arc Seconds | Fractional | |S| | Arc Seconds | | | (31 Bits) | (32 Bits) | +-+-------------------+---------------------+ | | Longitude | Longitude | |E| | | | | Arc Seconds | Fractional | |W| | Arc Seconds | | | (31 Bits) | (32 Bits) | +-+-------------------+---------------------+---------------------+ | | Altitude | Altitude | Altitude | |C| | | | | | High-Order Meters | Low-Order Meters | Fractional | |S| | | Meters | | | (31 Bits) | (32 Bits) | (32 Bits) | +---------------------+---------------------+---------------------+ *Indicates signed numeric values; all others are unsigned numeric. N S indicates South/North latitude flag (set => South latitude). E W indicates West/East longitude flag (set => West longitude). C S indicates Sea/Center altitude flag (set => above Sea Level). Following is a bit-wise representation of the UTC96 Spatial fields: (Offset = 40) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Precision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latitude (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Longitude (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Altitude (96) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 72) McNeil, Glassey expires November 17, 1999 [Page 31] Internet-Draft 17 May 1999 The following sections describe the UTC96 Spatial Coordinate fields: 8.1 Precision (4 octets) Binary representation specifying the degree to which the time and geocentric position coordinates in the Reply Token are estimated by the issuing Timebase to be accurate. The format consists of four 1- octet (8-bit) binary signed numeric values which specify, for each of the four time-space coordinates, a particular exponent beyond whose indicated point bits within the given coordinate are not meaningful. For example, a value of 0 specified for Time Precision means the UTC Time is accurate only to approximately a whole second. A value of -30 (minus 30) for the Time Precision, on the other hand, indicates the UTC Time is estimated accurate to about a nanosecond. As with NTP, it is recommended that bits beyond the meaningful limit (in UTC Time and other coordinates) be filled in with random values. 1. Signed numeric value, specifying UTC Time precision (1 octet) 2. Signed numeric value, specifying Latitude precision (1 octet) 3. Signed numeric value, specifying Longitude precision (1 octet) 4. Signed numeric value, specifying Altitude precision (1 octet) A bit-wise diagram of the Time-Space Coordinates Precision follows: (Offset = 40) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time P. | Latitude P. | Longitude P. | Altitude P. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 44) McNeil, Glassey expires November 17, 1999 [Page 32] Internet-Draft 17 May 1999 8.2 Latitude (8 octets) Representation of the latitude of the Timebase at the moment that the Reply Token was issued. The latitude in this field is in a binary 64-bit (8 octet) Arc Seconds representation, including 32 bits of fractional arc seconds. The highest order bit (bit 63) is an "NS flag" indicating South latitude if set, North latitude when not. Latitude (beyond the flag bit) is thus an unsigned numeric value. 1. NS Flag; indicates South latitude if set; North if not (1 bit) 2. 31-bit Arc Seconds of latitude (~4 octets) 3. 32-bit 2^(-32) fractional Arc Seconds (NTP style) (4 octets) Following is a bit-wise diagram of the Latitude Coordinate fields: (Offset = 44) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Arc Seconds of Latitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2^(-32) fractional Arc Seconds (NTP style) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 52) F symbolizes the NS Flag bit. 8.3 Longitude (8 octets) Representation of the longitude of the Timebase at the moment that the Reply Token was issued. The longitude in this field is in a binary 64-bit (8 octet) Arc Seconds representation, including 32 bits of fractional arc seconds. The highest order bit (bit 63) is an "EW flag" indicating West longitude if set; East longitude when not. Longitude (beyond the flag bit) is thus an unsigned numeric value. 1. EW Flag; indicates West Longitude if set; East if not (1 bit) 2. 31-bit Arc Seconds of Longitude (~4 octets) 3. 32-bit 2^(-32) fractional Arc Seconds (NTP style) (4 octets) Following is a bit-wise diagram of the Longitude Coordinate fields: (Offset = 52) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Arc Seconds of Longitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2^(-32) fractional Arc Seconds (NTP style) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 60) F symbolizes the EW Flag bit. McNeil, Glassey expires November 17, 1999 [Page 33] Internet-Draft 17 May 1999 8.4 Altitude (12 octets) Representation of the TimebaseÆs altitude at the moment the Reply Token was issued. The altitude appearing within this field is in a binary 96-bit (12 octet) meters representation, including 32 bits of fractional meters. The highest order bit (bit 95) is a "CS flag" indicating, when set, that the Altitude shown in the remaining bits is relative to Sea Level, and therefore is a signed numeric value. When not set, this flag indicates the Altitude is relative to the Center of the Earth, and thus is always an unsigned numeric value 1. CS Flag; above Sea Level if set; Center of Earth if not (1 bit) 2. 63-bit altitude (with regard to flag) in Meters (~8 octets) 3. 32-bit NTP-style 2^(-32) fractional Meters (4 octets) Following is a bit-wise diagram of the Altitude Coordinate fields: (Offset = 60) 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| High-Order Meters of Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Low-Order Meters of Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2^(-32) fractional Meters (NTP style) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Offset = 72) F symbolizes the CS Flag bit. McNeil, Glassey expires November 17, 1999 [Page 34] Internet-Draft 17 May 1999 9. Appendix: Time Representation 9.1 NTP time representation format The Network Time Protocol [ , ] (NTP)Æs 64-bit time representation format has several useful properties, such as the ability to compare two UTC times for the difference in seconds between them (ignoring leap seconds) by performing a single 64-bit binary subtraction. The NTP time format, however, includes the ability to express time down to (small) fractions of a second, so allowing whole-second errors (due to leap seconds) to be introduced every now and then is unwelcome. Also, the 32-bit seconds count portion of the NTP time format is only capable of registering a unique count for 136 years. The present count, which for NTP originates in the year 1900 (the year against which the length of the second was defined), will roll over in a millennium-type problem in AD 2036. While an encompassing representation is unimportant for conveying the present time, for representing time with longer lasting value, such as in timestamps, or to satisfy the occasional need to represent dates outside the present epoch, an improved time representation format is in order. 9.2 UTC96 time format Taking a large cue from D. J. BernsteinÆs "TAI64" time format [ ], based on a 64-bit TAI (International Atomic Time) seconds count, NTPÆs 32-bit count was extended in analogous fashion to produce "UTC64". Epoch 0 in UTC64 is defined as the standard NTP epoch beginning at 00:00:00 UTC on January 1, 1900, for the low-order 32- bit second count of UTC64. The high-order 32 bits (the Epoch Word) of UTC64 has a high-order bit (bit 1, or the next to highest bit) set at onset of Epoch 0, while the highest order bit 0 is reserved. Discarding for ease of computation BernsteinÆs TAI64N and TAI64NA fractional systems; appending NTPÆs 32-bit 2^(-32) UTC fractional- seconds to UTC64 produces "UTC96": a system consisting of an epoch- oriented, 64-bit UTC seconds count with 32-bit fractional seconds. The resulting UTC96 system has the desirable property that any two dates and times can be represented in it (with fractional seconds expressible to below the nanosecond) from, in principle, prior to the Big Bang (a probably meaningless concept) to well after the likely end of the universe (i.e., beyond 146 x 10^9 years in the future), without making use of the reserved bit in the epoch word. Although the UTC96 format eliminates the 32-bit UTC seconds countÆs vulnerability to a 136-year "millennium" problem (by adding a whole upper range of available epochs), 96-bit UTC96 alone, however, does not resolve the probability that whole-seconds time comparison error may result when leap seconds have occurred between two given times. McNeil, Glassey expires November 17, 1999 [Page 35] Internet-Draft 17 May 1999 9.3 Leap Second Count and Precision Additional information must be included with the UTC time to resolve this issue. This would be the instantaneous count of leap seconds, which identifies the difference between UTC seconds for a given time and International Atomic Time (TAI). TAI time does increase strictly monotonically into the future. To provide this added information, UTC96 format includes a 32-bit optional Leap Second Count field. For the purpose of expressing the degree to which times in UTC96 are accurate (the point beyond which bits in the time representation cease being meaningful), UTC96 includes an optional Precision field for expressing this via an indicator of binary order of magnitude. McNeil, Glassey expires November 17, 1999 [Page 36] Internet-Draft 17 May 1999 10. Security Considerations The Basic Event Representation Token (BERT) is a technology-specific mechanism that may need addressing when supported key lengths become less than sufficient to support the required level of security. The BERT is not intended to be anything other than a specific token structure. Appropriate use models are required. 11. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992. [3] Mills, D., "Simple Network Time Protocol (SNTP) Version 4", RFC 2030, October 1996. [4] Bernstein, D. J., "TAI64", March 22, 1998, See ftp://koobera.math.uic.edu/www/lists.html; see also ftp://koobera.math.uic.edu/www/djb.html. 12. Author's Addresses Michael E. McNeil GMT PO Box 66301 Scotts Valley, CA 95067-6301 USA Phone: +1-831-335-2069 Email: Michael.McNeil@GMTsw.com Todd S. Glassey GMT PO Box 66301 Scotts Valley, CA 95067-6301 USA Phone: +1-831-438-7811 Email: Todd.Glassey@GMTsw.com McNeil, Glassey expires November 17, 1999 [Page 37] Internet-Draft 17 May 1999 13. Full Statement "Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." McNeil, Glassey expires November 17, 1999 [Page 38]