idnits 2.17.1 draft-ietf-pkix-crlaia-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. ** 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: ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The abstract seems to indicate that this document updates RFC3280, but the header doesn't have an 'Updates:' line to match this. 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 (February 2006) is 6643 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: 'PKIX1' is mentioned on line 110, but not defined == Unused Reference: 'RFC 3280' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'URI' is defined on line 226, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2587 (Obsoleted by RFC 4523) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2251 (ref. 'LDAP') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2797 (ref. 'CMC') (Obsoleted by RFC 5272) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group S. Santesson (Microsoft) 3 INTERNET-DRAFT R. Housley (Vigil Security) 4 Expires February 2006 5 Updates RFC 3280 August 2005 7 Internet X.509 Public Key Infrastructure 8 Authority Information Access CRL Extension 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document updates RFC 3280 by defining the Authority Information 37 Access Certificate Revocation Lists (CRL) extension. RFC 3280 38 defines the Authority Information Access certificate extension using 39 the same syntax. The CRL extension provides a means of discovering 40 and retrieving CRL issuer certificates. 42 Table of Contents 44 1 Introduction ................................................ 2 45 1.1 Terminology ................................................ 3 46 2 Authority Information Access Extension in CRL ............... 4 47 3 Security Considerations ..................................... 5 48 4 IANA Considerations ......................................... 6 49 5 References .................................................. 6 50 Authors' Addresses ............................................. 7 51 Disclaimer ..................................................... 8 52 IPR Notice ..................................................... 8 53 Copyright Statement ............................................ 8 55 1. Introduction 57 RFC 3280 [PKIX1] specifies the validation of certification paths. 58 One aspect involves the determination that a certificate has not been 59 revoked, and one revocation checking mechanism is the Certificate 60 Revocation List (CRL). CRL validation is also specified in RFC 3280, 61 which involves the constructions of a valid certification path for 62 the CRL issuer. Building a CRL issuer certification path from the 63 signer of the CRL to a trust anchor is straightforward when the 64 certificate of the CRL issuer is present in the certification path 65 associated with the target certificate, but it can be complex in 66 other situations. 68 There are several legitimate scenarios where the certificate of the 69 CRL issuer is not present, or easily discovered, from the target 70 certification path. This can be the case when indirect CRLs are 71 used, when the certification Authority (CA) that issued the target 72 certificate changes its certificate signing key, or when the CA 73 employs separate keys for certificate signing and CRL signing. 75 Methods of finding the certificate of the CRL issuer are currently 76 available, such as though an accessible directory location or through 77 use of the Subject Information Access extension in intermediary CA 78 certificates. 80 Directory lookup requires existence and access to a directory that 81 has been populated with all of the necessary certificates. The 82 Subject Information Access extension, which supports building the CRL 83 issuer certification path top-down (in the direction from the trust 84 anchor to the CRL issuer), requires that some certificates in the CRL 85 issuer certification path includes an appropriate Subject Information 86 Access extension. 88 RFC 3280 [PKIX1] provides for bottom-up discovery of certification 89 paths through the Authority Information Access extension, where the 90 id-ad-caIssuers access method may specify one or more accessLocation 91 fields that reference CA certificates associated with the certificate 92 containing this extension. 94 This document enables the use of the Authority Information Access 95 extension in CRLs, enabling a CRL checking application to use the 96 access method (id-ad-caIssuers) to locate certificates that may be 97 useful in the construction of a valid CRL issuer certification path 98 to an appropriate trust anchor. 100 1.1 Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC 2119]. 106 2. Authority Information Access CRL Extension 108 This section defines the use of the Authority Information Access 109 extension in a CRL. The syntax and semantics defined in RFC 3280 110 [PKIX1] for the certificate extensions are also used for the CRL 111 extension. 113 This CRL extension MUST NOT be marked critical. 115 This extension MUST be identified by the extension object identifier 116 (OID) defined in RFC 3280 (1.3.6.1.5.5.7.1.1), and the 117 AuthorityInfoAccessSyntax MUST be used to form the extension value. 118 For convenience, the ASN.1 [X.680] definition of the Authority 119 Information Access extension is repeated below. 121 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 123 AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF 124 AccessDescription 126 AccessDescription ::= SEQUENCE { 127 accessMethod OBJECT IDENTIFIER, 128 accessLocation GeneralName } 130 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 132 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 134 When present in a CRL, this extension MUST include at least one 135 AccessDescription specifying id-ad-caIssuers as the accessMethod. 136 Access method types other than id-ad-caIssuers MUST NOT be included. 137 At least one instance of AccessDescription SHOULD specify an 138 accessLocation that is an HTTP [HTTP/1.1] or LDAP [LDAP] URI. 140 Where the information is available via HTTP or FTP, accessLocation 141 MUST be a uniformResourceIdentifier and the URI MUST point to a 142 certificate containing file. The certificate file MUST contain 143 either a single DER [X.690] encoded certificate (indicated by the 144 .cer file extension) or a collection of certificates (indicated by 145 the .p7c file extension): 147 .cer A single DER encoded certificate as specified in 148 RFC 2585 [PKIX-CERT]. 150 .p7c A "certs-only" CMS message as specified in RFC 2797 [CMC]. 152 Conforming applications that support HTTP or FTP for accessing 153 certificates MUST be able to accept .cer files and SHOULD be able 154 to accept .p7c files. 156 HTTP server implementations accessed via the URI SHOULD use the 157 appropriate MIME content-type for the certificate containing file. 158 Specifically, the HTTP server SHOULD use the content-type 159 application/pkix-cert [PKIX-CERT] for a single DER encoded 160 certificate and application/pkcs7-mime [CMC] for CMS certs-only 161 (PKCS#7). Consuming clients may use the MIME type and file 162 extension as a hint to the file content, but should not depend 163 solely on the presence of the correct MIME type or file extension 164 in the server response. 166 When the accessLocation is a directoryName, the information is to 167 be obtained by the application from whatever directory server is 168 locally configured. When one CA public key is used to validate 169 signatures on certificates and CRLs, the desired CA certificate is 170 stored in the crossCertificatePair and/or cACertificate attributes 171 as specified in [RFC 2587]. When different public keys are used to 172 validate signatures on certificates and CRLs, the desired 173 certificate is stored in the userCertificate attribute as specified 174 in [RFC 2587]. Thus, implementations that support the directoryName 175 form of accessLocation MUST be prepared to find the needed 176 certificate in any of these three attributes. The protocol that an 177 application uses to access the directory (e.g., DAP or LDAP) is a 178 local matter. 180 Where the information is available via LDAP, the accessLocation 181 SHOULD be a uniformResourceIdentifier. The URI MUST specify a 182 distingishedName and attribute(s) and MAY specify a host name 183 (e.g., ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com? 184 cACertificate;binary,crossCertificatePair;binary). Omitting the 185 host name (e.g., 186 ldap:///cn=example%20CA,dc=example,dc=com?cACertificate;binary) has 187 the effect of specifying the use of whatever LDAP server is locally 188 configured. The URI MUST list appropriate attribute descriptions 189 for one or more attributes holding certificates or cross- 190 certificate pairs. 192 3 Security Considerations 194 Implementers should take into account the possible existence of 195 multiple unrelated CAs and CRL issuers with the same name. 197 Implementers should be aware of risks involved if the Authority 198 Information Access extensions of corrupted CRLs contain links to 199 malicious code. Implementers should always take the steps of 200 validating the retrieved data to ensure that the data is properly 201 formed. 203 4 IANA Considerations 205 This document has no actions for IANA. 207 5 References 209 Normative references: 211 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC 2587] Boeyen, S., T. Howes, and P. Richard, "Internet X.509 215 Public Key Infrastructure: LDAPv2 Schema", June 1999. 217 [RFC 3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 218 X.509 Public Key Infrastructure: Certificate and 219 Certificate Revocation List (CRL) Profile", RFC 3280, 220 April 2002. 222 [HTTP/1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 223 Masinter, L., Leach P. and T. Berners-Lee, "Hypertext 224 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 226 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 227 Resource Identifiers (URI): Generic Syntax", RFC 2396, 228 August 1998. 230 [LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight 231 Directory Access Protocol (v3)", RFC 2251, 232 December 1997. 234 [PKIX-CERT] R. Housley and P. Hoffman, "Internet X.509 Public Key 235 Infrastructure: Operational Protocols: FTP and HTTP", 236 RFC 2585, May 1999. 238 [CMC] M. Myers, X. Liu, J. Schaad, J. Weinstein, "Certificate 239 Management Messages over CMS", RFC 2797, April 2000. 241 Informative references: 243 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 244 8824-1:2002), Information Technology - Abstract Syntax 245 Notation One, 2002. 247 [X.690] ITU-T Recommendation X.690 Information Technology - 248 ASN.1 encoding rules: Specification of Basic Encoding 249 Rules (BER), Canonical Encoding Rules (CER) and 250 Distinguished Encoding Rules (DER), 1997. 252 Authors' Addresses 254 Stefan Santesson 255 Microsoft 256 Tuborg Boulevard 12 257 2900 Hellerup 258 Denmark 260 EMail: stefans@microsoft.com 262 Russell Housley 263 Vigil Security, LLC 264 918 Spring Knoll Drive 265 Herndon, VA 20170 266 USA 268 EMail: housley@vigilsec.com 270 Disclaimer 272 This document and the information contained herein are provided on 273 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 274 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 275 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 276 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 277 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 278 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 279 PARTICULAR PURPOSE. 281 IPR Notice 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed 285 to pertain to the implementation or use of the technology described 286 in this document or the extent to which any license under such 287 rights might or might not be available; nor does it represent that 288 it has made any independent effort to identify any such rights. 289 Information on the procedures with respect to rights in RFC 290 documents can be found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use 295 of such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository 297 at http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at ietf- 303 ipr@ietf.org. 305 Copyright Statement 307 Copyright (C) The Internet Society (2005). 309 This document is subject to the rights, licenses and restrictions 310 contained in BCP 78, and except as set forth therein, the authors 311 retain all their rights. 313 Expires February 2006