PKIX Working Group P. Yee
Internet Draft RSA Security
Expires July 2002 January 2002
Attribute Certificate Management Messages over CMS
<draft-ietf-pkix-acmc-00.txt>
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 January 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 January 2002
Additional control attributes are defined: addAttribute and sendCert,
discussed later.
Control Attribute OID Syntax
_________________ __________ ______________
addAttribute id-cmc <acmc01> AddAttribute
sendTo id-cmc <acmc02> SendTo
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 January 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.
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
specified in CMC.
Yee [Page 4]
Internet Draft January 2002
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
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.
Yee [Page 5]
Internet Draft January 2002
-- 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 X.Y).
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. [Probably want a good example here.]
SendTo ::= -- Syntax TBD
[Additional syntax-based description of SendTo goes here.]
5. Status Modifications
To support attribute certificates, additional return values for the
cmcStatusInfoExt control attribute are defined. The set of failure
Yee [Page 6]
Internet Draft January 2002
information values defined in [CMC] Section 5.1.4 are extended with:
unsupportedAttr (13) -- A requested attribute was not
supported by the recipient AA attrModified (14) --
Requested attribute values were modified by the AA
policydoesnotAllow (15) -- Policy does not allow the granting of
a requested attribute or -- attribute value
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.
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. 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. November 10, 2001. "Certificate Store
Access via HTTP", draft-ietf-pkix-certstore-http-00.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
Yee [Page 7]
Internet Draft January 2002
[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
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 8]