BinaryTime: An Alternate Format for Representing Date and Time in ASN.1
obsoletes
- rfc-4049 — BinaryTime: An Alternate Format for Representing Date and Time in ASN.1
Extracted elements (15)
BinaryTime was chosen over UTCTime and GeneralizedTime because: (1) it produces smaller encoded values, (2) it maps directly to OS integer representations with only straightforward arithmetic conversion, and (3) integer comparison for date ordering is simpler than comparing UTC/GeneralizedTime strings across time zones.
The UNIX epoch (midnight UTC, January 1, 1970) was chosen as the BinaryTime reference point because most operating systems represent time relative to this epoch, minimizing conversion overhead for implementers.
BinaryTime cannot represent time values prior to January 1, 1970, which limits backward compatibility with historical timestamps. Implementations requiring pre-1970 dates must use UTCTime or GeneralizedTime.
The binary-signing-time attribute has the same semantics as the CMS signing-time attribute from RFC 5652; they are interchangeable representations of the same information and must agree if both appear together.
Only one of signing-time or binary-signing-time SHOULD be present in the signedAttrs of a SignerInfo or in the authAttrs of an AuthenticatedData object, since they carry the same semantics.
The binary-signing-time attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute.
The binary-signing-time attribute MUST have exactly one attribute value; there MUST NOT be zero or multiple instances of AttributeValue present within the SET OF AttributeValue.
The SignedAttributes in a signerInfo structure within SignedData MUST NOT include multiple instances of the binary-signing-time attribute; the same restriction applies to AuthAttributes in AuthenticatedData.
When encoding a multi-octet BinaryTime integer, the bits of the first octet and bit 8 of the second octet MUST NOT all be ones or all zeros, ensuring the integer is always encoded in the smallest possible number of octets.
BinaryTime is defined as an ASN.1 INTEGER (0..MAX) representing the number of seconds excluding leap seconds after midnight UTC, January 1, 1970 (UNIX epoch). It uses variable-length encoding and cannot represent dates prior to January 1, 1970.
The binary-signing-time attribute is identified by OID id-aa-binarySigningTime ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 46 }.
The binary-signing-time attribute specifies the time at which the signer purportedly performed the signing process, for use with CMS SignedData and AuthenticatedData content types. Its ASN.1 type BinarySigningTime is a direct alias for BinaryTime.
If both the original CMS signing-time attribute and the binary-signing-time attribute are present in signedAttrs or authAttrs, they MUST provide the same date and time. Only one of these attributes SHOULD be present.
Use of the binary-signing-time attribute does not necessarily provide confidence in when the signature value was produced; acceptance of a purported signing time is a matter of the recipient's discretion. RFC 3161 TSP is cited for obtaining trusted timestamps.
BinaryTime uses ASN.1 variable-length INTEGER encoding. A four-octet value can represent times up to 03:14:07 on January 19, 2038 (0x7FFFFFFF); a five-octet integer suffices for the next seventeen millennia beyond that.