< draft-ietf-pkix-acmc-00.txt		draft-ietf-pkix-acmc-01.txt >
	PKIX Working Group P. Yee		PKIX Working Group P. Yee
	Internet Draft RSA Security		Internet Draft RSA Security
	Expires July 2002 January 2002		Expires September 2002 March 2002
	Attribute Certificate Management Messages over CMS		Attribute Certificate Management Messages over CMS
	<draft-ietf-pkix-acmc-00.txt>		<draft-ietf-pkix-acmc-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of [RFC2026].		all provisions of Section 10 of [RFC2026].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts. Internet-Drafts are draft documents valid for a maximum of		Drafts. Internet-Drafts are draft documents valid for a maximum of
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	addExtensions id-cmc 8 AddExtensions		addExtensions id-cmc 8 AddExtensions
	getCert id-cmc 15 GetCert		getCert id-cmc 15 GetCert
	getCRL id-cmc 16 GetCRL		getCRL id-cmc 16 GetCRL
	revokeRequest id-cmc 17 RevokeRequest		revokeRequest id-cmc 17 RevokeRequest
	regInfo id-cmc 18 OCTET STRING		regInfo id-cmc 18 OCTET STRING
	responseInfo id-cmc 19 OCTET STRING		responseInfo id-cmc 19 OCTET STRING
	queryPending id-cmc 21 OCTET STRING		queryPending id-cmc 21 OCTET STRING
	idConfirmCertAcceptance id-cmc 24 CMCCertId		idConfirmCertAcceptance id-cmc 24 CMCCertId
	cmcStatusInfoExt id-cmc XX CMCStatusInfoExt		cmcStatusInfoExt id-cmc XX CMCStatusInfoExt
	Additional control attributes are defined: addAttribute and sendCert,		Additional control attributes are defined: addAttribute, sendTo, and
	discussed later.		modHandling discussed later.
	Control Attribute OID Syntax		Control Attribute OID Syntax
	_________________ __________ ______________		_________________ __________ ______________
	addAttribute id-cmc <acmc01> AddAttribute		addAttribute id-cmc <acmc01> AddAttribute
	sendTo id-cmc <acmc02> SendTo		sendTo id-cmc <acmc02> SendTo
			attrModHandling id-cmc <acmc03> AttrModHandling
	It is possible that a control attribute to support additional		It is possible that a control attribute to support additional
	retrieval indices for attribute certificates will be added if getCert		retrieval indices for attribute certificates will be added if getCert
	cannot be suitably modified.		cannot be suitably modified.
	3.1. Data Return Control Attribute		3.1. Data Return Control Attribute
	dataReturn, [CMCbis] Section 5.4, is supported without modification		dataReturn, [CMCbis] Section 5.4, is supported without modification
	by ACMC.		by ACMC.
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	certReferences sequence is additionally allowed to be equal to the		certReferences sequence is additionally allowed to be equal to the
	attrCertReqId of the AttrCertRequest within an AttrCertReqMsg (see		attrCertReqId of the AttrCertRequest within an AttrCertReqMsg (see
	ACRMF, Section 3). Also, when the extensions are being applied to an		ACRMF, Section 3). Also, when the extensions are being applied to an
	attribute certificate, the requirement shall be that servers MUST be		attribute certificate, the requirement shall be that servers MUST be
	able to process all extensions defined in [ACPROF].		able to process all extensions defined in [ACPROF].
	3.6. Get Certificate Control Attribute		3.6. Get Certificate Control Attribute
	ACMC supports the getCert control attribute ([CMCbis] Section 5.9).		ACMC supports the getCert control attribute ([CMCbis] Section 5.9).
	Currently, getCert only supports retrieval based upon the issuerName		Currently, getCert only supports retrieval based upon the issuerName
	and serialNumber combination.		and serialNumber combination. This combination of values suffices
			for both public key and attribute certificates.
	Additional retrieval scenarios are envisaged, as expressed in		Additional retrieval scenarios are envisaged, as expressed in
	[CERTHTTP]. Beyond that, attribute certificates have other means by		[CERTHTTP]. Beyond that, attribute certificates have other means by
	which they can be indexed and retrieved. In particular, retrieval by		which they can be indexed and retrieved. In particular, retrieval by
	holder name in conjunction with a particular set of attribute types		holder name in conjunction with a particular set of attribute types
	would be useful.		would be useful.
	3.7. Get CRL Control Attribute		3.7. Get CRL Control Attribute
	The getCRL control attribute ([CMCbis] Section 5.10) is supported as		The getCRL control attribute ([CMCbis] Section 5.10) is supported as
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 36 ¶
	Attributes control attribute (as opposed to an "all or nothing"		Attributes control attribute (as opposed to an "all or nothing"
	approach).		approach).
	1. If the conflict is within a single PKIData object, the certificate		1. If the conflict is within a single PKIData object, the certificate
	request would be rejected with an error of badRequest.		request would be rejected with an error of badRequest.
	2. If the conflict is between different PKIData objects, the		2. If the conflict is between different PKIData objects, the
	outermost version of the attribute would be used (allowing a LARA to		outermost version of the attribute would be used (allowing a LARA to
	override the attribute requested by the end-entity). If the		override the attribute requested by the end-entity). If the
	attributes requested by an end-entity are overridden, then the		attributes requested by an end-entity are overridden, then the
	returned status SHALL so indicate (see Section X.Y).		returned status SHALL so indicate (see Section 5).
	4.2. Send To Control Attribute		4.2. Send To Control Attribute
	The Send To Control Attribute indicates to the Attribute Authority		The Send To Control Attribute indicates to the Attribute Authority
	that a copy of the generated attribute certificate should be sent to		that a copy of the generated attribute certificate should be sent to
	the designated recipient. Such a service is useful in cases when the		the designated recipient. Such a service is useful in cases when the
	entity for whom the attribute certificate is issued is not the		entity for whom the attribute certificate is issued is not the
	requester. [Probably want a good example here.]		requester.
	SendTo ::= -- Syntax TBD		SendTo ::= GeneralNames
	[Additional syntax-based description of SendTo goes here.]		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
			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		5. Status Modifications
	To support attribute certificates, additional return values for the		cMCStatusInfoExt is used to indicate that a request was unsuccessful.
	cmcStatusInfoExt control attribute are defined. The set of failure
	information values defined in [CMC] Section 5.1.4 are extended with:
	unsupportedAttr (13) -- A requested attribute was not		ACMC returns additional status values beyond those specified in [CMC]
	supported by the recipient AA attrModified (14) --		Section 5.1.4. The additional status value are encoded using the
	Requested attribute values were modified by the AA		ExtendedFailInfo field of the cmcStatusInfoExt structure. These
	policydoesnotAllow (15) -- Policy does not allow the granting of		relevant values are defined as:
	a requested attribute or -- attribute value
			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		6. Additional Notes
	In the Full PKI Response generated when a new attribute certificate		In the Full PKI Response generated when a new attribute certificate
	is requested, this profile requires that the certificates field of		is requested, this profile requires that the certificates field of
	the signedData object MUST contain (at a minimum) the AA's PKC.		the signedData object MUST contain (at a minimum) the AA's PKC.
	Other certificates that form the certificate chain for the AA's PKC		Other certificates that form the certificate chain for the AA's PKC
	MAY be included in the certificates field.		MAY be included in the certificates field.
	Security considerations are not yet discussed in this memo.		Security considerations are not yet discussed in this memo.
	7. References		7. References
	[2459bis] Housley, R., W. Ford, W. Polk, and D. Solo. Work in		[2459bis] Housley, R., W. Ford, W. Polk, and D. Solo. Work in
	progress, October 2001. "Internet X.509 Public Key		progress, October 2001. "Internet X.509 Public Key
	Infrastructure Certificate and CRL Profile", draft-ietf-		Infrastructure Certificate and CRL Profile", draft-ietf-
	pkix-new-part1-11.txt.		pkix-new-part1-11.txt.
	[ACPROF] Farrell, S. and R. Housley. June 8, 2001. "An Internet		[ACPROF] Farrell, S. and R. Housley. Work in progress, June 8,
	Atribute Certificate Profile for Authorization", draft-		2001. "An Internet Atribute Certificate Profile for
	ietf-pkix-ac509prof-09.txt.		Authorization", draft-ietf-pkix-ac509prof-09.txt.
	[ACRMF] Yee, P. Work in progress, November 2001. "Attribute		[ACRMF] Yee, P. Work in progress, November 2001. "Attribute
	Certificate Request Message Format", draft-ietf-pkix-		Certificate Request Message Format", draft-ietf-pkix-
	acrmf-00.txt.		acrmf-00.txt.
	[CERTHTTP] Gutmann, P. November 10, 2001. "Certificate Store		[CERTHTTP] Gutmann, P. January 21, 2002. "Certificate Store Access
	Access via HTTP", draft-ietf-pkix-certstore-http-00.txt.		via HTTP", draft-ietf-pkix-certstore-http-02.txt.
	[CMCbis] Myers, M., X. Liu, J. Schaad, and J. Weinstein. Work in		[CMCbis] Myers, M., X. Liu, J. Schaad, and J. Weinstein. Work in
	progress, July 2001. "Certificate Management Messages		progress, July 2001. "Certificate Management Messages
	over CMS", draft-ietf-pkix-rfc2797-bis-01.txt.		over CMS", draft-ietf-pkix-rfc2797-bis-01.txt.
	[RFC2026] Bradner, S. October 1996. "The Internet Standards		[RFC2026] Bradner, S. October 1996. "The Internet Standards
	Process -- Revision 3", RFC 2026, BCP 9.		Process -- Revision 3", RFC 2026, BCP 9.
	[RFC2119] Bradner, S. March 1997. "Key words for use in RFCs to		[RFC2119] Bradner, S. March 1997. "Key words for use in RFCs to
	Indicate Requirement Levels", RFC 2119, BCP 14.		Indicate Requirement Levels", RFC 2119, BCP 14.
End of changes. 13 change blocks.
	22 lines changed or deleted		96 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/