RFC 4049

BinaryTime 🦋 An Alternate Format for Representing Date and Time in ASN.1

• 🎀 RFC: 4049
• 💅 Author: R. Housley, Vigil Security
• 🔥 Category: Experimental
• 🌸 Date: April 2005
• ✨ Obsoletes / Updates: nothing is listed in this header

---

Status of This Memo 📜

okay so this memo defines an Experimental Protocol for the Internet community. it is NOT an Internet standard of any kind 🙈 the IETF wants feedback and suggestions for improvement, and the memo can be distributed freely with no limits 💖

Copyright Notice ©️

Copyright (C) The Internet Society (2005).

Abstract 🧚

this doc introduces a brand new ASN.1 type for time, called BinaryTime 🌈 it also gives you an alternative to the signing-time attribute for Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types. that alternative is called the binary-signing-time attribute, and it uses BinaryTime. CMS and the signing-time attribute are both defined in RFC 3852 💜

1. Introduction 🎀

the big news is a new ASN.1 [ASN1] type for representing time: BinaryTime 🫶 it can hold date and time values.

this doc also offers an alternative to the signing-time attribute used with the Cryptographic Message Syntax (CMS) [CMS] SignedData and AuthenticatedData content types. with it, BinaryTime can be used instead of the old-school UTCTime and GeneralizedTime types 👑

1.1. BinaryTime 🍓

lots of operating systems store date and time as an integer 💅 this doc defines an ASN.1 type that is also an integer. some conversion might be needed, because of a different epoch or a different granularity, but an integer representation has some serious perks over UTCTime and GeneralizedTime:

First, a BinaryTime value is smaller than either a UTCTime or a GeneralizedTime value. tiny and iconic 🦋

Second, on some operating systems the value can be used with little or no conversion. when conversion is needed, it's just straightforward math. if the endian ordering differs from the ASN.1 representation of an INTEGER, you do some straightforward manipulation to get an equivalent integer value. if the epoch is different from the one chosen for BinaryTime, you add or subtract to compensate. if the granularity is something other than seconds, you multiply or divide to compensate. padding may also be needed to turn the variable-length ASN.1 encoding of INTEGER into the fixed-length value the operating system uses ✨

Third, date comparison is super easy with BinaryTime. integer comparison is easy, even when multi-precision integers are involved. comparing UTCTime or GeneralizedTime values can get messy when the two values are given in different time zones 🙄

this is a rare case where you save both memory AND processor cycles. slay 💖

1.2. Binary Signing Time Attribute 🌸

the signing-time attribute is defined in [CMS]. the alternative binary-signing-time attribute is defined in this doc so you can get all the BinaryTime benefits 🎀

1.3. Terminology 📖

in this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS] 🫶

2. BinaryTime Definition 🧚‍♀️

the BinaryTime ASN.1 type represents an absolute time and date. a positive integer value represents time values based on coordinated universal time (UTC), which is also called Greenwich Mean Time (GMT) and ZULU clock time 🌍

the syntax for BinaryTime is:

BinaryTime ::= INTEGER (0..MAX)

the integer value is the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. this format can NOT represent times before January 1, 1970 🙈 the latest UTC time that fits in a four-octet integer is 03:14:07 on January 19, 2038, which is the hexadecimal value 7FFFFFFF 💀 times after 03:14:07 on January 19, 2038 are stored as integer values longer than four octets. a five-octet integer is enough to cover the next seventeen millennia 😭

this spec uses a variable-length encoding of INTEGER. that means any time after midnight UTC, January 1, 1970 can be represented 💅

when encoding an integer value made of more than one octet (which covers almost every time value anyone cares about), the bits of the first octet and bit 8 of the second octet MUST NOT all be ones or all be zeros. this keeps every integer in the smallest possible number of octets ✨ the tradeoff is that implementations CANNOT assume a fixed length for the integer value, so be ready for that 🎀

3. Binary Signing Time Attribute Definition 🦋

the binary-signing-time attribute type says when the signer (allegedly) did the signing 🔥 it's meant for the CMS SignedData content type, but it can also be used with the AuthenticatedData content type 💜

the binary-signing-time attribute MUST be a signed attribute or an authenticated attribute. it MUST NOT be an unsigned attribute, an unauthenticated attribute, or an unprotected attribute 🫶

the following object identifier identifies the binary-signing-time attribute:

id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) aa(2) 46 }

binary-signing-time attribute values have the ASN.1 type BinarySigningTime:

BinarySigningTime ::= BinaryTime

in [CMS], the SignedAttributes syntax and the AuthAttributes syntax are each defined as a SET OF Attributes. but the binary-signing-time attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. there MUST NOT be zero instances or multiple instances of AttributeValue present 🙅‍♀️

the SignedAttributes in the signerInfo structure inside SignedData MUST NOT include multiple instances of the binary-signing-time attribute. same deal for the AuthAttributes in an AuthenticatedData: they MUST NOT include multiple instances of the binary-signing-time attribute 👑

no requirement is imposed on whether the signing time itself is correct. accepting a purported signing time is up to the recipient's discretion 🌈 it is expected, though, that some signers, like time-stamp servers, will be trusted implicitly 🧚

4. References 📚

this section has normative and informative references.

4.1. Normative References

• [ASN1] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
• [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
• [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

4.2. Informative References

• [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.

5. Security Considerations 🚨

this part is SERIOUS, bestie 😭 using the binary-signing-time attribute does NOT automatically give you confidence in when the signature value was produced 💀 so accepting a purported signing time is up to the recipient's discretion. RFC 3161 [TSP] describes a protocol for getting time stamps from a trusted entity 🔐

the original signing-time attribute defined in [CMS] has the same semantics as the binary-signing-time attribute in this doc. so only one of these attributes SHOULD be present in the signedAttrs of a SignerInfo object or in the authAttrs of an AuthenticatedData object. BUT if both are present, they MUST provide the same date and time. no mismatched timestamps allowed, periodt 💅

Appendix A: ASN.1 Module 💖

the ASN.1 module in this appendix defines the structures you need to implement this spec. it's meant to be used together with the ASN.1 modules in [CMS] 🧚

BinarySigningTimeModule
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) 27 }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN


-- BinaryTime Definition

BinaryTime ::= INTEGER (0..MAX)

-- Signing Binary Time Attribute

id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) aa(2) 46 }

BinarySigningTime ::= BinaryTime

END

Author's Address 🎀

Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA

EMail: housley@vigilsec.com

Full Copyright Statement 🌈

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🔮

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. it also doesn't say it has made any independent effort to identify such rights. info on how RFC documents handle rights is in BCP 78 and BCP 79 📜

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 💜

funding for the RFC Editor function is currently provided by the Internet Society 🫶✨