idnits 2.17.00 (12 Aug 2021) /tmp/idnits24540/draft-housley-binarytime-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 242. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 283), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 283. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 97: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 98: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 128: '... 8 of the second octet MUST NOT all be...' RFC 2119 keyword, line 142: '...g-time attribute MUST be a signed attr...' RFC 2119 keyword, line 143: '...ed attribute; it MUST NOT be an unsign...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 6450 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ASN1' on line 47 looks like a reference -- Missing reference section? 'CMS' on line 258 looks like a reference -- Missing reference section? 'STDWORDS' on line 100 looks like a reference -- Missing reference section? 'TSP' on line 201 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Housley 2 Internet Draft Vigil Security 3 expires in six months September 2004 5 BinaryTime: 6 An alternate format for representing date and time in ASN.1 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft is intended to be published as an Experimental 34 RFC. 36 Abstract 38 This document specifies a new ASN.1 type for representing time: 39 BinaryTime. This document also specifies an alternate to the 40 signing-time attribute for use with the Cryptographic Message Syntax 41 (CMS) SignedData and AuthenticatedData content types; the binary- 42 signing-time attribute uses BinaryTime. CMS and the signing-time 43 attribute are defined in RFC 3852. 45 1 Introduction 47 This document specifies a new ASN.1 [ASN1] type for representing 48 time: BinaryTime. This ASN.1 type can be used to represent date and 49 time values. 51 This document also specifies an alternative to the signing-time 52 attribute used with the Cryptographic Message Syntax (CMS) [CMS] 53 SignedData and AuthenticatedData content types, allowing the 54 BinaryTime type to be used instead of the traditional UTCTime and 55 GeneralizedTime types. 57 1.1 BinaryTime 59 Many operating systems represent date and time as an integer. This 60 document specifies an ASN.1 type for representing a date and time in 61 a manner that is also an integer. While some conversion may be 62 necessary due to the selection of different epoch or a different 63 granularity, an integer representation has several advantages over 64 the UTCTime and GeneralizedTime types. 66 First, a BinaryTime value is smaller than either a UTCTime or a 67 GeneralizedTime value. 69 Second, in some operating systems, the value can be used with little 70 or no conversion. Conversion, when it is needed, requires only 71 straightforward computation. If the endian ordering is different 72 than the ASN.1 representation of an INTEGER, then straightforward 73 manipulation is needed to obtain an equivalent integer value. If the 74 epoch is different than the one chosen for BinaryTime, addition or 75 subtraction is needed to compensate. If the granularity is something 76 other than seconds, then multiplication or division is needed to 77 compensate. Also, padding may be needed convert the variable length 78 ASN.1 encoding of INTEGER to a fixed length value used in the 79 operating system. 81 Third, date comparison is very easy with BinaryTime. Integer 82 comparison is easy, even when multi-precision integers are involved. 83 Date comparison with UTCTime or GeneralizedTime can be complex when 84 the two values to be compared are provided in different time zones. 86 This is a rare instance where both memory and processor cycles can be 87 saved. 89 1.2 Binary Signing Time Attribute 91 The signing-time attribute is defined in [CMS]. The alternative 92 binary-signing-time attribute is defined in this document to obtain 93 the benefits of the BinaryTime type. 95 1.3 Terminology 97 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 98 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 99 described in [STDWORDS]. 101 2 BinaryTime Definition 103 The BinaryTime ASN.1 type is used to represent an absolute time and 104 date. A positive integer value is used to represent time values 105 based on coordinated universal time (UTC), which is also called 106 Greenwich Mean Time (GMT) and ZULU clock time. 108 The syntax for BinaryTime is: 110 BinaryTime ::= INTEGER 112 The integer value is the number of seconds after midnight UTC, 113 January 1, 1970. This time format cannot represent time values prior 114 to January 1, 1970. The latest UTC time value that can be 115 represented by a four-octet integer value is 03:14:07 on January 19, 116 2038, which is represented by the hexadecimal value 7FFFFFFF. Time 117 values beyond 03:14:07 on January 19, 2038 are represented by integer 118 values that are longer than four octets, and a five-octet integer 119 value is sufficient to represent dates covering the next seventeen 120 millennia. 122 This specification uses a variable length encoding of INTEGER. This 123 permits any time value after midnight UTC, January 1, 1970 to be 124 represented. 126 When encoding of an integer value that consists of more than one 127 octet, which includes almost all of the time values of interest, the 128 bits of the first octet and bit 8 of the second octet MUST NOT all be 129 ones or all zeros. This rule ensures that an integer value is always 130 encoded in the smallest possible number of octets. However, it means 131 that implementations cannot assume a fixed length for the integer 132 value. 134 3 Binary Signing Time Attribute Definition 136 The binary-signing-time attribute type specifies the time at which 137 the signer (purportedly) performed the signing process. The binary- 138 signing-time attribute type is intended for use in the CMS SignedData 139 content type; however, the attribute can also be used with the 140 AuthenticatedData content type. 142 The binary-signing-time attribute MUST be a signed attribute or an 143 authenticated attribute; it MUST NOT be an unsigned attribute, 144 unauthenticated attribute, or unprotected attribute. 146 The following object identifier identifies the binary-signing-time 147 attribute: 149 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 150 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 151 smime(16) aa(2) 46 } 153 The binary-signing-time attribute values have ASN.1 type 154 BinarySigningTime: 156 BinarySigningTime ::= BinaryTime 158 In [CMS], the SignedAttributes syntax and the AuthAttributes syntax 159 are each defined as a SET OF Attributes. However, the binary- 160 signing-time attribute MUST have a single attribute value, even 161 though the syntax is defined as a SET OF AttributeValue. There MUST 162 NOT be zero or multiple instances of AttributeValue present. 164 The SignedAttributes contained in the signerInfo structure within 165 SignedData MUST NOT include multiple instances of the binary-signing- 166 time attribute. Similarly, the AuthAttributes in an 167 AuthenticatedData MUST NOT include multiple instances of the binary- 168 signing-time attribute. 170 No requirement is imposed concerning the correctness of the signing 171 time itself, and acceptance of a purported signing time is a matter 172 of a recipient's discretion. It is expected, however, that some 173 signers, such as time-stamp servers, will be trusted implicitly. 175 4 References 177 This section provides normative and informative references. 179 4.1 Normative References 181 ASN1 CCITT. Recommendation X.208: Specification of Abstract 182 Syntax Notation One (ASN.1). 1988. 184 CMS Housley, R. Cryptographic Message Syntax. RFC 3852. 185 July 2004. 187 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 188 Requirement Levels. RFC 2119. March 1997. 190 4.2 Informative References 192 TSP Adams, C., P. Cain, D. Pinkas, and R. Zuccherato. 193 Internet X.509 Public Key Infrastructure Time-Stamp 194 Protocol (TSP). RFC 3161. August 2001. 196 5 Security Considerations 198 Use of the binary-signing-time attribute does not necessarily provide 199 confidence in the time that the signature value was produced. 200 Therefore, acceptance of a purported signing time is a matter of a 201 recipient's discretion. RFC 3161 [TSP] specifies a protocol for 202 obtaining time stamps from a trusted entity. 204 The original signing-time attribute defined in [CMS] has the same 205 semantics as the binary-signing-time attribute specified in this 206 document. Therefore, only one of these attributes SHOULD be present 207 in the signedAttrs of a SignerInfo object or in the authAttrs of an 208 AuthenticatedData object. However, if both of these attributes are 209 present, they MUST provide the same date and time. 211 6 IANA Considerations 213 No IANA actions are needed. 215 7 IPR Considerations 217 By submitting this Internet-Draft, I certify that any applicable 218 patent or other IPR claims of which I am aware have been disclosed, 219 or will be disclosed, and any of which I become aware will be 220 disclosed, in accordance with RFC 3668. 222 The IETF takes no position regarding the validity or scope of any 223 Intellectual Property Rights or other rights that might be claimed to 224 pertain to the implementation or use of the technology described in 225 this document or the extent to which any license under such rights 226 might or might not be available; nor does it represent that it has 227 made any independent effort to identify any such rights. Information 228 on the procedures with respect to rights in RFC documents can be 229 found in BCP 78 and BCP 79. 231 Copies of IPR disclosures made to the IETF Secretariat and any 232 assurances of licenses to be made available, or the result of an 233 attempt made to obtain a general license or permission for the use of 234 such proprietary rights by implementers or users of this 235 specification can be obtained from the IETF on-line IPR repository at 236 http://www.ietf.org/ipr. 238 The IETF invites any interested party to bring to its attention any 239 copyrights, patents or patent applications, or other proprietary 240 rights that may cover technology that may be required to implement 241 this standard. Please address the information to the IETF at ietf- 242 ipr@ietf.org. 244 8 Author's Address 246 Russell Housley 247 Vigil Security, LLC 248 918 Spring Knoll Drive 249 Herndon, VA 20170 250 USA 252 housley@vigilsec.com 254 Appendix A: ASN.1 Module 256 The ASN.1 module contained in this appendix defines the structures 257 that are needed to implement this specification. It is expected to 258 be used in conjunction with the ASN.1 modules in [CMS]. 260 BinarySigningTimeModule 261 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 262 pkcs-9(9) smime(16) modules(0) 27 } 264 DEFINITIONS IMPLICIT TAGS ::= 265 BEGIN 267 -- BinaryTime Definition 269 BinaryTime ::= INTEGER 271 -- Signing Binary Time Attribute 273 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 274 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 275 smime(16) aa(2) 46 } 277 BinarySigningTime ::= BinaryTime 279 END 281 Full Copyright Statement 283 Copyright (C) The Internet Society (2004). All Rights Reserved. 285 This document and translations of it may be copied and furnished to 286 others, and derivative works that comment on or otherwise explain it 287 or assist in its implementation may be prepared, copied, published 288 and distributed, in whole or in part, without restriction of any 289 kind, provided that the above copyright notice and this paragraph are 290 included on all such copies and derivative works. However, this 291 document itself may not be modified in any way, such as by removing 292 the copyright notice or references to the Internet Society or other 293 Internet organizations, except as needed for the purpose of 294 developing Internet standards in which case the procedures for 295 copyrights defined in the Internet Standards process must be 296 followed, or as required to translate it into languages other than 297 English. 299 This document and the information contained herein is provided on an 300 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 301 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 302 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 303 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 304 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.