idnits 2.17.1 draft-ietf-ltans-pki-retention-01.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (October 23, 2006) is 6388 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) == Unused Reference: 'I-D.ietf-pkix-scvp' is defined on line 222, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ltans-ers-07 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) == Outdated reference: A later version (-07) exists of draft-ietf-ltans-ers-scvp-01 == Outdated reference: A later version (-33) exists of draft-ietf-pkix-scvp-27 -- Obsolete informational reference (is this intentional?): RFC 2559 (Obsoleted by RFC 3494) -- Obsolete informational reference (is this intentional?): RFC 2587 (Obsoleted by RFC 4523) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Long-term Archive And Notary C. Wallace 3 Services (LTANS) Cygnacom Solutions 4 Internet-Draft October 23, 2006 5 Expires: April 26, 2007 7 Infrastructure Support for Retention of PKI Artifacts 8 draft-ietf-ltans-pki-retention-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 In most PKIs, directory servers are used to provide current 42 certificates and revocation information to relying parties. In 43 situations where certificates must be validated relative to a time in 44 the past, relying parties often have no means of obtaining the 45 necessary PKI artifacts. This specification defines several 46 directory attributes to support validation using historical PKI 47 artifacts. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 4 54 3. Object classes . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Public key certificates . . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 60 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 61 Appendix B. Revocation information . . . . . . . . . . . . . . . 10 62 B.1. Historical CRLs . . . . . . . . . . . . . . . . . . . . . 10 63 B.2. Entry Revocation Publication extension . . . . . . . . . . 11 64 B.3. Historical CRL issuance extension . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 Intellectual Property and Copyright Statements . . . . . . . . . . 14 68 1. Introduction 70 Digital signatures are frequently verified using public key 71 infrastructure (PKI) artifacts such as public key certificates and 72 certificate revocation lists (CRLs). Verifiers construct and 73 validate certification paths from a public key certificate containing 74 the public key used to verify the signature to a trusted public key. 75 Construction of a certification path may require acquisition of 76 different types of information generated by multiple PKIs. When 77 verifying digital signatures many years after signature generation, 78 additional considerations must be addressed. For example, some 79 necessary PKI artifacts may no longer be available, some may have 80 expired and the cryptographic algorithms or keys used in generating 81 digital signatures may no longer provide the desired degree of 82 security. 84 The "Standard Certificate Validation Protocol" (SCVP) [I-D.ietf-pkix- 85 scvp] defines a means of delegating certification path construction 86 and/or validation to a server, including the ability to request the 87 server to perform the operations relative to a time in the past. The 88 "Evidence Record Syntax" (ERS) [I-D.ietf-ltans-ers] defines 89 structures for preserving materials over long periods of time through 90 a regimen that includes periodic re-signing of relevant materials 91 using newer keys and stronger cryptographic algorithms. "Using SCVP 92 to Convey Evidence Records" [I-D.ietf-ltans-ers-scvp] defines a means 93 of using SCVP to retrieve evidence records covering historical PKI 94 artifacts. 96 Directory servers are frequently used to make PKI artifacts available 97 for use by public key-enabled applications. However, in many PKIs, 98 artifacts are removed from the directory when the artifact is updated 99 by a newer version or the artifact expires. This document describes 100 a means of using LDAP or X.500 directory servers to retrieve 101 historical PKI artifacts and, optionally, associated evidence 102 records. 104 1.1. Requirements notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Concept of Operations 112 Public key-enabled applications build and validate certification 113 paths in support of functions including digital signature 114 verification and public key encryption. In many cases, the materials 115 used to validate a certification path are available via an X.500 or 116 LDAP directory in accord with the schema defined in [RFC2587]. For 117 many reasons, including size constraints on the server and 118 performance impact on relying parties, directories usually contain 119 PKI artifacts that are current, i.e., non-expired and most recent. 120 Applications requiring access to historical PKI artifacts, i.e., not 121 the most recent and possibly expired, are forced to rely upon other 122 mechanisms. This document defines an object class and a set of 123 directory attributes that complement those defined in [RFC2587] for 124 the purpose of making historical PKI artifacts available. 126 3. Object classes 128 Two object classes are defined for historical certificates and CRLs: 129 historicalPKIEntity and historicalCRLDistributionPoint. These 130 auxiliary object classes MAY be used to represent entities associated 131 with historical PKI artifacts. 133 historicalPKIEntity OBJECT-CLASS ::= 134 { 135 SUBCLASS OF {top} 136 KIND auxiliary 137 MAY CONTAIN {historicalCertificate} 138 ID TBD 139 } 140 historicalCRLDistributionPoint OBJECT-CLASS ::= 141 { 142 SUBCLASS OF {top} 143 KIND auxiliary 144 MAY CONTAIN {historicalCRL} 145 ID TBD 146 } 148 This specification differs from [RFC2587] by not defining separate 149 object classes or attributes to delineate between end entities and 150 certification authorities. 152 4. Public key certificates 154 Public key certificates are digitally signed. As such, certificates 155 are subject to the same concerns as described for digitally signed 156 forms, contracts, etc. in [I-D.ietf-ltans-ers]. To address these 157 concerns, the integrity of public key certificates can be protected 158 by generating and maintaining an evidence record covering the 159 certificate. A certificate and an evidence record can be bound 160 together using the structure defined below. Certificates are defined 161 in [RFC3280] and evidence records are defined in [I-D.ietf-ltans- 162 ers]. 164 HistoricalCertificate ::= SEQUENCE 165 { 166 certificate Certificate, 167 evidenceRecord EvidenceRecord OPTIONAL 168 } 170 HistoricalCertificates can be made available via an X.500 or LDAP 171 directory using the following attribute. When a certificate is to be 172 removed from a directory due to replacement or due to expiration, it 173 MAY be removed from the userCertificate or cACertificate attribute 174 and it SHOULD be added to the historicalCertificate attribute. An 175 evidence record for the certificate MAY be requested at that time or 176 at a later time. 178 historicalCertificate ATTRIBUTE ::= 179 { 180 WITH SYNTAX HistoricalCertificate 181 EQUALITY MATCHING RULE historicalCertificateExactMatch, 182 ID TBD 183 } 185 5. Security Considerations 187 Since the information stored in the attributes defined in this 188 specification are signed, no additional integrity service is 189 required. 191 Security considerations with respect to retrieval, addition, deletion 192 and modification of the information supported by this schema 193 definition are addressed in [RFC2559]. 195 The timing of the application or update of evidence records is a 196 matter of local policy. Security considerations associated with 197 evidence records are described in [I-D.ietf-ltans-ers]. 199 6. References 201 6.1. Normative References 203 [I-D.ietf-ltans-ers] 204 Brandner, R., "Evidence Record Syntax (ERS)", 205 draft-ietf-ltans-ers-07 (work in progress), May 2006. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 211 X.509 Public Key Infrastructure Certificate and 212 Certificate Revocation List (CRL) Profile", RFC 3280, 213 April 2002. 215 6.2. Informative References 217 [I-D.ietf-ltans-ers-scvp] 218 Wallace, C., "Using SCVP to Convey Long-term Evidence 219 Records", draft-ietf-ltans-ers-scvp-01 (work in progress), 220 May 2006. 222 [I-D.ietf-pkix-scvp] 223 Malpani, A., "Server-based Certificate Validation Protocol 224 (SCVP)", draft-ietf-pkix-scvp-27 (work in progress), 225 June 2006. 227 [RFC2559] Boeyen, S., Howes, T., and P. Richard, "Internet X.509 228 Public Key Infrastructure Operational Protocols - LDAPv2", 229 RFC 2559, April 1999. 231 [RFC2587] Boeyen, S., Howes, T., and P. Richard, "Internet X.509 232 Public Key Infrastructure LDAPv2 Schema", RFC 2587, 233 June 1999. 235 Appendix A. ASN.1 Module 237 LTANS_PKI_RETENTION 238 -- { iso(1) identified-organization(3) dod(6) internet(1) 239 -- security(5) mechanisms(5) pkix(7) id-mod(0) TBD } 241 DEFINITIONS IMPLICIT TAGS ::= 242 BEGIN 244 IMPORTS 246 Certificate, CertificateList, Time 247 FROM PKIX1Explicit88 248 { iso(1) identified-organization(3) dod(6) 249 internet(1) security(5) mechanisms(5) pkix(7) 250 mod(0) pkix1-explicit(18) } 252 EvidenceRecord 253 FROM ERS 254 {iso(1) identified-organization(3) dod(6) internet(1) 255 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ers(TBD) } 257 HistoricalCertificate ::= SEQUENCE 258 { 259 certificate Certificate, 260 evidenceRecord EvidenceRecord OPTIONAL 261 } 263 HistoricalCRL ::= SEQUENCE 264 { 265 crl CertificateList, 266 evidenceRecord EvidenceRecord OPTIONAL 267 } 269 EntryRevocationPublication ::= Time 270 HistoricalCRLIssuance ::= Time 272 END 274 Appendix B. Revocation information 276 Preservation of revocation information is more complicated than 277 preservation of certificates due, primarily, to the volume of 278 revocation information generated in most PKIs, i.e., CRLs are 279 generated more frequently than certificates and are often much 280 larger. CRLs are signed and the signatures require preservation. 281 However, the number of CRLs makes preservation difficult and 282 complicates validation operations for relying parties. A cumulative 283 CRL provides a better target for preservation. However, cumulative 284 CRLs introduce additional processing rules. To account for the 285 HoldInstruction extension, all entries on a CRL must be reviewed, the 286 entries applicable to a certificate sorted and the time of interest 287 compared to the sorted list to determine if the certificate was on 288 hold at that time. 290 X.509 specifies a the expiredCertsOnCRL CRL extension, that is not 291 present in [RFC3280], to indicate that the CRL contains expired 292 certificates. The extension is expressed as a GeneralizedTime value 293 that provides the time at or since which certificates may have 294 expired but will still appear on the CRL, i.e., certificates that 295 expired before that time do not appear on the CRL. Relying parties 296 using a CRL of this sort must recognize that the time of interest for 297 a path validation operation may fall outside the thisUpdate/ 298 nextUpdate period of a cumulative CRL. The following section 299 describes a variation on the X.509 CumulativeCRL extension that 300 preserves the property where thisUpdate is less than or equal to the 301 time of interest and nextUpdate is greater than or equal to the time 302 of interest. 304 B.1. Historical CRLs 306 To avoid preserving every CRL instance generated within a PKI, an 307 historical CRL can be generated and maintained. An historical CRL is 308 a CRL with the following properties: 310 - The thisUpdate field is fixed and contains the time 311 corresponding to the instantiation of the CA(s) covered by the 312 CRL. 314 - Entries optionally include an extension indicating the 315 thisUpdate value from the first CRL on which the entry appeared. 317 - The CRL structure is optionally associated with an 318 EvidenceRecord. 320 Historical CRLs are defined as follows. 322 HistoricalCRL ::= SEQUENCE 323 { 324 crl CertificateList, 325 evidenceRecord EvidenceRecord OPTIONAL 326 } 328 CRL issuers need not generate an historical CRL upon each CRL 329 issuance. Historical CRLs can be generated on a less frequent basis 330 since certification path validation operations relative to the 331 current time can be serviced using conventional CRLs. When an 332 historical CRL is generated, the thisUpdate time MUST NOT change from 333 the value in the previous historical CRL. The new CRL MUST replace 334 the previous historical CRL in the historicalCRL directory attribute. 335 The thisUpdate value in the first historical CRL issued by a CRL 336 issuer SHOULD be set to the earliest notBefore value from the set of 337 certificates issued by the CAs covered by the CRL. After a CA no 338 longer needs to issue CRLs, the final HistoricalCRL can be preserved 339 by periodically updating the evidence record as described in 340 [I-D.ietf-ltans-ers]. 342 For sake of simplicity, historical CRLs should not be indirect CRLs 343 and should not be delta CRLs. Where partitioned, historical CRLs 344 MUST adhere to the partioning scheme used by the corresponding 345 conventional CRLs. 347 B.2. Entry Revocation Publication extension 349 This CRL entry extension identifies the thisUpdate time from the CRL 350 on which the entry first appeared. If this extension is not present 351 on the first entry in a CRL, the revocation publication value 352 defaults to the thisUpdate value of the CRL. On subsequent entries, 353 if this extension is not present, the revocation publication value 354 for the entry is the same as that for the preceding entry. This 355 extension is defined as follows: 357 EntryRevocationPublication ::= Time 359 B.3. Historical CRL issuance extension 361 This optional CRL extension indicates the CRL is an historical CRL, 362 i.e., the thisUpdate time is not based on the time of issuance. The 363 extension is used to convey the issuance time and is defined as 364 follows: 366 HistoricalCRLIssuance ::= Time 368 If used by conforming CRL issuers, this extension MUST always be non- 369 critical. 371 HistoricalCRLs can be made available via an X.500 or LDAP directory 372 using the following attribute. 374 historicalCRL ATTRIBUTE ::= 375 { 376 WITH SYNTAX HistoricalCRL 377 EQUALITY MATCHING RULE historicalCRLExactMatch, 378 ID TBD 379 } 381 Historical CRLs are not intended to replace CRLs used by applications 382 performing certification path validation relative to the current 383 time. CRL issuers should continue to publish conventional CRLs. 385 Author's Address 387 Carl Wallace 388 Cygnacom Solutions 389 Suite 5200 390 7925 Jones Branch Drive 391 McLean, VA 22102 393 Email: cwallace@cygnacom.com 395 Intellectual Property Statement 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Disclaimer of Validity 421 This document and the information contained herein are provided on an 422 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 423 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 424 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 425 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 426 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Copyright Statement 431 Copyright (C) The Internet Society (2006). This document is subject 432 to the rights, licenses and restrictions contained in BCP 78, and 433 except as set forth therein, the authors retain all their rights. 435 Acknowledgment 437 Funding for the RFC Editor function is currently provided by the 438 Internet Society.