PKIX Working Group Michael E. McNeil
Internet Draft GMT
Document: <draft-pkix-bert1-00.txt> Todd S. Glassey
Category: Informational GMT
Expires in six months: 17 November 1999 17 May 1999
Basic Event Representation Token v1
<draft-ietf-pkix-bert1-00.txt>
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]