idnits 2.17.00 (12 Aug 2021) /tmp/idnits63113/draft-ietf-pkix-acmc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([CMCbis], [ACRMF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 2002) is 7371 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: '0' on line 65 -- Looks like a reference, but probably isn't: '1' on line 66 -- Looks like a reference, but probably isn't: '2' on line 67 == Missing Reference: 'CMC' is mentioned on line 321, but not defined == Unused Reference: '2459bis' is defined on line 369, but no explicit reference was found in the text == Outdated reference: draft-ietf-pkix-new-part1 has been published as RFC 3280 == Outdated reference: draft-ietf-pkix-ac509prof has been published as RFC 3281 == Outdated reference: A later version (-01) exists of draft-ietf-pkix-acrmf-00 -- Possible downref: Normative reference to a draft: ref. 'ACRMF' == Outdated reference: draft-ietf-pkix-certstore-http has been published as RFC 4387 -- Possible downref: Normative reference to a draft: ref. 'CMCbis' Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group P. Yee 3 Internet Draft RSA Security 4 Expires September 2002 March 2002 6 Attribute Certificate Management Messages over CMS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document specifies modifications to the Certificate Management 31 Messages over CMS specification ([CMCbis]) to permit the management 32 of attribute certificates. This document does not stand alone, but 33 must be used in conjunction with [CMCbis]. It is expected that the 34 modifications proposed here will also be used in conjunction with the 35 Attribute Certificate Request Message Format specification ([ACRMF]). 37 1. Introduction 39 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 40 in this document are to be interpreted as described in [RFC2119]. 42 CMC [CMCbis] specifies the exchanges, structures, and controls for 43 managing public key certificates. This document extends CMC to 44 handle attribute certificates. It profiles CMC, adding new elements 45 as necessary. 47 CMC supports "Simple PKI Requests" and "Full PKI Requests". The ACMC 48 specification requires the use of the Full PKI Request form and its 49 corresponding response. 51 2. Request Modifications 53 The two primary data structures in CMC are the PKIData content object 54 and the ResponseBody content object. Based on the name of the 55 PKIData structure, one might not think that it is appropriate for 56 attribute certificates; however its content is well-aligned with our 57 purpose. In particular, no changes are required at the top level of 58 either PKIData or ResponseBody. 60 Within the PKIData structure, the reqSequence (a sequence of 61 TaggedRequest) element is modified in order to carry the ACRMF and 62 other requests. Thus, TaggedRequest becomes: 64 TaggedRequest ::= CHOICE { 65 tcr [0] TaggedCertificationRequest, -- original 66 crm [1] CertRequestMsg, -- original 67 other [2] ANY DEFINED BY OID -- others including ACRMF 69 Implementations MAY allow requests for both public key and attribute 70 certificates in a single reqSequence. 72 3. Control Attribute Modifications 74 CMC specifies a large number of control attributes that can be 75 applied as part of certificate requests. Many of these are 76 inappropriate for attribute certificates. In particular, ACMC only 77 uses the following controls: 79 Control Attribute OID Syntax 80 _________________ __________ ______________ 81 dataReturn id-cmc 4 OCTET STRING 82 transactionID id-cmc 5 INTEGER 83 senderNonce id-cmc 6 OCTET STRING 84 recipientNonce id-cmc 7 OCTET STRING 85 addExtensions id-cmc 8 AddExtensions 86 getCert id-cmc 15 GetCert 87 getCRL id-cmc 16 GetCRL 88 revokeRequest id-cmc 17 RevokeRequest 89 regInfo id-cmc 18 OCTET STRING 90 responseInfo id-cmc 19 OCTET STRING 91 queryPending id-cmc 21 OCTET STRING 92 idConfirmCertAcceptance id-cmc 24 CMCCertId 93 cmcStatusInfoExt id-cmc XX CMCStatusInfoExt 95 Additional control attributes are defined: addAttribute, sendTo, and 96 modHandling discussed later. 98 Control Attribute OID Syntax 99 _________________ __________ ______________ 100 addAttribute id-cmc AddAttribute 101 sendTo id-cmc SendTo 102 attrModHandling id-cmc AttrModHandling 104 It is possible that a control attribute to support additional 105 retrieval indices for attribute certificates will be added if getCert 106 cannot be suitably modified. 108 3.1. Data Return Control Attribute 110 dataReturn, [CMCbis] Section 5.4, is supported without modification 111 by ACMC. 113 3.2. Transaction ID Control Attribute 115 transactionID, [CMCbis] Section 5.6, is supported without 116 modification by ACMC. 118 3.3. Sender Nonce Control Attribute 120 senderNonce, [CMCbis] Section 5.6, is supported without modification 121 by ACMC. 123 3.4. Recipient Nonce Control Attribute 125 recipientNonce, [CMCbis] Section 5.6, is supported without 126 modification by ACMC. 128 3.5. Add Extensions Control Attribute 130 The addExtensions control attribute, [CMCbis] Section 5.5, is 131 supported by ACMC. In order to match [ACRMF] messages, the 132 certReferences sequence is additionally allowed to be equal to the 133 attrCertReqId of the AttrCertRequest within an AttrCertReqMsg (see 134 ACRMF, Section 3). Also, when the extensions are being applied to an 135 attribute certificate, the requirement shall be that servers MUST be 136 able to process all extensions defined in [ACPROF]. 138 3.6. Get Certificate Control Attribute 140 ACMC supports the getCert control attribute ([CMCbis] Section 5.9). 141 Currently, getCert only supports retrieval based upon the issuerName 142 and serialNumber combination. This combination of values suffices 143 for both public key and attribute certificates. 145 Additional retrieval scenarios are envisaged, as expressed in 146 [CERTHTTP]. Beyond that, attribute certificates have other means by 147 which they can be indexed and retrieved. In particular, retrieval by 148 holder name in conjunction with a particular set of attribute types 149 would be useful. 151 3.7. Get CRL Control Attribute 153 The getCRL control attribute ([CMCbis] Section 5.10) is supported as 154 is by ACMC. 156 3.8. Revoke Request Control Attribute 158 The revokeRequest control attribute ([CMCbis] Section 5.11)is 159 supported as specified in CMC. Some of the CRLReason codes used, 160 however, are not suitable for use with attribute certificates. In 161 particular, only the unspecified, affliationChanged, superseded, 162 cessationOfOperation, privilegeWithdrawn, or aACompromise values 163 should be used when revoking an attribute certificate. 165 More generally, this control attribute is not appropriate to employ 166 if the noRevAvail extension is present in the attribute certificate 167 and its value is set to TRUE. 169 The protocol does not specify which entities are allowed to request 170 the revocation of a certificate. 172 The revoke request control attribute allows revocation of a public 173 key certificate without having a signature on the request. A 174 password is used for authentication in this case. For attribute 175 certificates, this capability is not supported. If the private 176 signing key is lost, then the public key certificate should be 177 revoked. Attribute certificates that are explicitly linked to the 178 public key certificate being revoked will simply fail to verify. 180 3.9. Registration Information Control Attribute 182 The regInfo control attribute ([CMCbis] Section 5.12) is supported as 183 specified in CMC. 185 3.10. Response Information Control Attribute 187 The responseInfo control attribute ([CMCbis] Section 5.12) is 188 supported as specified in CMC. 190 3.11. Query Pending Control Attribute 192 The queryPending control attribute ([CMCbis] Section 5.13) is 193 supported as specified in CMC. 195 3.12. Confirm Certificate Acceptance Control Attribute 197 The idConfirmCertAcceptance control attribute ([CMCbis] Section 5.14) 198 is supported as specified in CMC. 200 4. New Control Attributes 202 4.1. Add Attributes Control Attribute 204 The addAttributes control attribute is analogous to the addExtensions 205 control attribute. 207 The Add Attributes control attribute is used by LARAs to specify 208 additional attributes that are to be placed on certificates. This 209 attribute uses the following ASN.1 definition: 211 AddAttributes ::= SEQUENCE 213 pkiDataReference BodyPartID 214 certReferences SEQUENCE OF BodyPartID, 215 attributes SEQUENCE OF Attribute 216 } 218 -- pkiDataReference field contains the body part identifier of the 219 embedded request message. 221 -- certReferences field is a list of references to one or more of the 222 payloads contained within a PKIData. Each element of the 223 certReferences sequence MUST be equal to either the bodyPartID of a 224 TaggedCertificationRequest, the certReqId of the CertRequest within a 225 CertReqMsg, or the attrCertReqId of the AttrCertRequest within an 226 AttrCertReqMsg. By definition, the listed attributes are to be 227 applied to every element referenced in the certReferences sequence. 228 If a request corresponding to bodyPartID cannot be found, the error 229 badRequest is returned referencing this control attribute. 231 -- attributes field contains the sequence of attributes to be applied 232 to the referenced certificate requests. 234 Servers MUST be able to process all attributes defined in [ACPROF]. 235 Servers are not required to be able to process every attribute 236 transmitted using this protocol. Servers are not required to put all 237 LARA-requested attributes into a certificate. Servers are permitted 238 to modify LARA-requested attributes. Servers MUST NOT alter an 239 attribute so as to reverse the meaning of a client-requested 240 attribute. If a certification request is denied due to the inability 241 to handle a requested attribute and a response is returned, the 242 server MUST return a failInfo attribute with the value of 243 unsupportedAttr. 245 If multiple Add Attributes statements exist in an enrollment message, 246 the exact behavior is left up to the certificate issuer policy. 247 However it is recommended that the following policy be used. These 248 rules would be applied to individual attribute within an Add 249 Attributes control attribute (as opposed to an "all or nothing" 250 approach). 252 1. If the conflict is within a single PKIData object, the certificate 253 request would be rejected with an error of badRequest. 255 2. If the conflict is between different PKIData objects, the 256 outermost version of the attribute would be used (allowing a LARA to 257 override the attribute requested by the end-entity). If the 258 attributes requested by an end-entity are overridden, then the 259 returned status SHALL so indicate (see Section 5). 261 4.2. Send To Control Attribute 263 The Send To Control Attribute indicates to the Attribute Authority 264 that a copy of the generated attribute certificate should be sent to 265 the designated recipient. Such a service is useful in cases when the 266 entity for whom the attribute certificate is issued is not the 267 requester. 269 SendTo ::= GeneralNames 271 GeneralNames is used to specify the recipients of the generated 272 attribute certificate. Note that some forms of GeneralName are not 273 appropriate for receiving attribute certificates without further 274 specification. 276 4.3. Attribute Modification Handling Control Attribute 278 The Attribute Modification Handling Control Attribute allows the 279 requester to specify its permissions for cases where the LARA wishes 280 to change the requested set attributes or their values, or where the 281 Attribute Authority wishes to issue a set of attributes which differ 282 from those requested. Permissions that may be specified are: 284 - Attributes to be issued must be exactly as specified (or not at 285 all). 286 - Attributes to be issued must be according to given profile or 287 policy. 288 - Attributes types must be as requested, but values may differ 289 (across any subset of attributes). 290 - Any attributes and values are acceptable. 292 attrModHandling ::= SEQUENCE { 293 attrModPermission AttrModPermission, 294 attrModPolicy OBJECT IDENTIFIER 295 } 297 AttrModPermission ::= INTEGER { 298 asSpecified (0), 299 byPolicy (1), 300 byType (2), 301 atAADiscretion (3) 302 } 304 The Modification Handling control supercedes the Add Attributes 305 control and cannot be further superceded by another instance of 306 this control. If more than one instance of the control appears 307 in a single request, a badRequest CMCFailInfo value MUST be 308 returned to the LARA or end-entity. 310 When attributes are to be issued according to a given profile or 311 policy, the requester MAY send requested attributes and their 312 value or omit them. If values are supplied, the AA may modify 313 these values within the bounds of the policy. If the attributes 314 are omitted in the request, the AA supplies a permissible set of 315 attributes and values as dictated by the policy. 317 5. Status Modifications 319 cMCStatusInfoExt is used to indicate that a request was unsuccessful. 321 ACMC returns additional status values beyond those specified in [CMC] 322 Section 5.1.4. The additional status value are encoded using the 323 ExtendedFailInfo field of the cmcStatusInfoExt structure. These 324 relevant values are defined as: 326 id-cet-acmcFailInfo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 327 dod(6) internet(1) security(5) mechanisms(5) pkix(7) cet(15) acmcFailInfo(x) } 329 ACMCFailInfo ::= INTEGER { 330 unsupportedAttr (0), 331 attrModified (1), 332 policyDoesNotAllow (2), 333 comboNotSupported (3) } 335 The ACMCFailInfo values mean: 337 - unsupportedAttr means that the requested attribute was not 338 supported by the recipient AA. 340 - attrModified indicates that the set of attributes or the 341 attribute values were modified by the AA. This return value is 342 not explicitly fatal, but is meant to alert the requester that 343 one or more modifications were made in the returned attributes. 344 If the Attribute Modification Control is used to signal that 345 attributes are to be set by policy, than this return value MAY 346 be omitted. 348 - policyDoesNotAllow signals that the prevailing policy under 349 which the attribute certificate is to be issued does not allow 350 the granting of a requested attribute or attribute value; this 351 error value is used in response to the addAttribute control. 353 - comboNotSupported means that this responder does not support 354 requests for both public key and attribute certificates in one 355 message. 357 6. Additional Notes 359 In the Full PKI Response generated when a new attribute certificate 360 is requested, this profile requires that the certificates field of 361 the signedData object MUST contain (at a minimum) the AA's PKC. 362 Other certificates that form the certificate chain for the AA's PKC 363 MAY be included in the certificates field. 365 Security considerations are not yet discussed in this memo. 367 7. References 369 [2459bis] Housley, R., W. Ford, W. Polk, and D. Solo. Work in 370 progress, October 2001. "Internet X.509 Public Key 371 Infrastructure Certificate and CRL Profile", draft-ietf- 372 pkix-new-part1-11.txt. 374 [ACPROF] Farrell, S. and R. Housley. Work in progress, June 8, 375 2001. "An Internet Atribute Certificate Profile for 376 Authorization", draft-ietf-pkix-ac509prof-09.txt. 378 [ACRMF] Yee, P. Work in progress, November 2001. "Attribute 379 Certificate Request Message Format", draft-ietf-pkix- 380 acrmf-00.txt. 382 [CERTHTTP] Gutmann, P. January 21, 2002. "Certificate Store Access 383 via HTTP", draft-ietf-pkix-certstore-http-02.txt. 385 [CMCbis] Myers, M., X. Liu, J. Schaad, and J. Weinstein. Work in 386 progress, July 2001. "Certificate Management Messages 387 over CMS", draft-ietf-pkix-rfc2797-bis-01.txt. 389 [RFC2026] Bradner, S. October 1996. "The Internet Standards 390 Process -- Revision 3", RFC 2026, BCP 9. 392 [RFC2119] Bradner, S. March 1997. "Key words for use in RFCs to 393 Indicate Requirement Levels", RFC 2119, BCP 14. 395 Appendix A: Object Identifiers 397 [OIDs go here.] 399 Appendix B: ASN.1 Module 401 [ASN.1 goes here.] 403 Author's Address: 405 Peter Yee 406 RSA Security 407 2955 Campus Drive 408 Suite 400 409 San Mateo, California 94403 410 USA 412 email: pyee@rsasecurity.com 414 Full Copyright Statement 415 Copyright (C) The Internet Society (2002). All Rights Reserved. 417 This document and translations of it may be copied and furnished to 418 others, and derivative works that comment on or otherwise explain it 419 or assist in its implementation may be prepared, copied, published 420 and distributed, in whole or in part, without restriction of any 421 kind, provided that the above copyright notice and this paragraph are 422 included on all such copies and derivative works. However, this 423 document itself may not be modified in any way, such as by removing 424 the copyright notice or references to the Internet Society or other 425 Internet organizations, except as needed for the purpose of 426 developing Internet standards in which case the procedures for 427 copyrights defined in the Internet Standards process must be 428 followed, or as required to translate it into languages other than 429 English. 431 The limited permissions granted above are perpetual and will not be 432 revoked by the Internet Society or its successors or assigns. 434 This document and the information contained herein is provided on an 435 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 436 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 437 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 438 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 439 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.