idnits 2.17.1 draft-turner-additional-cms-ri-choices-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 3, 2010) is 5048 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) -- Looks like a reference, but probably isn't: '1' on line 98 -- Looks like a reference, but probably isn't: '0' on line 351 ** Downref: Normative reference to an Informational RFC: RFC 5911 (ref. 'CMS-ASN') ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Downref: Normative reference to an Informational RFC: RFC 5912 (ref. 'PROFILE-ASN') Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK WG Sean Turner, IECA 2 Internet Draft Russ Housley, Vigil Security 3 Intended Status: Standards Track June 3, 2010 4 Expires: December 3, 2010 6 Additional CMS Revocation Information Choices 7 draft-turner-additional-cms-ri-choices-06.txt 9 Abstract 11 The Cryptographic Message Syntax (CMS) allows revocation information 12 to be conveyed as part of the SignedData, EnvelopedData, 13 AuthenticatedData, and AuthEnvelopedData content types. The 14 preferred format for revocation information is the Certificate 15 Revocation List (CRL), but an extension mechanism supports other 16 revocation information formats. This document defines two additional 17 revocation information formats for Online Certificate Status Protocol 18 (OCSP) responses and Server-Based Certificate Validation Protocol 19 (SCVP). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on December 3, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 The RevocationInfoChoices type defined in [CMS] provides a set of 62 revocation status information alternatives, which allows revocation 63 information to be conveyed as part of the SignedData, EnvelopedData, 64 AuthenticatedData, and AuthEnvelopedData content types. The intent 65 is to provide information sufficient to determine whether the 66 certificates and attribute certificates carried elsewhere in the CMS- 67 protected content have been revoked. There may be more revocation 68 status information than necessary or there may be less revocation 69 status information than necessary. 71 X.509 Certificate revocation lists (CRLs) [PROFILE] are the primary 72 source of revocation status information, but any other revocation 73 information format can be supported. This document specifies two 74 other formats: Online Certificate Status Protocol (OCSP) responses 75 [OCSP] and Server-Based Certificate Validation Protocol (SCVP) 76 requests and responses [SCVP]. 78 Section 2 discusses the RevocationInformation structure. Section 3 79 defines a mechanism to carry OCSP responses. Section 4 defines a 80 mechanism to carry SCVP requests and responses. Appendix A provides 81 the normative ASN.1 syntax for the two mechanisms. 83 1.1. Requirements Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [WORDS]. 89 2. Revocation Information 91 For convenience, the ASN.1 definition of the RevocationInfoChoices 92 type from [CMS] is repeated here: 94 RevocationInfoChoices ::= SET OF RevocationInfoChoice 96 RevocationInfoChoice ::= CHOICE { 97 crl CertificateList, 98 other [1] IMPLICIT OtherRevocationInfoFormat } 100 OtherRevocationInfoFormat ::= SEQUENCE { 101 otherRevInfoFormat OBJECT IDENTIFIER, 102 otherRevInfo ANY DEFINED BY otherRevInfoFormat } 104 The other CHOICE MUST be used to convey OCSP responses, SCVP 105 requests, and SCVP responses. 107 This document defines the id-ri arc under which the revocation 108 information formats are defined. The id-ri object identifier is: 110 id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 111 dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) } 113 NOTE: Numbers 1 and 3 were assigned to CRL and Delta CRL. These two 114 numbers are not used because these formats use the 115 RevocationInfoChoice crl CHOICE when included in CMS [CMS]. 117 3. OCSP Response 119 To carry an OCSP response, the otherRevInfoFormat is set to 120 id-ri-ocsp-response, which has the following ASN.1 definition: 122 id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 } 124 In this case, otherRevInfo MUST carry the OCSP response using the 125 OCSPResponse type defined in [OCSP]. The responseStatus field MUST 126 be successful and the responseBytes field MUST be present. 128 4. SCVP Request and Response 130 Unlike OSCP, SCVP permits unprotected and protected responses, where 131 protected responses can be digitally signed or include message 132 authentication codes. While this provides more flexibility, it 133 complicates implementations when an SCVP response can be validated by 134 entities other than the entity that generated the SCVP request. If a 135 lower layer provides authentication and integrity for the client- 136 server interaction and the response is not protected, then a third 137 party cannot validate the response because there is no way to know 138 that the response was returned over a protected connection. If a 139 message authentication code is used, then the third party will be 140 unable to validate the message authentication code because it does 141 not possess the necessary private key. For these reasons, SCVP 142 responses sent to a third party MUST be signed by the SCVP server so 143 that the third party can validate them. 145 SCVP response validation requires matching it to the SCVP request. 146 This means that the SCVP request MUST always be included with the 147 response. SCVP permits the client to retain the response, and SCVP 148 permits the request to be returned in the response (in the requestReq 149 field). The request need not be protected for matching to be 150 performed; nonces and certIds can be checked. 152 To carry the SCVP request and response, the otherRevInfoFormat is set 153 to id-ri-scvp, which has the following ASN.1 definition: 155 id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 } 157 In this case, the otherRevInfo MUST carry both the SCVP request and 158 response with the following structure: 160 SCVPReqRes ::= SEQUENCE { 161 request [0] EXPLICIT ContentInfo OPTIONAL, 162 response ContentInfo } 164 The SCVPReqRes has the following fields: 166 o request contains the SCVP request. It contains the unprotected 167 request, authenticated request, or the signed request. The 168 request MUST be present if the response does not include the 169 requestRef fullRequest field. 171 o response contains the SCVP response. It MUST contain the signed 172 response. Additionally, the responseStatus MUST be okay. 173 Unprotected and authenticated responses MUST NOT be included. 175 5. Security Considerations 177 The security considerations of [CMS], [CMS-ASN], [OCSP], [SCVP], and 178 [PROFILE-ASN] apply. 180 To locally store unprotected or authenticated SCVP responses, a 181 client can encapsulate the unprotected or authenticated SCVP response 182 in a SignedData. It is a matter of local policy whether these SCVP 183 responses that are encapsulated and signed by the client are 184 considered valid by another entity. 186 6. IANA Considerations 188 This document makes use of object identifiers. These object 189 identifiers are defined in an arc delegated by IANA to the PKIX 190 Working Group. No further action by IANA is necessary for this 191 document or any anticipated updates. 193 7. References 195 7.1. Normative References 197 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 5652, 198 September 2009. 200 [CMS-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 201 Cryptographic Message Syntax (CMS) and S/MIME", RFC 202 5911, June 2010. 204 [OCSP] Meyers, M., Ankney, R., Malpani, A., Galperin, S., and 205 C. Adams, "X.509 Internet Public Key Infrastructure 206 Online Certificate Status Protocol - OCSP", RFC 2560, 207 June 1999. 209 [PROFILE-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 210 Public Key Infrastructure Using X.509 (PKIX)", RFC 211 5912, June 2010. 213 [SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and 214 W. Polk, "Server-Based Certificate Validation Protocol 215 (SCVP)", RFC 5055, December 2007. 217 [WORDS] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 221 1:2002. Information Technology - Abstract Syntax 222 Notation One. 224 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824- 225 2:2002. Information Technology - Abstract Syntax 226 Notation One: Information Object Specification. 228 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 229 3:2002. Information Technology - Abstract Syntax 230 Notation One: Constraint Specification. 232 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 233 4:2002. Information Technology - Abstract Syntax 234 Notation One: Parameterization of ASN.1 235 Specifications, 2002. 237 7.2. Informative References 239 [PROFILE] Cooper, D. et. al., "Internet X.509 Public Key 240 Infrastructure Certificate and Certification 241 Revocation List (CRL) Profile", RFC 5280, May 2008. 243 Appendix A. ASN.1 Modules 245 Appendix A.1 provides the normative ASN.1 definitions for the 246 structures described in this specification using ASN.1 as defined in 247 [X.680] for compilers that support the 1988 ASN.1. 249 Appendix A.2 provides informative ASN.1 definitions for the 250 structures described in this specification using ASN.1 as defined in 251 [X.680], [X.681], [X.682], and [X.683] for compilers that support the 252 2002 ASN.1. This appendix contains the same information as Appendix 253 A.1 in a more recent (and precise) ASN.1 notation, however Appendix 254 A.1 takes precedence in case of conflict. 256 A.1. 1988 ASN.1 Module 258 CMS-Other-RIs-2009-88 259 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 260 mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-88(63) 261 } 263 DEFINITIONS IMPLICIT TAGS ::= 265 BEGIN 267 -- EXPORTS ALL 268 IMPORTS 270 -- FROM CMS [CMS] 272 ContentInfo 273 FROM CryptographicMessageSyntax2004 274 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 275 smime(16) modules(0) cms-2004(24) } 277 ; 279 id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 280 dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) } 282 -- RevocationInfoChoice for OCSP response 283 -- OID included in otherRevInfoFormat 284 -- signed OCSP response included in otherRevInfo 286 id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 } 288 -- RevocationInfoChoice for SCVP response 289 -- OID included in otherRevInfoFormat 290 -- SCVPReqRes included in otherRevInfo 292 id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 } 294 SCVPReqRes ::= SEQUENCE { 295 request [0] EXPLICIT ContentInfo OPTIONAL, 296 response ContentInfo } 298 END 300 A.2. 2002 ASN.1 Module 302 CMS-Other-RIs-2009-02 303 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 304 mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-93(64) 305 } 307 DEFINITIONS IMPLICIT TAGS ::= 309 BEGIN 311 -- EXPORT ALL 312 IMPORTS 314 -- FROM [PROFILE-ASN] 316 OCSPResponse 317 FROM OCSP-2009 318 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 319 mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) } 321 -- FROM [CMS-ASN] 323 ContentInfo, OTHER-REVOK-INFO 324 FROM CryptographicMessageSyntax-2009 325 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 326 smime(16) modules(0) id-mod-cms-2004-02(41) } 328 ; 330 -- Defines OCSP and SCVP formats for RevocationInfoChoice 332 SupportedOtherRevokInfo OTHER-REVOK-INFO ::= { 333 ri-ocsp-response | 334 ri-scvp, 335 ... } 337 ri-ocsp-response OTHER-REVOK-INFO ::= { 338 OCSPResponse IDENTIFIED BY id-ri-ocsp-response } 340 id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 341 dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) } 343 id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 } 345 ri-scvp OTHER-REVOK-INFO ::= { 346 SCVPReqRes IDENTIFIED BY id-ri-scvp } 348 id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 } 350 SCVPReqRes ::= SEQUENCE { 351 request [0] EXPLICIT ContentInfo OPTIONAL, 352 response ContentInfo } 354 END 356 Authors' Addresses 358 Sean Turner 359 IECA, Inc. 360 3057 Nutley Street, Suite 106 361 Fairfax, VA 22031 362 USA 364 EMail: turners@ieca.com 366 Russ Housley 367 Vigil Security, LLC 368 918 Spring Knoll Drive 369 Herndon, VA 20170 370 USA 372 EMail: housley@vigilsec.com