PKIX Working Group P. Yee Internet Draft RSA Security Expires September 2002 March 2002 Attribute Certificate Management Messages over CMS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies modifications to the Certificate Management Messages over CMS specification ([CMCbis]) to permit the management of attribute certificates. This document does not stand alone, but must be used in conjunction with [CMCbis]. It is expected that the modifications proposed here will also be used in conjunction with the Attribute Certificate Request Message Format specification ([ACRMF]). 1. Introduction The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119]. CMC [CMCbis] specifies the exchanges, structures, and controls for managing public key certificates. This document extends CMC to handle attribute certificates. It profiles CMC, adding new elements as necessary. CMC supports "Simple PKI Requests" and "Full PKI Requests". The ACMC Yee [Page 1] Internet Draft March 2002 specification requires the use of the Full PKI Request form and its corresponding response. 2. Request Modifications The two primary data structures in CMC are the PKIData content object and the ResponseBody content object. Based on the name of the PKIData structure, one might not think that it is appropriate for attribute certificates; however its content is well-aligned with our purpose. In particular, no changes are required at the top level of either PKIData or ResponseBody. Within the PKIData structure, the reqSequence (a sequence of TaggedRequest) element is modified in order to carry the ACRMF and other requests. Thus, TaggedRequest becomes: TaggedRequest ::= CHOICE { tcr [0] TaggedCertificationRequest, -- original crm [1] CertRequestMsg, -- original other [2] ANY DEFINED BY OID -- others including ACRMF Implementations MAY allow requests for both public key and attribute certificates in a single reqSequence. 3. Control Attribute Modifications CMC specifies a large number of control attributes that can be applied as part of certificate requests. Many of these are inappropriate for attribute certificates. In particular, ACMC only uses the following controls: Control Attribute OID Syntax _________________ __________ ______________ dataReturn id-cmc 4 OCTET STRING transactionID id-cmc 5 INTEGER senderNonce id-cmc 6 OCTET STRING recipientNonce id-cmc 7 OCTET STRING addExtensions id-cmc 8 AddExtensions getCert id-cmc 15 GetCert getCRL id-cmc 16 GetCRL revokeRequest id-cmc 17 RevokeRequest regInfo id-cmc 18 OCTET STRING responseInfo id-cmc 19 OCTET STRING queryPending id-cmc 21 OCTET STRING idConfirmCertAcceptance id-cmc 24 CMCCertId cmcStatusInfoExt id-cmc XX CMCStatusInfoExt Yee [Page 2] Internet Draft March 2002 Additional control attributes are defined: addAttribute, sendTo, and modHandling discussed later. Control Attribute OID Syntax _________________ __________ ______________ addAttribute id-cmc AddAttribute sendTo id-cmc SendTo attrModHandling id-cmc AttrModHandling It is possible that a control attribute to support additional retrieval indices for attribute certificates will be added if getCert cannot be suitably modified. 3.1. Data Return Control Attribute dataReturn, [CMCbis] Section 5.4, is supported without modification by ACMC. 3.2. Transaction ID Control Attribute transactionID, [CMCbis] Section 5.6, is supported without modification by ACMC. 3.3. Sender Nonce Control Attribute senderNonce, [CMCbis] Section 5.6, is supported without modification by ACMC. 3.4. Recipient Nonce Control Attribute recipientNonce, [CMCbis] Section 5.6, is supported without modification by ACMC. 3.5. Add Extensions Control Attribute The addExtensions control attribute, [CMCbis] Section 5.5, is supported by ACMC. In order to match [ACRMF] messages, the certReferences sequence is additionally allowed to be equal to the attrCertReqId of the AttrCertRequest within an AttrCertReqMsg (see ACRMF, Section 3). Also, when the extensions are being applied to an attribute certificate, the requirement shall be that servers MUST be able to process all extensions defined in [ACPROF]. Yee [Page 3] Internet Draft March 2002 3.6. Get Certificate Control Attribute ACMC supports the getCert control attribute ([CMCbis] Section 5.9). Currently, getCert only supports retrieval based upon the issuerName and serialNumber combination. This combination of values suffices for both public key and attribute certificates. Additional retrieval scenarios are envisaged, as expressed in [CERTHTTP]. Beyond that, attribute certificates have other means by which they can be indexed and retrieved. In particular, retrieval by holder name in conjunction with a particular set of attribute types would be useful. 3.7. Get CRL Control Attribute The getCRL control attribute ([CMCbis] Section 5.10) is supported as is by ACMC. 3.8. Revoke Request Control Attribute The revokeRequest control attribute ([CMCbis] Section 5.11)is supported as specified in CMC. Some of the CRLReason codes used, however, are not suitable for use with attribute certificates. In particular, only the unspecified, affliationChanged, superseded, cessationOfOperation, privilegeWithdrawn, or aACompromise values should be used when revoking an attribute certificate. More generally, this control attribute is not appropriate to employ if the noRevAvail extension is present in the attribute certificate and its value is set to TRUE. The protocol does not specify which entities are allowed to request the revocation of a certificate. The revoke request control attribute allows revocation of a public key certificate without having a signature on the request. A password is used for authentication in this case. For attribute certificates, this capability is not supported. If the private signing key is lost, then the public key certificate should be revoked. Attribute certificates that are explicitly linked to the public key certificate being revoked will simply fail to verify. 3.9. Registration Information Control Attribute The regInfo control attribute ([CMCbis] Section 5.12) is supported as Yee [Page 4] Internet Draft March 2002 specified in CMC. 3.10. Response Information Control Attribute The responseInfo control attribute ([CMCbis] Section 5.12) is supported as specified in CMC. 3.11. Query Pending Control Attribute The queryPending control attribute ([CMCbis] Section 5.13) is supported as specified in CMC. 3.12. Confirm Certificate Acceptance Control Attribute The idConfirmCertAcceptance control attribute ([CMCbis] Section 5.14) is supported as specified in CMC. 4. New Control Attributes 4.1. Add Attributes Control Attribute The addAttributes control attribute is analogous to the addExtensions control attribute. The Add Attributes control attribute is used by LARAs to specify additional attributes that are to be placed on certificates. This attribute uses the following ASN.1 definition: AddAttributes ::= SEQUENCE pkiDataReference BodyPartID certReferences SEQUENCE OF BodyPartID, attributes SEQUENCE OF Attribute } -- pkiDataReference field contains the body part identifier of the embedded request message. -- certReferences field is a list of references to one or more of the payloads contained within a PKIData. Each element of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest, the certReqId of the CertRequest within a CertReqMsg, or the attrCertReqId of the AttrCertRequest within an AttrCertReqMsg. By definition, the listed attributes are to be Yee [Page 5] Internet Draft March 2002 applied to every element referenced in the certReferences sequence. If a request corresponding to bodyPartID cannot be found, the error badRequest is returned referencing this control attribute. -- attributes field contains the sequence of attributes to be applied to the referenced certificate requests. Servers MUST be able to process all attributes defined in [ACPROF]. Servers are not required to be able to process every attribute transmitted using this protocol. Servers are not required to put all LARA-requested attributes into a certificate. Servers are permitted to modify LARA-requested attributes. Servers MUST NOT alter an attribute so as to reverse the meaning of a client-requested attribute. If a certification request is denied due to the inability to handle a requested attribute and a response is returned, the server MUST return a failInfo attribute with the value of unsupportedAttr. If multiple Add Attributes statements exist in an enrollment message, the exact behavior is left up to the certificate issuer policy. However it is recommended that the following policy be used. These rules would be applied to individual attribute within an Add Attributes control attribute (as opposed to an "all or nothing" approach). 1. If the conflict is within a single PKIData object, the certificate request would be rejected with an error of badRequest. 2. If the conflict is between different PKIData objects, the outermost version of the attribute would be used (allowing a LARA to override the attribute requested by the end-entity). If the attributes requested by an end-entity are overridden, then the returned status SHALL so indicate (see Section 5). 4.2. Send To Control Attribute The Send To Control Attribute indicates to the Attribute Authority that a copy of the generated attribute certificate should be sent to the designated recipient. Such a service is useful in cases when the entity for whom the attribute certificate is issued is not the requester. SendTo ::= GeneralNames GeneralNames is used to specify the recipients of the generated attribute certificate. Note that some forms of GeneralName are not appropriate for receiving attribute certificates without further Yee [Page 6] Internet Draft March 2002 specification. 4.3. Attribute Modification Handling Control Attribute The Attribute Modification Handling Control Attribute allows the requester to specify its permissions for cases where the LARA wishes to change the requested set attributes or their values, or where the Attribute Authority wishes to issue a set of attributes which differ from those requested. Permissions that may be specified are: - Attributes to be issued must be exactly as specified (or not at all). - Attributes to be issued must be according to given profile or policy. - Attributes types must be as requested, but values may differ (across any subset of attributes). - Any attributes and values are acceptable. attrModHandling ::= SEQUENCE { attrModPermission AttrModPermission, attrModPolicy OBJECT IDENTIFIER } AttrModPermission ::= INTEGER { asSpecified (0), byPolicy (1), byType (2), atAADiscretion (3) } The Modification Handling control supercedes the Add Attributes control and cannot be further superceded by another instance of this control. If more than one instance of the control appears in a single request, a badRequest CMCFailInfo value MUST be returned to the LARA or end-entity. When attributes are to be issued according to a given profile or policy, the requester MAY send requested attributes and their value or omit them. If values are supplied, the AA may modify these values within the bounds of the policy. If the attributes are omitted in the request, the AA supplies a permissible set of attributes and values as dictated by the policy. 5. Status Modifications cMCStatusInfoExt is used to indicate that a request was unsuccessful. Yee [Page 7] Internet Draft March 2002 ACMC returns additional status values beyond those specified in [CMC] Section 5.1.4. The additional status value are encoded using the ExtendedFailInfo field of the cmcStatusInfoExt structure. These relevant values are defined as: id-cet-acmcFailInfo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) cet(15) acmcFailInfo(x) } ACMCFailInfo ::= INTEGER { unsupportedAttr (0), attrModified (1), policyDoesNotAllow (2), comboNotSupported (3) } The ACMCFailInfo values mean: - unsupportedAttr means that the requested attribute was not supported by the recipient AA. - attrModified indicates that the set of attributes or the attribute values were modified by the AA. This return value is not explicitly fatal, but is meant to alert the requester that one or more modifications were made in the returned attributes. If the Attribute Modification Control is used to signal that attributes are to be set by policy, than this return value MAY be omitted. - policyDoesNotAllow signals that the prevailing policy under which the attribute certificate is to be issued does not allow the granting of a requested attribute or attribute value; this error value is used in response to the addAttribute control. - comboNotSupported means that this responder does not support requests for both public key and attribute certificates in one message. 6. Additional Notes In the Full PKI Response generated when a new attribute certificate is requested, this profile requires that the certificates field of the signedData object MUST contain (at a minimum) the AA's PKC. Other certificates that form the certificate chain for the AA's PKC MAY be included in the certificates field. Security considerations are not yet discussed in this memo. Yee [Page 8] Internet Draft March 2002 7. References [2459bis] Housley, R., W. Ford, W. Polk, and D. Solo. Work in progress, October 2001. "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", draft-ietf- pkix-new-part1-11.txt. [ACPROF] Farrell, S. and R. Housley. Work in progress, June 8, 2001. "An Internet Atribute Certificate Profile for Authorization", draft-ietf-pkix-ac509prof-09.txt. [ACRMF] Yee, P. Work in progress, November 2001. "Attribute Certificate Request Message Format", draft-ietf-pkix- acrmf-00.txt. [CERTHTTP] Gutmann, P. January 21, 2002. "Certificate Store Access via HTTP", draft-ietf-pkix-certstore-http-02.txt. [CMCbis] Myers, M., X. Liu, J. Schaad, and J. Weinstein. Work in progress, July 2001. "Certificate Management Messages over CMS", draft-ietf-pkix-rfc2797-bis-01.txt. [RFC2026] Bradner, S. October 1996. "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9. [RFC2119] Bradner, S. March 1997. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14. Appendix A: Object Identifiers [OIDs go here.] Appendix B: ASN.1 Module [ASN.1 goes here.] Author's Address: Peter Yee RSA Security 2955 Campus Drive Suite 400 San Mateo, California 94403 USA email: pyee@rsasecurity.com Full Copyright Statement Yee [Page 9] Internet Draft March 2002 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Yee [Page 10]