< draft-ietf-pkix-ac509prof-00.txt		draft-ietf-pkix-ac509prof-01.txt >
	INTERNET-DRAFT S. Farrell		PKIX Working Group S. Farrell
	PKIX Working Group SSE		INTERNET-DRAFT Baltimore Technologies
	expires in six months R. Housley		Expires in six months R. Housley
	Spryus		SPYRUS
	April 1999		October 1999
	An Internet AttributeCertificate
	Profile for Authorization
	<draft-ietf-pkix-ac509prof-00.txt>
	Status of this memo		An Internet Attribute Certificate
			Profile for Authorization
			<draft-ietf-pkix-ac509prof-01.txt>
	This document is an Internet-Draft and is in full		Status of this Memo
	conformance with all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet		This document is an Internet-Draft and is in full conformance with
	Engineering Task Force (IETF), its areas, and its working		all provisions of Section 10 of [RFC2026].
	groups. Note that other groups may also distribute
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum		Internet-Drafts are working documents of the Internet Engineering
	of six months and may be updated, replaced, or obsoleted		Task Force (IETF), its areas, and its working groups. Note that
	by other documents at any time. It is inappropriate to		other groups may also distribute working documents as Internet-
	use Internet-Drafts as reference material or to cite them		Drafts. Internet-Drafts are draft documents valid for a maximum of
	other than as "work in progress."		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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be		The list of Internet-Draft Shadow Directories can be accessed at
	accessed at http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	<<Comments are contained in angle brackets like this.>>		<<Comments are contained in angle brackets like this.>>
	Abstract		Abstract
	Authorization support is required for various Internet		Authorization services are required for numerous Internet protocols,
	protocols, for example, TLS, CMS and their consumers,		including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate
	and others. The X.509 AttributeCertificate provides a		provides a structure that can form the basis for such services
	structure that can form the basis for such services		[X.509]. This specification defines a profile for the use of X.509
	([X.509], [XPDAM]). This specification defines two		Attribute Certificates to provide authorization services for
	profiles (basic and proxiable) for the use of X.509		Internet protocols. Some optional features are also specified which
	AttributeCertificates to provide such authorization		are not required for conformance to the base profile.
	services.
	Farrell & Housley [Page 1]		Table of Contents
	1. Introduction
	The key words "MUST", "REQUIRED", "SHOULD",		Status of this Memo.............................................1
	"RECOMMENDED", and "MAY" in this document are to be		Abstract........................................................1
	interpreted as described in [RFC2119].		Table of Contents...............................................1
			1. Introduction.................................................3
			2. Terminology..................................................5
			3. Requirements.................................................6
			4. The AC Profile...............................................7
			4.1 X.509 Attribute Certificate Definition.................7
			4.2 Object Identifiers.....................................8
			4.3 Profile of Standard Fields.............................9
			4.3.1 version..........................................9
			4.3.2 owner...........................................10
			4.3.3 issuer..........................................10
			4.3.4 signature.......................................10
			4.3.5 serialNumber....................................11
			4.3.6 attrCertValidityPeriod..........................11
			4.3.7 attributes......................................12
			4.3.8 issuerUniqueID..................................12
			4.3.9 extensions......................................12
			4.4 Extensions............................................12
			4.4.1 Audit Identity..................................12
			4.4.2 AC Targeting....................................13
			4.4.3 authorityKeyIdentifier..........................14
			4.4.4 authorityInformationAccess......................14
			4.4.5 crlDistributionPoints...........................15
			4.5 Attribute Types.......................................15
			4.5.1 Service Authentication Info.....................16
			4.5.2 Access Identity.................................16
			4.5.3 Charging Identity...............................16
			4.5.4 Group...........................................17
			4.5.5 Role............................................17
			4.5.6 Clearance.......................................17
			4.6 PKC Extensions........................................18
			4.6.1 AAControls......................................18
			4.7 Profile of AC Issuer's PKC............................19
			5. Attribute Certificate Validation............................19
			6. Revocation..................................................21
			6.1.1 "Never revoke" method...........................21
			6.1.2 "Pointer from above" method.....................22
			6.1.3 "Pointer in AC" method..........................22
			7. Optional Features...........................................22
			7.1 Attribute Encryption..................................22
			7.2 Proxying..............................................23
			7.3 Use of ObjectDigestInfo...............................25
			7.4 AC Chaining...........................................26
			8. Security Considerations.....................................27
			9. References..................................................27
			Author's Addresses.............................................28
			Full Copyright Statement.......................................28
			Appendix A: "Compilable" ASN.1 Module..........................29
			Appendix B: Samples............................................32
			Appendix C: Changes this version / Open Issues.................32
	The provision of authentication, data integrity and		1. Introduction
	confidentiality services for current Internet protocols
	is well understood and many secure transports are defined
	(e.g. TLS, IPSEC, etc.). In many applications these
	services are not sufficient (or too cumbersome to
	administer) to provide the type of authorization services
	required.
	[RFC2459] specifies a profile for the use of X.509 public		The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
	key certificates in Internet protocols. This type of		in this document are to be interpreted as described in [RFC2119].
	certificate is typically used as an "identity"
	certificate, that is, it contains a certified name and
	public key, and any entity that can use the corresponding
	private key is treated as the named entity.
	When considering authorization, one is often less		A server makes an access control decision when a client requests
	interested in the identity of the entity than in some		access to a resource offered by that server. The server must ensure
	other attributes, (e.g. roles, account limits etc.),		that the client is authorized to access that resource. The server
	which should be used to make an authorization decision.		decision is based on the access control policy, the context of the
			request, and the identity and authorizations of the client. The
			access control policy and the context of the request are readily
			available to the server. Certificates may be used to provide
			identity and authorization information about the client.
	In many such cases, it is better to separate this		Similar access control decisions are made in other network
	information from the identity for management, security,		environments, such as a store-and-forward electronic mail
	interoperability or other reasons. However, this		environment. That is, access control decisions are not limited to
	authorization information also needs to be protected in a		client-server protocol environments.
	fashion similar to a public key certificate - the name
	for the structure used is an attribute certificate (an
	AC) which is a digitally signed (certified) set of
	attributes.
	An AC is a structure that is similar to an X.509 public		X.509 public key certificates (PKCs) [X.509],[RFC2459] bind an
	key certificate [RFC2459] with the main difference being		identity and a public key. The identity may be used to support
	that it contains no public key. The AC typically contains		identity-based access control decisions after the client proves that
	group membership, role, clearance and other access		it has access to the private key that corresponds to the public key
	control information associated with the AC owner. The		contained in the PKC. The public key is used to validate digital
	base syntax for ACs is also defined in the X.509 standard		signatures or cryptographic key management operations. However, not
	(making the term X.509 certificate ambiguous!). This		all access control decisions are identity-based. Rule-based, role-
	document specifies a profile of the X.509 AC suitable for		based, and rank-based access control decisions require additional
	authorization purposes in Internet protocols.		information. For example, information about a client's ability to
			pay for a resource access may be more important than the client's
			identity. Authorization information to support such access control
			decisions may be placed in a PKC extension or placed in a separate
			attribute certificate (AC).
	Farrell & Housley [Page 2]		The placement of authorization information in PKCs is usually
	When making an access decision based on an AC, an access		undesirable for two reasons. First, authorization information does
	decision function may need to ensure that the appropriate		not have the same lifetime as the binding of the identity and the
	AC owner is the entity that has requested access. For		public key. When authorization information is placed in a PKC
	example, one way in which the linkage between the request		extension, the general result is the shortening of the PKC useful
	and the AC can be achieved is if the AC has a "pointer"		lifetime. Second, the PKC issuer is not usually authoritative for
	to a PKC for the requestor and that PKC has been used to		the authorization information. This results in additional steps for
	authenticate the request.		the PKC issuer to obtain authorization information from the
			authoritative source.
	As there is often confusion about the difference between		For these reasons, it is often better to separate this authorization
	public key certificates (PKCs) and attribute certificates		information from the PKC. Yet, this authorization information also
	(ACs), an analogy may help. A PKC can be considered to be		needs to be protected in a fashion similar to a PKC. An attribute
	like a passport: it identifies the owner, tends to last		certificate (AC) provides this protection, and it is simply a
	for a long period and shouldn't be too easy to get. An AC		digitally signed (or certified) set of attributes.
	is more like an entry visa in that it is typically issued
	by a different authority and doesn't last as long. As
	acquiring an entry visa typically requires presenting a
	passport, getting a visa can be a simpler process.
	In conjunction with authentication services ACs provide a		An AC is a structure similar to a PKC; the main difference being
	means to transport authorization information securely to		that it contains no public key. An AC may contain attributes that
	applications. However, there are a number of possible		specify group membership, role, security clearance, and other access
	communication paths that an AC may take:		control information associated with the AC owner. The syntax for the
			AC is defined in Recommendation X.509 (making the term "X.509
			certificate" ambiguous). This document specifies a profile of the
			X.509 AC suitable for use with authorization information within
			Internet protocols.
	In some environments it is suitable for a client to		When making an access control decision based on an AC, an access
	"push" an AC to a server. This means that no new		control decision function may need to ensure that the appropriate AC
	connections between the client and server domains are		owner is the entity that has requested access. For example, one way
	required. It also means that no search burden is imposed		in which the linkage between the request and the AC can be achieved
			is if the AC has a "pointer" to a PKC for the requester and that PKC
			has been used to authenticate the access request.
			As there is often confusion about the difference between PKCs and
			ACs, an analogy may help. A PKC can be considered to be like a
			passport: it identifies the owner, tends to last for a long time and
			should not be trivial to obtain. An AC is more like an entry visa:
			it is typically issued by a different authority and does not last
			for as long a time. As acquiring an entry visa typically requires
			presenting a passport, getting a visa can be a simpler process.
			In conjunction with authentication services, ACs provide a means to
			securely provide authorization information to applications. However,
			there are a number of possible communication paths that an AC may
			take.
			In some environments it is suitable for a client to "push" an AC to
			a server. This means that no new connections between the client and
			server are required. It also means that no search burden is imposed
	on servers, which improves performance.		on servers, which improves performance.
	In other cases it is more suitable for a client simply to		In other cases, it is more suitable for a client simply to
	authenticate to the server and for the server to request		authenticate to the server and for the server to request ("pull")
	("pull") the client's AC from an AC issuer or a		the client's AC from an AC issuer or a repository. A major benefit
	repository. A major benefit of the "pull" model is that		of the "pull" model is that it can be implemented without changes to
	it can be implemented without changes to the client and		the client or client-server protocol. It is also more suitable for
	client/server protocol. It is also more suitable for some		some inter-domain cases where the client's rights should be assigned
	inter-domain cases where the client's rights should be		within the server's domain, rather than within the client's "home"
	assigned within the server's domain, rather than within		domain.
	the client's "home" domain.
	There are a number of possible exchanges that can occur		There are a number of possible exchanges that can occur and three
	and three entities involved (client, server and AC		entities involved (client, server and AC issuer). In addition the
	issuer). In addition the use of a directory service or		use of a directory service or other repository for AC retrieval MAY
	other repository for AC retrieval MAY be supported.		be supported.
	Farrell & Housley [Page 3]		Figure 1 shows an abstract view of the exchanges that may involve
	The diagram below shows an abstract view of the exchanges		ACs. This profile does not specify protocol for these exchanges.
	that may involve ACs. This profile does not specify
	protocol for all of these exchanges, though a limited
	case of client and server acquisition is defined below.
	+--------------+ +---------------+		+--------------+
	| | | |		| | Server Acquisition
	| AC Issuer +----+ | Repository |		| AC Issuer +----------------------------+
	| | | | |		| | |
	+--+-----------+ | Server +-------+-------+		+--+-----------+ |
	| | Acquisition |		| |
	|Client | |Server		| Client |
	|Acquisition +----------------------+ |Lookup		| Acquisition |
	| | |		| |
	+--+-----------+ +--+----+-------+		+--+-----------+ +--+------------+
	| | AC "push" | |		| | AC "push" | |
	| Client +------------------------+ Server |		| Client +-------------------------+ Server |
	| | (part of app. protocol)| |		| | (part of app. protocol) | |
	+--------------+ +---------------+		+--+-----------+ +--+------------+
	|		| |
	| Client Lookup		| Client | Server
	+--+-----------+		| Lookup +--------------+ | Lookup
	| |		| | | |
	| Repository | Figure 1: AC Exchanges		+---------------+ Repository +---------+
	| |		| |
	+--------------+		+--------------+
			Figure 1: AC Exchanges
	The remainder of the document is structured as follows:-		The remainder of the document is structured as follows:-
	Section 2 defines some terminology		Section 2 defines some terminology
	Section 3 specifies the requirements that this profile is		Section 3 specifies the requirements that this profile is to meet
	to meet
	Section 4 contains the profile of the X.509 AC		Section 4 contains the profile of the X.509 AC
	Section 5 specifies rules for AC validation		Section 5 specifies rules for AC validation
	Section 6 specifies rules for AC revocation checks		Section 6 specifies rules for AC revocation checks
	Section 7 specifies a limited AC acquisition protocol		Section 7 specifies optional features which MAY be supported but for
	Section 8 contains a conformance statement		which support is not required for conformance to this profile
	Appendices contain samples, a "compilable" ASN.1 module		Appendices contain a "compilable" ASN.1 module for this
	for this specification and a list of open issues.		specification, samples and a list of changes and open issues.
	2. Terminology		2. Terminology
	Term Meaning		For simplicity, we use the terms client and server in this
			specification. This is not intended to indicate that ACs are only to
			be used in client-server environments, e.g. in the S/MIME v3
			context, the mail user agent would, by turns, be both "client" and
			"server" in the sense the terms are used here.
	AC AttributeCertificate		Term Meaning
	AC user any entity that parses or processes an AC
	AC verifier any entity that checks the validity of an
	AC and then makes use of the result
	AC issuer the entity which signs the AC
	Farrell & Housley [Page 4]		AA Attribute Authority, the entity that issues the
	AC owner the entity indicated (perhaps indirectly)		AC, synonymous in this specification with "AC
	in the subject field of the AC		issuer"
	Client the entity which is requesting the action		AC Attribute Certificate
	for which authorization checks are to be		AC user any entity that parses or processes an AC
	made		AC verifier any entity that checks the validity of an AC and
	LAAP Limited AC Acquisition Protocol		then makes use of the result
	LRP LAAP responder		AC issuer the entity which signs the AC, synonymous in this
	LRQ LAAP requestor		specification with "AA"
	Proxying In this specification, Proxying is used		AC owner the entity indicated (perhaps indirectly) in the
	to mean the situation where an		owner field of the AC
	application server acts as an application		Client the entity which is requesting the action for
	client on behalf of a user. Proxying here		which authorization checks are to be made
	does not mean granting of authority.		Proxying In this specification, Proxying is used to mean
	PKC Public Key Certificate - uses the type		the situation where an application server acts as
	ASN.1 Certificate defined in X.509 and		an application client on behalf of a user.
	profiled in RFC 2459. This (non-standard)		Proxying here does not mean granting of authority.
	acronym is used in order to avoid		PKC Public Key Certificate - uses the type ASN.1
	confusion about the term "X.509		Certificate defined in X.509 and profiled in RFC
	certificate".		2459. This (non-standard) acronym is used in order
	Server the entity which requires that the		to avoid confusion about the term "X.509
	authorization checks are made		certificate".
			Server the entity which requires that the authorization
			checks are made
	3. Requirements		3. Requirements
	The following are the requirements that the "full"		This Attribute Certificate profile meets the following requirements.
	profile defined here meets.
	Time/Validity requirements:		Time/Validity requirements:
	1. Support for short-lived or long-lived ACs is		1. Support for short-lived or long-lived ACs is required. Typical
	required. Typical validity periods might be measured in		validity periods might be measured in hours, as opposed to
	hours, as opposed to months for X.509 public key		months for X.509 public key certificates. Short validity
	certificates. Short validity periods mean that ACs can be		periods mean that ACs can be useful without a revocation
	useful without a revocation scheme.		mechanism.
	Attribute Types:		Attribute Types:
	2. Issuers of ACs should be able to define their own		2. Issuers of ACs should be able to define their own attribute
	attribute types for use within closed domains.		types for use within closed domains.
	3. Some standard attribute types should be defined		3. Some standard attribute types should be defined which can be
	which can be contained within ACs, for example "access		contained within ACs, for example "access identity", "group",
	identity", "group", "role", "clearance", "audit		"role", "clearance", "audit identity", "charging id" etc.
	identity", "charging id" etc.		4. Standard attribute types should be defined so that it is
	4. Standard attribute types should be defined so that		possible for an AC verifier to distinguish between e.g. the
	it is possible for an AC verifier to distinguish between		"Administrators group" as defined by Baltimore and the
	e.g. the "Administrators group" as defined by SSE and the		"Administrators group" as defined by SPYRUS.
	"Administrators group" as defined by Widgets inc.
	5. ACs should support the encryption of some, or all,
	attributes (e.g. passwords for legacy applications). It
	should be possible for such an encrypted attribute to be
	Farrell & Housley [Page 5]
	deciphered by an appropriate AC verifier even where the
	AC has not been received directly from the AC owner (i.e.
	where the AC is proxied).
	Targeting of ACs:		Targeting of ACs:
	6. It should be possible to "target" an AC. This means		5. It should be possible to "target" an AC. This means that a
	that a given AC may be "targeted" at one, or a number of,		given AC may be "targeted" at one, or a small number of,
	servers/services in the sense that a trustworthy non-		servers in the sense that a trustworthy non- target will reject
	target will reject the AC for authorization decisions.		the AC for authorization decisions.
	Proxying:		Push vs. Pull
	7. It should be possible for a server to proxy an AC		6. ACs should be defined so that they can either be "pushed" by
	when it acts as a client (for another server) on behalf		the client to the server, or "pulled" by the server from a
	of the AC owner.		repository or other network service (which may be an online AC
	8. Proxying should be under the AC issuer's control, so		issuer).
	that not every AC is proxiable and so that a given
	proxiable AC can be proxied in a targeted fashion.
	9. Support for chains of proxies (with more than one
	intermediate server) is required.
	Push vs. Pull		4. The AC Profile
	10. ACs should be defined so that they can either be		This section presents a profile for attribute certificates that will
	"pushed" by the client to the server, or "pulled" by the		foster interoperability. This section is based upon the X.509
	server from a network service (whether the AC issuer or		attribute certificate format defined in [X.509]. The ISO/IEC/ITU
	an online repository).		documents use the 1993 version of ASN.1; while this document uses
			the 1988 ASN.1 syntax, the encoded certificate and standard
			extensions are equivalent. This section also defines private
			extensions for the Internet community.
	This profile specifically imposes no requirements for:		Attribute certificates may be used in a wide range of applications
			and environments covering a broad spectrum of interoperability goals
			and a broader spectrum of operational and assurance requirements.
			The goal of this document is to establish a common baseline for
			generic applications requiring broad interoperability and limited
			special purpose requirements. In particular, the emphasis will be
			on supporting the use of attribute certificates for informal
			Internet electronic mail, IPSec, and WWW applications.
	1. The meaning of a chain of ACs		Conforming implementations MUST support the profile specified in
	2. AC translation		this section.
	Support for such features may be part of some other		4.1 X.509 Attribute Certificate Definition
	profile.
	Farrell & Housley [Page 6]		X.509 contains the definition of an Attribute Certificate given
	4. The AC Profile		below. Types that are not defined can be found in [RFC2459].
	This section specifies the profile of the X.509 AC which		AttributeCertificate ::= SEQUENCE {
	is to be supported by conforming implementations.		acinfo AttributeCertificateInfo
			signatureAlgorithm AlgorithmIdentifier,
			signatureValue BIT STRING
			}
	4.1 X.509 AttributeCertificate Definition		AttributeCertificateInfo ::= SEQUENCE {
			version AttCertVersion DEFAULT v1,
			owner Owner,
			issuer AttCertIssuer,
			signature AlgorithmIdentifier,
			serialNumber CertificateSerialNumber,
			attrCertValidityPeriod AttCertValidityPeriod
			attributes SEQUENCE OF Attribute,
			issuerUniqueID UniqueIdentifier OPTIONAL,
			extensions Extensions OPTIONAL
			}
	X.509 contains the definition of an AttributeCertificate		AttCertVersion ::= INTEGER {v1(0), v2(1) }
	given below. Types that are not defined can be found in
	[RFC2459].
	<<This definition is from the PDAM.>>		Owner ::= SEQUENCE {
			baseCertificateID [0] IssuerSerial OPTIONAL,
			-- the issuer and serial number of
			-- the owner's Public Key Certificate
			entityName [1] GeneralNames OPTIONAL,
			-- the name of the claimant or role
			objectDigestInfo [2] ObjectDigestInfo OPTIONAL
			-- if present, version must be v2
			}
	AttributeCertificate ::= SIGNED {		ObjectDigestInfo ::= SEQUENCE {
	acinfo AttributeCertificateInfo		digestAlgorithm AlgorithmIdentifier,
	}		objectDigest OCTET STRING
			}
	AttributeCertificateInfo ::= SEQUENCE {		AttCertIssuer ::= SEQUENCE {
	version AttCertVersion DEFAULT v1,		issuerName GeneralNames OPTIONAL,
	owner CHOICE{		baseCertificateId [0] IssuerSerial OPTIONAL
	baseCertificateID [0] IssuerSerial,		}
	-- the issuer and serial number of
	-- the owner's Public Key Certificate
	entityName [1] GeneralNames,
	-- the name of the claimant or role
	objectDigestInfo [2] ObjectDigestInfo
	-- if present, version must be v2
	},
	issuer CHOICE {
	baseCertificateId [0] IssuerSerial,
	issuerName [1] GeneralNames
	},
	--AA that issued the attribute certificate
	signature AlgorithmIdentifier,
	serialNumber CertificateSerialNumber,
	attrCertValidityPeriod AttCertValidityPeriod
	attributes SEQUENCE OF Attribute,
	issuerUniqueID UniqueIdentifier OPTIONAL,
	extensions Extensions OPTIONAL
	}
	AttCertVersion ::= INTEGER {v1(0), v2(1) }		IssuerSerial ::= SEQUENCE {
			issuer GeneralNames,
			serial CertificateSerialNumber,
			issuerUID UniqueIdentifier OPTIONAL
			}
	ObjectDigestInfo ::= SEQUENCE {		AttCertValidityPeriod ::= SEQUENCE {
	digestAlgorithm AlgorithmIdentifier,		notBeforeTime GeneralizedTime,
	objectDigest OCTET STRING		notAfterTime GeneralizedTime
	}		}
	IssuerSerial ::= SEQUENCE {		4.2 Object Identifiers
	issuer GeneralNames,
	Farrell & Housley [Page 7]		This section lists the new object identifiers which are defined in
	serial CertificateSerialNumber,		this specification. Some of these are required only for support of
	issuerUID UniqueIdentifier OPTIONAL		optional features and are not required for conformance to this
	}		profile.
	AttCertValidityPeriod ::= SEQUENCE {		The following OIDs are imported from [RFC2459]:
	notBeforeTime GeneralizedTime,
	notAfterTime GeneralizedTime
	}
	4.2 Object Identifiers		id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
			dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
			id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
			id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
			id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
	The following OIDs are used:		The following new ASN.1 module OID is defined:
	<<		id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
	for interop testing purposes the SSE OID sse-ac-tst may
	be used instead of ietf-ac.
	sse-id OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 1201 }
	sse-ac-tst OBJECT IDENTIFIER ::= { sse-id 56 }
	>>
	ietf-ac OBJECT IDENTIFIER ::= <<tbs>>		The following AC extension OIDs are defined:
	ietf-ac-extensions OBJECT IDENTIFIER ::= { ietf-ac 1}
	ietf-ac-attributes OBJECT IDENTIFIER ::= { ietf-ac 2}
	4.3 Profile of Standard Fields.		id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
			id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 }
			id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 }
			The following registeredID form of name for targets and proxies is
			defined (see section 4.4.2 below):
			id-pe-ac-targeting-all OBJECT IDENTIIFIER ::=
			{ id-pe-ac-targeting 1 }
			The following PKC extension OIDs are defined:
			id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
			The following attribute OIDs are defined:
			id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
			id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
			id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
			id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
			id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
			id-aca-role OBJECT IDENTIFIER ::= { id-aca 5 }
			id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
			The following new access methods for an authorityInfoAccess
			extension are defined:
			id-ad-noRevStat OBJECT IDENTIFIER ::= { id-ad 3 }
			id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4 }
			4.3 Profile of Standard Fields
	For all GeneralName fields in this profile the otherName,		For all GeneralName fields in this profile the otherName,
	x400Address, ediPartyName and registeredId options MUST		x400Address, ediPartyName and registeredID options MUST NOT be used
	NOT be used unless otherwise specified (e.g. as in the		unless otherwise specified (e.g. as in the description of targeting
	description of targeting extension).		extension).
	4.3.1 version		This means that conforming implementations MUST be able to support
			the dNSName, directoryName, uniformResourceIdentifier and iPAddress
			fields in all cases where GeneralName is used. The MUST support
			requirements for each of these fields are as specified in [RFC2459],
			(mainly in section 4.2.1.7).
	This must be the default value of v1, i.e. not present in		4.3.1 version
	encoding.
	<<If we allow objectDigest then the above will have to		This must be the default value of v1, i.e. not present in encoding,
	change. There's also a comment to the PDAM which may		except where the owner is identified using the optional
	cause a change here.>>		objectDigestInfo field, as specified in section 7.3.
	4.3.2 owner		4.3.2 owner
	For any protocol where the AC is passed in an		For any protocol where the AC is passed in an authenticated message
	authenticated message or session, and where the		or session, and where the authentication is based on the use of an
	authentication is based on the use of an X.509 public key		X.509 public key certificate (PKC), the owner field SHOULD use the
	certificate (PKC), the owner field MUST use the
	baseCertificateID.		baseCertificateID.
	With the baseCertificateID option, the owner's PKC		With the baseCertificateID option, the owner's PKC serialNumber and
	serialNumber and issuer MUST be identical to the AC owner		issuer MUST be identical to the AC owner field. The PKC issuer MUST
			have a non-NULL X.500 name which is to be present as the single
	Farrell & Housley [Page 8]		value of the owner.baseCertificateID.issuer construct in the
	field. The PKC issuer MUST have a non-NULL X.500 name		directoryName field. The owner.baseCertificateID.issuerUID field
	which is to be present as the single value of the of the		MUST only be used if the owner's PKC contains an issuerUniqueID
	owner.issuerSerial.issuer construct in the directoryName
	field. The owner.issuerSerial.issuerUID field MUST only
	be used if the owner's PKC contains an issuerUniqueID
	field.		field.
	The above means that the baseCertificateID is only usable		The above means that the baseCertificateID is only usable with PKC
	with PKC profiles (like RFC2459) which mandate that the		profiles (like RFC2459) which mandate that the PKC issuer field
	PKC issuer field contain a value.		contain a value.
	If the owner field uses the entityName option and the		If the owner field uses the entityName option and the underlying
	underlying authentication is based on a PKC, then the		authentication is based on a PKC, then the entityName MUST be the
	entityName MUST be the same as the PKC subject field, or,		same as the PKC subject field, or, if the PKC subject is a "NULL"
	if the PKC subject is a "NULL" DN, then the entityName		DN, then the entityName field MUST be identical to one of the values
	field MUST be identical to one of the values of the PKC		of the PKC subjectAltName field extension. Note that [RFC2459]
	subjectAltName field extension. Note that [RFC2459]		mandates that the subjectAltNames extension be present if the PKC
	mandates that the subjectAltNames extension be present if		subject is a "NULL" DN.
	the PKC subject is a "NULL" DN.
	In any other case where the owner field uses the		In any other case where the owner field uses the entityName option
	entityName option then only one name SHOULD be present.		then only one name SHOULD be present.
	AC's conforming to this profile MUST NOT use the		Implementations conforming to this profile are not required to
	objectDigest field.		support the use of the objectDigest field. However, section 7.3
			specifies how this optional feature MAY be used.
	<<Uses of objectDigest are for further study.>>		Any protocol conforming to this profile SHOULD specify which AC
			owner option is to be used and how this fits with e.g. peer-entity
			authentication in the protocol.
	Any protocol conforming to this profile SHOULD specify		4.3.3 issuer
	which AC subject option is to be used and how this fits
	with e.g. peer-entity authentication in the protocol.
	4.3.3 issuer		ACs conforming to this profile MUST use the issuerName choice, which
			MUST contain one and only one GeneralName, which MUST contain its
			non-null value in the directoryName field. This means that all AC
			issuers MUST have non-NULL X.500 names.
	ACs conforming to this profile MUST use the issuerName		Part of the reason for the use of the issuerName field is that it
	choice which MUST contain one and only one GeneralName		allows the AC verifier to be independent of the AC issuer's public
	which MUST contain its non-null value in the		key infrastructure. Using the baseCertificateId field to reference
	directoryName field. This means that all AC issuers MUST		the AC issuer would mean that the AC verifier would have such a
	have non-NULL X.500 names.		dependency.
	Part of the reason for the use of the issuerName field is		4.3.4 signature
	that it allows the AC verifier to be independent of the		Contains the algorithm identifier used to validate the AC signature.
	AC issuer's public key infrastructure. Using the
	baseCertificateId field to reference the AC issuer would
	mean that the AC verifier would have such a dependency.
	4.3.4 signature		This MUST be one of the following algorithms defined in [RFC2459]
			section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha-
			1WithRSAEncryption, or ecdsa-with-SHA1 defined in [ECDSA] section
			3.2.
	Contains the algorithm identifier used to validate the AC		id-dsa-with-sha1 MUST be supported by all AC users. The other
	signature.		algorithms SHOULD be supported.
	Farrell & Housley [Page 9]		4.3.5 serialNumber
	This MUST be one of the following algorithms defined in
	[RFC2459] section 7.2: md5WithRSAEncryption, id-dsa-with-
	sha1 or sha-1WithRSAEncryption.
	id-dsa-with-sha1 MUST be supported by all AC users. The		For any conforming AC, the issuer/serialNumber pair MUST form a
	other algorithms SHOULD be supported.		unique combination, even if ACs are very short-lived (one second is
			the shortest possible validity due to the use of GeneralizedTime).
	4.3.5 serialNumber		AC issuers MUST force the serialNumber to be a positive integer,
			that is, the topmost bit in the DER encoding of the INTEGER value
			MUST NOT be a `1'B - this is to be done by adding a leading
			(leftmost) `00'H octet if necessary. This removes a potential
			ambiguity in mapping between a string of octets and a serialNumber.
	For any conforming AC, the issuer/serialNumber pair MUST		Given the uniqueness and timing requirements above serial numbers
	form a unique combination, even if ACs are very short-		can be expected to contain long integers, i.e. AC users MUST be able
	lived (one second is the shortest possible validity due		to handle more than 32 bit integers here.
	to the use of GeneralizedTime).
	AC issuers MUST force the serialNumber to be a positive		There is no requirement that the serial numbers used by any AC
	integer, that is, the topmost bit in the DER encoding of		issuer follow any particular ordering, in particular, they need not
	the INTEGER value MUST NOT be a `1'B - this is to be done		be monotonically increasing with time.
	by adding a leading (leftmost) `00'H octet if necessary.
	This removes a potential ambiguity in mapping between a
	string of octets and a serialNumber.
	Given the uniqueness and timing requirements above serial		4.3.6 attrCertValidityPeriod
	numbers can be expected to contain long integers, i.e. AC
	users MUST be able to handle more than 32 bit integers
	here.
	There is no requirement that the serial numbers used by		The attrCertValidityPeriod (a.k.a. validity) field specifies the
	any AC issuer follow any particular ordering, in		period for which the AC issuer expects that the binding between the
	particular, they need not be monotonically increasing		owner and the attributes fields will be valid.
	with time.
	4.3.6 attrCertValidityPeriod		The generalized time type, GeneralizedTime, is a standard ASN.1 type
			for variable precision representation of time. Optionally, the
			GeneralizedTime field can include a representation of the time
			differential between local and Greenwich Mean Time.
	The attrCertValidityPeriod (a.k.a. validity) field		For the purposes of this profile, GeneralizedTime values MUST be
	specifies the period for which the AC issuer expects that		expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
	the binding between the owner and the attributes fields		times are YYYYMMDDHHMMSSZ), even where the number of seconds is
	will be valid.		zero. GeneralizedTime values MUST NOT include fractional seconds.
	GeneralizedTime encoding is restricted as specified in		(Note that the above is as specified in [RFC2459], section
	[RFC2459] for the corresponding fields in a PKC.		4.1.2.5.2.)
	Note that AC users MUST be able to handle the case where		Note that AC users MUST be able to handle the case where an AC is
	an AC is issued, which (at the time of parsing), has its		issued, which (at the time of parsing), has its entire validity
	entire validity period in the future (a "post-dated" AC).		period in the future (a "post-dated" AC). This is valid for some
	This is valid for some applications, e.g. backup.		applications, e.g. backup.
	4.3.7 attributes		4.3.7 attributes
	The attributes field gives information about the AC		The attributes field gives information about the AC owner. When the
	owner. When the AC is used for authorization this will		AC is used for authorization this will often contain a set of
	often contain a set of privileges. However, authorization		privileges.
	may also require support for "restrictions" - these are
	not carried within the attributes field (though they
	"belong" to the AC owner) but in the extensions field.
	The attributes field contains a SEQUENCE OF Attribute.		The attributes field contains a SEQUENCE OF Attribute. For a given
	For a given AC each attribute type in the sequence MUST		AC each attribute type in the sequence MUST be unique, that is, only
	be unique, that is, only one instance of each attribute		one instance of each attribute type can occur in a single AC. Each
	type can occur in a single AC. Each instance can however,		instance can however, be multi-valued.
	be multi-valued.
	AC consumers MUST be able to handle multiple values for		AC users MUST be able to handle multiple values for all attribute
	all attribute types.		types.
	Note that a conforming AC MAY contain an empty SEQUENCE,		Note that a conforming AC MAY contain an empty SEQUENCE, that is, no
	that is, no attributes at all.		attributes at all. <<Note: This is no longer required since we've
			dropped support for restrictions, so it will disappear in the next
			revision unless there's an explicit consensus for keeping it.>>
	Some standard attribute types are defined in section 4.5.		Some standard attribute types are defined in section 4.5.
	4.3.8 issuerUniqueID		4.3.8 issuerUniqueID
	This field MUST NOT be used.		This field MUST NOT be used.
	4.3.9 extensions		4.3.9 extensions
	The extensions field generally gives information about		The extensions field generally gives information about the AC as
	the AC as opposed to information about the AC owner. The		opposed to information about the AC owner.
	exception is where restrictions are to be supported. If
	one regards a restriction as a qualification on a
	privilege then it is clear that restrictions must be
	implemented as a critical extension.
	Section 4.4 defines the extensions that MAY be used with		Section 4.4 defines the extensions that MAY be used with this
	this profile. An AC that has no extensions conforms to		profile. An AC that has no extensions conforms to the profile. If
	the profile. If any other critical extension is used,		any other critical extension is used, then the AC does not conform
	then the AC does not conform to this profile. An AC that		to this profile. An AC that contains additional non-critical
	contains additional non-critical extensions still		extensions still conforms.
	conforms.
	4.4 Extensions.		4.4 Extensions.
	4.4.1 Restrictions		4.4.1 Audit Identity
	<<The authors solicit comment on whether support for		In some circumstances it is required (e.g. by data protection/data
	restrictions is needed. The benefit is that they may		privacy legislation) that audit trails do not contain records which
	allow the "positive" privilege syntax to be standardised		directly identify individuals. This may make the use of the owner
	more widely under the assumption that the corresponding		field of the AC unsuitable for use in audit trails.
	restriction syntax need only be understood "locally". On
	the other hand, we can omit this entirely if not many
	people see any benefit.>>
	A restriction is a "negative" privilege, for example an
	AC may "state" that the AC owner is a member of the
	administrative group except for purposes of backup.
	Restrictions would more properly be implemented as a
	separate field of the AC, but with the current syntax can
	only be supported via the use of a critical extension.
	The value of this extension will be a SEQUENCE OF		In order to allow for such cases an AC MAY contain an audit identity
	Attribute. The rule stated above for the AC attributes		extension. Ideally it SHOULD be infeasible to derive the AC owner's
	field (only one instance of each type etc.) applies here		identity from the audit identity value except with the co-operation
	also.		of the AC issuer.
	Each restriction MUST correspond to one attribute present		The value of the audit identity plus the AC issuer/serial should
	in the attributes field and must use the same attrType		then be used for audit/logging purposes. If the value of the audit
	OID as the related attribute.		identity is suitably chosen then a server/service administrator can
			track the behavior of an AC owner without being able to identify the
			AC owner.
	name ietf-ac-restrictions		The server/service administrator in combination with the AC issuer
	OID { ietf-ac-extensions 1 }		MUST be able to identify the AC owner in cases where misbehavior is
	syntax SEQUENCE OF Attribute		detected. This means that the AC issuer MUST be able to map
	criticality MUST be TRUE		"backwards" from the audit identity to the actual identity of the AC
			owner.
	4.4.2 Audit Identity		Of course, auditing could be based on the AC issuer/serial pair,
			however, this method doesn't allow tracking the same AC owner across
			different ACs. This means that an audit identity is only useful if
			it lasts for longer than the typical AC lifetime - how much longer
			is an issue for the AC issuer implementation. Auditing could also be
			based on the AC owner's PKC issuer/serial however, this will often
			allow the server/service administrator identify the AC owner.
	In some circumstances it is required (e.g. by data		As the AC verifier might otherwise use the AC subject or some other
	protection/data privacy legislation) that audit trails do		identifying value for audit purposes, this extension MUST be
	not contain records which directly identify individuals.		critical when used.
	This may make the use of the owner field of the AC
	unsuitable for use in audit trails.
	In order to allow for such cases an AC MAY contain an		Protocols that use ACs will often expose the identity of the AC
	audit identity extension. Ideally it SHOULD be infeasible		owner in the bits on-the-wire. In such cases, an "opaque" audit
	to derive the AC owner's identity from the audit identity		identity does not make use of the AC anonymous, it simply ensures
	value except with the co-operation of the AC issuer.		that the ensuing audit trails are "semi-anonymous".
	The value of the audit identity plus the AC issuer/serial		name id-pe-ac-auditIdentity
	should then be used for audit/logging purposes. If the		OID { id-pe 4 }
	value of the audit identity is suitably chosen then a		syntax OCTET STRING
	server/service administrator can track the behaviour of		criticality must be TRUE
	an AC owner without being able to identify the AC owner.
	The server/service administrator in combination with the		4.4.2 AC Targeting
	AC issuer MUST be able to identify the AC owner in cases
	where mis-behaviour is detected. This means that the AC
	issuer MUST be able to map "backwards" from the audit
	identity to the actual identity of the AC owner.
	Of course, auditing could be based on the AC		In order to allow that an AC is "targeted", the target information
	issuer/serial pair, however, this method doesn't allow		extension MAY be used to specify a number of servers/services. The
	tracking the same AC owner across different ACs. This		intent is that the AC should only be usable at the specified
	means that an audit identity is only useful if it lasts		servers/services - an (honest) AC verifier who is not amongst the
	for longer than the typical AC lifetime - how much longer		named servers/services MUST reject the AC.
	is an issue for the AC issuer implementation. Auditing
	could also be based on the AC owner's PKC issuer/serial
	however, this will often allow the server/service
	administrator identify the AC owner.
	As the AC verifier might otherwise use the AC subject or		If this extension is not present then the AC is not targeted and may
	some other identifying value for audit purposes, this		be accepted by any server.
	extension MUST be critical when used.
	Protocols that use ACs will often expose the identity of		The targeting information simply consists of a list of named targets
	the AC owner in the bits on-the-wire. In such cases, an		or groups.
	"opaque" audit identity does not make use of the AC
	anonymous, it simply ensures that the ensuing audit
	trails are "semi-anonymous".
	name ietf-ac-auditId		The following syntax is used to represent the targeting information:
	OID { ietf-ac-extensions 3 }
	syntax OCTET STRING
	criticality must be TRUE
	4.4.3 AC Targeting and Proxying		Targets ::= SEQUENCE OF Target
			Target ::= CHOICE {
			targetName [0] GeneralName,
			targetGroup [1] GeneralName
			}
	In order to allow that an AC is "targeted" and to control		We represent a special target, called "ALL" which is a wildcard as a
	proxying, the proxy information extension MAY be used to		targetName with the registeredID choice and a value of {id-pe-ac-
	specify a number of servers/services. The intent is that		targeting 1}. This is an exception to the general rule stated above
	the AC should only be usable at the specified		about the use of GeneralName choices.
	servers/services - an (honest) AC verifier who is not
	amongst the named servers/services MUST reject the AC.
	If this extension is not present then the AC is not		The targets check passes if:
	proxiable. Any server which receives the AC such that the
	owner and the authenticated peer-entity do not match MUST
	reject the AC.
	When this extension is present we are essentially		the targets field contains one targetName which
	checking that the entity from which the AC was received		is the "ALL" value,
	was allowed to send it and that the AC is allowed to be		or,
	used by this recipient.		the current server (recipient) is one of the
			targetName fields in the targets part,
			or,
			the current server is a member of one of the
			targetGroup fields in the targets part.
	The targeting information consists of the direct		How the membership of a target within a targetGroup is determined is
	information (targets field) and an optional set of proxy		not defined here. It is assumed that any given target "knows" the
	information (proxies field). If the "direct check" or any		names of the targetGroup's to which it belongs or can otherwise
	of the "proxy" checks (see below) pass then the		determine its membership. For example, if the targetGroup were to be
	"targeting check" as a whole is successful.		a DNS domain and the AC verifier knows the DNS domain to which it
			belongs or it the targetGroup were "PRINTERS" and the AC verifier
			"knows" that it's a printer or print server.
	The effect is that the AC owner can send to any valid		name id-pe-ac-targeting
	target which can then only proxy to targets which are in		OID { id-pe 5 }
	one of the same "proxy sets" as itself.		syntax Targets
			criticality must be TRUE
	The following data structure is used to represent the		4.4.3 authorityKeyIdentifier
	targeting/proxying information.
	ProxyInfo ::= SEQUENCE {		The authorityKeyIdentifier extension as profiled in [RFC2459] MAY be
	owner CHOICE {		used to assist the AC verifier in checking the signature of the AC.
	baseCertificateID [0] IssuerSerial,		The [RFC2459] description should be read as if "CA" meant "AC
	subjectName [1] GeneralNames,		issuer". As with PKCs this extension SHOULD be included in ACs.
	objectDigestInfo [2] ObjectDigestInfo
	},
	targets [0] Targets OPTIONAL,
	proxies [1] SEQUENCE OF Targets OPTIONAL
	}
	Targets ::= SEQUENCE OF Target
	Target ::= CHOICE {
	targetName [0] GeneralName,
	targetGroup [1] GeneralName
	}
	Where no proxies or targets are present then the entire		name id-ce-authorityKeyIdentifier
	field MUST be omitted, that is, a zero-length sequence of		OID { id-ce 35 }
	Targets MUST NOT be present. There MUST be at least one		syntax AuthorityKeyIdentifier
	target or one proxy present, that is, one of the targets		criticality MUST be FALSE
	or proxies fields MUST be present.
	We represent a special target, called "ALL" which is a		4.4.4 authorityInformationAccess
	wildcard as a targetName with the registeredID choice and
	a value of {ietf-ac-extensions 4 1}. This is an exception
	to the general rule stated above about the use of
	GeneralName choices.
	The direct check passes if:		The authorityInformationAccess extension as profiled in [RFC2459]
			MAY be used to assist the AC verifier in checking the revocation
			status of the AC. See section 6 on revocation below for details.
	the identity of the client as established by the		The following accessMethod is used to indicate that revocation
	underlying authentication service matches the owner		status checking is not provided for this AC:
	field
	and
	(
	the targets field contains one targetName which
	is the "ALL" value
	or
	the current server (recipient) is one of the
	targetName fields in the targets part
	or
	the current server is a member of one of the
	targetGroup fields in the targets part.
	)
	How the membership of a target within a targetGroup is		id-ad-noRevStat OBJECT IDENTIFIER ::=
	determined is not defined here. It is assumed that any		{ id-ad 3 }
	given target "knows" the names of the targetGroup's to
	which it belongs or can otherwise determine its
	membership. For example, if the targetGroup were to be a
	DNS domain and the AC verifier knows the DNS domain to
	which it belongs or it the targetGroup were "PRINTERS"
	and the AC verifier "knows" that it's a printer or print
	server.
	A proxy check succeeds if		The following accessMethod is used to indicate that revocation
			status checking is provided for this AC, using the OCSP protocol
			defined in [RFC2560]:
	(		id-ad-ocsp OBJECT IDENTIFIER ::=
	the identity of the sender as established by		{ id-ad 1 }
	the underlying authentication service matches
	the owner field
	and
	(
	the current server "matches" any one of
	the proxy sets (where "matches" is as for
	the direct check above)
	)
	)
	or
	(
	the identity of the sender as established by
	the underlying authentication service "matches"
	one of the proxy sets (call it set "A")
	and
	(
	the current server is one of the targetName
	fields in the set "A"
	or
	the current server is a member of one of the
	targetGroup fields in set "A".
	)
	)
	Where an AC is proxied more than once a number of targets		The following accessMethod is used to indicate that revocation
	will be on the path from the original client which is		status checking is provided "below" this PKC or AC:
	normally, but not always, the AC owner. In such cases
	prevention of AC "stealing" requires that the AC verifier
	MUST check that all targets on the path are members of
	the same proxy set. It is the responsibility of the AC
	using protocol to ensure that a trustworthy list of
	targets on the path is available to the AC verifier.
	name ietf-ac-targeting		id-ad-acRevStatusLocation OBJECT IDENTIFIER ::=
	OID { ietf-ac-extensions 4 }		{ id-ad 4 }
	syntax ProxyInfo
	criticality must be TRUE
	4.4.4 authorityKeyIdentifier		The accessLocation field MUST contain a NULL directoryName.
	The authorityKeyIdentifier extension as profiled in		name id-ce-authorityInfoAccess
	[RFC2459] MAY be used to assist the AC verifier in		OID { id-pe 1 }
	checking the signature of the AC. The [RFC2459]		syntax AuthorityInfoAccessSyntax
	description should be read as if "CA" meant "AC issuer".		criticality MUST be TRUE
	As with PKCs this extension SHOULD be included in ACs.
	name id-ce-authorityKeyIdentifier		4.4.5 crlDistributionPoints
	OID { id-ce 35 }
	syntax AuthorityKeyIdentifier
	criticality MUST be FALSE
	4.4.5 authorityInformationAccess		The crlDistributionPoints extension as profiled in [RFC2459] MAY be
			used to assist the AC verifier in checking the revocation status of
			the AC. See section 6 on revocation below for details.
	The authorityInformationAccess extension as profiled in		name id-ce-cRLDistributionPoints
	[RFC2459] MAY be used to assist the AC verifier in		OID { id-ce 31 }
	checking the revocation status of the AC. See section 6		syntax CRLDistPointsSyntax
	on revocation below for details.		criticality SHOULD be FALSE
	The following accessMethod is used to indicate that		4.5 Attribute Types
	revocation status checking is not provided for this AC:
	ietf-ac-norevstat OBJECT IDENTIFIER ::=		Some of the attribute types defined below make use of the
	{ ietf-ac-extensions 5}		IetfAttrSyntax type defined below. The reasons for using this type
			are:
	The accessLocation field MUST contain a NULL		1. It allows a separation between the AC issuer and the attribute
	directoryName.		policy authority. This is useful for situations where a single
			policy authority (e.g. an organization) allocates attribute
			values, but where multiple AC issuers are deployed for
			performance, network or other reasons.
			2. The syntaxes allowed for values are restricted to OCTET STRING
			and OID, which reduces some of the matching complexities
			associated with GeneralName. All multi-valued attributes using
			this syntax are restricted so that each value MUST use the same
			choice of value syntax, that is, it is not allowed that one
			value use an OID but that a second value uses a string.
	name id-ce-authorityInfoAccess		IetfAttrSyntax ::= SEQUENCE OF SEQUENCE {
	OID { id-pe 1 }		policyAuthority[0] GeneralNames OPTIONAL,
	syntax AuthorityInfoAccessSyntax		values SEQUENCE OF CHOICE {
	criticality MUST be TRUE		octets OCTET STRING,
			oid OBJECT IDENTIFIER,
			string UTF8String
			}
			}
	4.5 Attribute Types		4.5.1 Service Authentication Info
	Some of the attribute types defined below make use of the		This attribute type identifies the AC owner to the server/service by
	IetfAttrSyntax type defined below. The reasons for using		a name and with optional authentication information. Typically this
	this type are:		will contain a username/password pair for a "legacy" application
			(and hence MAY need to be encrypted).
	1. It allows a separation between the AC issuer and the		This attribute type will typically be encrypted if the authInfo
	attribute policy authority. This is useful for situations		field contains sensitive information (e.g. a password).
	where a single policy authority (e.g. an organisation)
	allocates attribute values, but where multiple AC issuers
	are deployed for performance, network or other reasons.
	2. It allows the type of the attribute (privilege,
	restriction) to be made explicit which helps server
	implementations that provide an API on top of an AC
	validation module.
	3. The syntaxes allowed for values are restricted to		name id-aca-authenticationInfo
	OCTET STRING and OID, which reduces some of the matching		OID { id-aca 1 }
	complexities associated with GeneralName.		Syntax SvceAuthInfo
			values: Multiple allowed
	<<The authors solicit comment on whether this flexibility		SvceAuthInfo ::= SEQUENCE {
	is required. The alternative would be to encourage the		service GeneralName,
	use of attributes which have a GeneralName syntax and to		ident GeneralName,
	mandate this for role/group etc..>>		authInfo OCTET STRING OPTIONAL
			}
	IetfAttrSyntax ::= SEQUENCE OF {		4.5.2 Access Identity
	type INTEGER {
	privilege(0),
	restriction(1),
	other(2)
	}
	DEFAULT privilege,
	policyAuthority[0] GeneralNames OPTIONAL,
	values SEQUENCE OF CHOICE {
	octets OCTET STRING,
	oid OBJECT IDENTIFIER
	}
	}
	4.5.1 Service Authentication Info		An access identity identifies the AC owner to the server/service.
			For this attribute the authInfo field MUST NOT be present.
	This attribute type identifies the AC owner to the		name id-aca-accessIdentity
	server/service by a name and with optional authentication		OID { id-aca 2 }
	information. Typically this will contain a		syntax SvceAuthInfo
	username/password pair for a "legacy" application (and		values: Multiple allowed
	hence MAY need to be encrypted).
	This attribute type will typically be encrypted if the		4.5.3 Charging Identity
	authInfo field contains sensitive information (e.g. a
	password).
	name ietf-ac-authInfo		This attribute type identifies the AC owner for charging purposes.
	OID { ietf-ac-attributes 1}		Note that, in general, the charging identity will be different from
	Syntax SvceAuthInfo		other identities of the owner, for example, when the ownerÆs company
	values: Multiple allowed		is to be charged for service.
	SvceAuthInfo ::= SEQUENCE {		name id-aca-chargingIdentity
	service GeneralName,		OID { id-aca 3 }
	ident GeneralName,		syntax IetfAttrSyntax
	authInfo OCTET STRING OPTIONAL		values: Multiple allowed
	}
	4.5.2 Access Identity		4.5.4 Group
	An access identity identifies the AC owner to the		This attribute carries information about group memberships of the AC
	server/service. For this attribute the authInfo field		owner.
	MUST NOT be present.
	name ietf-ac-accessId		<<Might it be more useful to define OS-specific group attribute
	OID { ietf-ac-attributes 2}		types which map to UNIX gids and/or NT SIDs? Even with that,
	syntax SvceAuthInfo		application defined groups will be needed - should they use a
	values: Multiple allowed		standard group attribute or should appX-group attribute types be
			defined for each?>>
	4.5.3 Charging Identity		name id-aca-group
			OID { id-aca 4 }
			syntax IetfAttrSyntax
			values: Multiple allowed
	This attribute type identifies the AC owner for charging		4.5.5 Role
	purposes.
	name ietf-ac-chargingId		This attribute carries information about role allocations of the AC
	OID { ietf-ac-attributes 3}		owner.
	syntax IetfAttrSyntax
	values: Multiple allowed
	4.5.4 Group		name id-aca-role
			OID { id-aca 5 }
			syntax IetfAttrSyntax
			values: Multiple allowed
	This attribute carries information about group		4.5.6 Clearance
	memberships of the AC owner.
	<<Might it be more useful to define OS-specific group		This attribute (imported from [X.501]) carries clearance (security
	attribute types which map to UNIX gids and/or NT SIDs?		labeling) information about the AC owner.
	Even with that, application defined groups will be needed
	- should they use a standard group attribute or should
	appX-group attribute types be defined for each?>>
	name ietf-ac-group		name { id-at-clearance }
	OID { ietf-ac-attributes 4}		OID { joint-iso-ccitt(2) ds(5) module(1) selected-
	syntax IetfAttrSyntax		attribute-types(5) clearance (55) }
	values: Multiple allowed		syntax Clearance - imported from [X.501]
			values Multiple allowed
	4.5.5 Role		Clearance ::= SEQUENCE {
			policyId OBJECT IDENTIFIER,
			classList ClassList DEFAULT {unclassified},
			securityCategories
			SET OF SecurityCategory OPTIONAL
			}
	This attribute carries information about role allocations		ClassList ::= BIT STRING {
	of the AC owner.		unmarked (0),
			unclassified (1),
			restricted (2)
			confidential (3),
			secret (4),
			topSecret (5)
	name ietf-ac-role		}
	OID { ietf-ac-attributes 5}
	syntax IetfAttrSyntax
	values: Multiple allowed
	4.5.6 Clearance		SecurityCategory ::= SEQUENCE {
			type [0] IMPLICIT OBJECT IDENTIFIER,
			value [1] ANY DEFINED BY type
			}
	This attribute carries clearance (security labelling)		-- original syntax with MACRO
	information about the AC owner.		-- <<is the above equivalent??>>
			-- SecurityCategory ::= SEQUENCE {
			-- type [0] IMPLICIT SECURITY-CATEGORY,
			-- value [1] ANY DEFINED BY type
			-- }
			--
			-- SECURITY-CATEGORY MACRO ::=
			-- BEGIN
			-- TYPE NOTATION ::= type | empty
			-- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
			-- END
	name { id-at-clearance }		4.6 PKC Extensions
	OID { joint-iso-ccitt(2) ds(5) module(1) selected-
	attribute-types(5) clearance (55) }
	syntax Clearance - imported from [X.5??]
	values Multiple allowed
	Clearance ::= SEQUENCE {		Public key certificate extensions which assist in AC handling are
	policyId OBJECT IDENTIFIER,		defined in this section. At the moment only one new extension is
	classList ClassList DEFAULT {unclassified},		defined.
	securityCategories
	SET OF SecurityCategory OPTIONAL
	}
	ClassList ::= BIT STRING {		4.6.1 AAControls
	unmarked (0),
	unclassified (1),
	restricted (2)
	confidential (3),
	secret (4),
	topSecret (5)
	}
	SecurityCategory ::= SEQUENCE {		During AC validation a relying party has to answer the question "is
	type [0] IMPLICIT SECURITY-CATEGORY,		this AC issuer trusted to issue ACs containing this attribute"? The
	value [1] ANY DEFINED BY type		AAControls PKC extension, intended to be used in CA and AC Issuer
	}		PKCs, MAY be used to help answer the question. The use of AAControls
			is further described in section 5.
	SECURITY-CATEGORY MACRO ::=		id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
	BEGIN
	TYPE NOTATION ::= type | empty
	VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
	END
	4.5.7 EncryptedAttributes		aaControls EXTENSION ::= {
			SYNTAX AAControls
			IDENTIFIED BY { id-pe-aaControls}
			}
			AAControls ::= SEQUENCE {
			pathLenConstraint INTEGER (0..MAX) OPTIONAL,
			permittedAttrs [0] AttrSpec OPTIONAL,
			excludedAttrs [1] AttrSpec OPTIONAL,
			permitUnSpecified BOOLEAN DEFAULT TRUE
			}
			AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
	Where an AC will be carried in clear within an		The aaControls extension is used as follows:
	application protocol or where an AC contains some
	sensitive information (e.g. a legacy application
	username/password) then encryption of AC attributes MAY
	be needed.
	When a set of attributes are to be encrypted within an		The pathLenConstraint if present is interpreted as in [RFC2459], but
	AC, the cryptographic message syntax, EnvelopedData		now restricts the allowed "distance" between the AA CA, (a CA
	structure [CMS] is used to carry the ciphertext(s) and		directly trusted to include AAControls in its PKCs), and the AC
	associated per-recipient keying information.		issuer.
	This type of attribute encryption is targeted which means		The permittedAttrs field specifies a set of attribute types that any
	that before the AC is signed the attributes have been		AC issuer below this AA CA is allowed to include in ACs. If this
	encrypted for a set of predetermined recipients.		field is not present, it means that no attribute types are
			explicitly allowed (though the permitUnSpecified field may open
			things up).
	The AC then contains the ciphertext(s) inside its signed		The excludedAttrs field specifies a set of attribute types that no
	data. The "enveloped-data" (id-envelopedData) ContentType is		AC issuer is allowed to include in ACs. If this field is not
	used and the content field will contain the EnvelopedData		present, it means that no attribute types are explicitly disallowed
	type.		(though the permitUnSpecified field may close things down).
	Only one encryptedAttributes attribute can be present in		The permitUnSpecified field specifies how to handle attribute types
	an AC - however it MAY be multi-valued and each of its		which are not present in either the permittedAttrs or excludedAttrs
	values will contain an EnvelopedData.		fields. TRUE (the default) means that any unspecified attribute type
			is allowed in ACs; FALSE means that no unspecified attribute type is
			allowed.
	Each value can contain a set of attributes (each possibly		4.7 Profile of AC Issuer's PKC
	a multi-valued attribute) encrypted for a set of
	recipients.
	The cleartext that is encrypted has the type:		The AC Issuer's PKC MUST conform to [RFC2459] and MUST NOT
			explicitly indicate that the AC issuer can't sign. In order to avoid
			confusion (e.g. over serial numbers or revocations) an AC issuer
			MUST NOT also be a PKC Issuer (i.e. it can't be a CA as well), so
			the AC Issuer's PKC MUST NOT have a basicConstraints extension with
			isACA set to TRUE.
	ACClearAttrs ::= SEQUENCE {		If the AC issuer supports revocation of ACs then the AC issuer's PKC
	acIssuer GeneralName,		SHOULD contain an authorityInfoAccess extension with a new
	acSerial INTEGER,		accessMethod which assists the AC verifier in checking the status of
	attrs SEQUENCE OF Attribute		an AC.
	}
	The DER encoding of the ACClearAttrs structure is used as		The new accessMethod is:
	the encryptedContent field of the EnvelopedData, i.e. the
	DER encoding MUST be embedded in an OCTET STRING.
	The acIssuer and acSerial fields are present to prevent		id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4}
	ciphertext stealing - when an AC verifier has
	successfully decrypted an encrypted attribute it MUST
	then check that the AC issuer and serialNumber fields
	contain the same values. This prevents a malicious AC
	issuer from copying ciphertext from another AC issuer's
	AC into an AC issued by the malicious AC issuer.
	The procedure for an AC issuer when encrypting attributes		The accessLocation field MUST contain a single GeneralName
	is illustrated by the following (any other procedure that		containing either an X.500 Name or a URL. If accessLocation contains
	gives the same result MAY be used):		an X.500 Name, then this is the name of a directory entry where a
			revocation list for ACs issued by this AC issuer should be present
			as a value of the atributeCertificateRevocationList attribute. If
			accessLocation contains a URI, then this specifies the transport
			used for OCSP [RFC2560] requests. The AC issuer MUST, of course,
			maintain an OCSP responder at this location.
	1. Identify the sets of attributes that are to be		Note that in contrast to the use of authorityInfoAccess described in
	encrypted for each set of recipients.		section 4.4.4, in this case the extension is not present in the AC,
	2. For each attribute set which is to be encrypted:		but rather in the AC issuer's PKC.
	2.1. Create an EnvelopedData structure for the data for
	this set of recipients.
	2.2. Encode the EnvelopedData as a value of the
	EncryptedAttributes attribute
	2.3. Ensure the cleartext attribute(s) are not present in
	the to-be-signed AC
	3. Add the EncryptedAttribute (with its multiple		5. Attribute Certificate Validation
	values) to the AC		This section describes a basic set of rules that all "valid" ACs
			MUST satisfy. Some additional checks are also described which AC
			verifiers MAY choose to implement.
	Note that the rule that each attribute type (the OID)		To be valid an AC MUST satisfy all of the following:
	only occurs once may not hold after decryption. That is,
	an AC MAY contain the same attribute type both in clear
	and in encrypted form (and indeed more than once if the
	decryptor is a recipient for more than one
	EnvelopedData). One approach would be to merge attributes
	following decryption in order to re-establish the "once
	only" constraint.
	name ietf-ac-encAttrs		1. The AC signature must be cryptographically correct and the AC
	OID { ietf-ac-attributes 6}		issuer's PKC MUST be verified in accordance with [RFC2459].
	Syntax ContentInfo		2. The AC issuer's PKC MUST also conform to the profile specified
	values Multiple Allowed		in section 4.7 above.
			3. If the AC issuer is not directly trusted as an AC issuer (by
			configuration or otherwise), then the AC issuer's certification
			path must satisfy the additional PKC checks described below
			4. The time for which the AC is being evaluated MUST be within the
			AC validity (if the evaluation time is equal to either
			notBeforeTime or notAfterTime then the AC is timely, i.e. this
			check succeeds). Note that in some applications, the evaluation
			time MAY not be the same as the current time.
			5. The AC targeting check MUST pass (see section 4.4.3 above)
			6. If the AC contains any "unsupported" critical extensions then
			the AC MUST be rejected.
	4.6 PKC Extensions		"Support" for an extension in this context means:
	Public key certificate extensions which assist in AC		a. the AC verifier MUST be able to parse the extension value, and,
	handling are defined in this section.		b. where the extension value SHOULD cause the AC to be rejected, the
	<<just one for now, and hopefully, always!>>		AC verifier MUST reject the AC.
	4.6.1 AAControls		The following additional certification path checks (referred to in
			(2) above) MUST all succeed:
	During AC validation a relying party has to answer the		1. Some CA on the AC's certificate path MUST be directly trusted
	question "is this AC issuer trusted to issue ACs		to issue PKCs which precede the AC issuer in the certification
	containing this attribute"? The AAControls PKC extension,		path, call this CA the "AA CA".
	intended to be used in CA and AC Issuer PKCs, MAY be used		2. All PKC's on the path from the AA CA down to and including the
	to help answer the question. The use of AAControls is		AC issuer's PKC MUST contain an aaControls extension as defined
	further described in section 5.		below (the PKC with the AA CA's as subject need not contain
			this extension).
			3. Only those attributes in the AC which are allowed according to
			all of the aaControls extension values in all of the PKCs from
			the AA CA to the AC issuer, may be used for authorization
			decisions, all other attributes MUST be ignored (note that this
			check MUST be applied to the set of attributes following
			attribute decryption and that in such cases the id-aca-encAttrs
			type MUST also be checked).
	aaControls EXTENSION ::= {		Additional Checks:
	SYNTAX AAControls
	IDENTIFIED BY { ietf-ac-pkcexts-aaControls}
	}
	AAControls ::= SEQUENCE {
	pathLenConstraint INTEGER (0..MAX) OPTIONAL,
	permittedAttrs [0] AttrSpec OPTIONAL,
	excludedAttrs [1] AttrSpec OPTIONAL,
	permitUnSpecified BOOLEAN DEFAULT TRUE
	}
	AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
	The aaControls extension is used as follows:		1. The AC MAY be rejected on the basis of further AC verifier
			configuration, for example an AC verifier may be configured to
			reject ACs which contain or lack certain attribute types.
			2. If the AC verifier provides an interface that allows
			applications to query the contents of the AC, then the AC
			verifier MAY filter the attributes from the AC on the basis of
			configured information, e.g. an AC verifier might be configured
			not to return certain attributes to certain targets.
	The pathLenConstraint if present is interpreted as in		6. Revocation
	[RFC2459], but now restricts the allowed "distance"
	between the AA CA, (a CA directly trusted to include
	AAControls in its PKCs), and the AC issuer.
	The permittedAttrs field specifies a set of attribute		<<Input is solicited on the suitability of the 3-scheme approach.>>
	types that any AC issuer below this AA CA is allowed to
	include in ACs. If this field is not present, it means
	that no attribute types are explicitly allowed (though
	the permitUnSpecified field may open things up).
	The excludedAttrs field specifies a set of attribute		In many environments, the validity period of an AC is less than the
	types that no AC issuer is allowed to include in ACs. If		time required to issue and distribute revocation information.
	this field is not present, it means that no attribute		Therefore, short-lived ACs typically do not require revocation
	types are explicitly disallowed (though the		support. However, long-lived ACs and environments where ACs enable
	permitUnSpecified field may close things down).		high value transactions MAY require revocation support.
	The permitUnSpecified field specifies how to handle		The basic approach taken is to allow use of the following AC
	attribute types which are not present in either the		revocation related schemes.
	permittedAttrs or excludedAttrs fields. TRUE (the
	default) means that any unspecified attribute type is
	allowed in ACs; FALSE means that no unspecified attribute
	type is allowed.
	5. AttributeCertificate Validation		"Never revoke" scheme: ACs may be marked so that the relying party
			understands that no revocation status information will be made
			available.
	This section describes a basic set of rules that all		"Pointer from above" scheme: The PKC (or AC see section 7.4) of an
	"valid" ACs MUST satisfy. Some additional checks are also		AC issuer may "point" to sources of revocation status information
	described which AC verifiers MAY choose to implement.		for all ACs issued by that AC issuer, (with the exception of those
			marked using the never-revoke method above).
	To be valid an AC MUST satisfy all of the following:		"Pointer in AC" scheme: ACs may be marked (like PKCs) to "point" to
			sources of revocation status information (using an
			authorityInfoAccess or crlDistributionPoints extension in the AC
			itself).
	1. the AC signature must be cryptographically correct		The never revoke scheme requires a new authorityInfoAccess
	and the AC issuer's PKC MUST be verified in accordance		accessMethod. The pointer from above scheme also requires a new
	with [RFC2459]		authorityInfoAccess accessMethod. The pointer in AC scheme is as
	2. if the AC issuer is not directly trusted as an AC		specified in [RFC2459] and [RFC2560].
	issuer (by configuration or otherwise), then the AC
	issuer's certification path must satisfy the additional
	PKC checks described below
	3. the time of evaluation MUST be within the AC
	validity (if the evaluation time is equal to either
	notBeforeTime or notAfterTime then the AC is timely, i.e.
	this check succeeds)
	4. if an AC contains attributes apparently encrypted
	for the AC verifier then the decryption process MUST not
	fail - if decryption fails then the AC MUST be rejected
	5. the AC targeting check MUST pass (see section 4.4.3
	above)
	6. if the AC contains any "unsupported" critical
	extensions then the AC MUST be rejected.
	"Support" for an extension in this context means:		The never revoke scheme MUST be supported, the other schemes SHOULD
			be supported.
	a. the AC verifier MUST be able to parse the extension		6.1.1 "Never revoke" method
	value, and,
	b. where the extension value SHOULD cause the AC to be
	rejected, the AC verifier MUST reject the AC.
	The following additional certification path checks		Where an AC issuer does not support revocation status checks for a
	(referred to in (2) above) MUST all succeed:		particular AC, then an authority information access extension (id-
			pe-authorityInfoAccess) with an id-ad-noRevStat accessMethod as
			specified in section 4.4.4 above MUST be present and critical in the
			AC to indicate this.
	1. some CA on the AC's certificate path MUST be		Where no authority information access is present with this
	directly trusted to issue PKCs which preceed the AC		accessMethod, then the AC issuer is implicitly stating that
	issuer in the certification path, call this CA the "AA		revocation status checks are supported and one of the other methods
	CA"		below MUST be provided to allow AC verifiers to establish the
	2. all PKC's on the path from the AA CA down to and		revocation status of the AC.
	including the AC issuer's PKC MUST contain an aaControls
	extension as defined below (the PKC with the AA CA's as
	subject need not contain this extension)
	3. only those attributes in the AC which are allowed
	according to all of the aaControls extension values in
	all of the PKCs from the AA CA to the AC issuer, may be
	used for authorization decisions, all other attributes
	MUST be ignored (note that this check MUST be applied to
	the set of attributes following attribute decryption and
	that in such cases the ietf-ac-encAttrs type MUST also be
	checked)
	Additional Checks:		6.1.2 "Pointer from above" method
	1. The AC MAY be rejected on the basis of further AC		In this case the AC issuer's PKC contains an authority information
	verifier configuration, for example an AC verifier may be		access extension with an id-ad-acRevStatusLocation accessMethod as
	configured to reject ACs which contain or lack certain		described in section 4.7 above.
	attribute types
	2. If the AC verifier provides an interface that allows
	applications to query the contents of the AC, then the AC
	verifier MAY filter the attributes from the AC on the
	basis of configured information, e.g. an AC verifier
	might be configured not to return certain attributes to
	certain targets.
	6. Revocation		6.1.3 "Pointer in AC" method
	In many environments, the validity period of an AC is		AC revocation status MAY be checked using the methods described in
	less than the time required to issue and distribute		[RFC2459], but substituting the AC issuer wherever a CA is
	revocation information. Therefore, short-lived ACs do		mentioned.
	not require revocation support. However, long-lived ACs
	and environments where ACs enable high value transactions
	MAY require revocation support.
	In such cases, AC revocation status MAY be checked using		In these cases, the AC contains either an authorityInfoAccess or
	the methods described in [RFC2459], but substituting the		crlDistributionPoints extensions as defined in [RFC2459] and
	AC issuer wherever a CA is mentioned.		[RFC2560] respectively.
	Note however that this does not impose a requirement for		7. Optional Features
	conformant AC issuers to be able to issue CRLs.
	Where an AC issuer does not support revocation status		This section specifies features that MAY be implemented. Conformance
	checks for a particular AC, then an authority information		to this specification does NOT require support for these features.
	access extension (id-pe-authorityInfoAccess) MUST be
	present and critical in the AC to indicate this. Where no
	authority information access is present, then the AC
	issuer is implicitly stating that revocation checks are
	supported and mechanisms in accordance with [RFC2459]
	MUST be provided to allow AC verifiers to establish the
	revocation status of the AC.
	The accessMethod used to handle this case is described		7.1 Attribute Encryption
	above.
	7. Limited AC Acquisition Protocol		Where an AC will be carried in clear within an application protocol
			or where an AC contains some sensitive information (e.g. a legacy
			application username/password) then encryption of AC attributes MAY
			be needed.
	<<Note that this section is very likely to change and may		When a set of attributes are to be encrypted within an AC, the
	be removed, in particular if it is found that CMP or CMC		cryptographic message syntax, EnvelopedData structure [CMS] is used
	can be suitably extended to support AC acquisition. If		to carry the ciphertext(s) and associated per-recipient keying
	the WG reaches a consensus that a new protocol is needed		information.
	then this section may move to a separate I-D. Even with a
	new protocol, it would be appropriate to examine
	extending CMP/CMC to handle more general AC management
	tasks. Basically, this is a "strawman">>
	There is clearly a requirement for an AC management		This type of attribute encryption is targeted, which means that
	protocol (or protocols, like [CMP] and [CMC]). Such		before the AC is signed the attributes have been encrypted for a set
	management protocols are not specified in this document.		of predetermined recipients.
	There is also a requirement for a specification of an
	LDAP schema, which is also not specified here.
	In addition to such protocols, which may be more suited		The AC then contains the ciphertext(s) inside its signed data. The
	to management of long-term or more sensitive (i.e. more		"enveloped-data" (id-envelopedData) ContentType is used and the
	"powerful") ACs, there is a requirement for a very		content field will contain the EnvelopedData type.
	simple, explicitly limited AC acquisition protocol.
	This protocol is required for cases where an AC user		The set of ciphertexts is included into the AC as the value of an
	wishes to acquire a "current" AC for an entity (possibly		encrypted attributes attribute. Only one encrypted attributes
	itself) leaving almost all details as to the content of		attribute can be present in an AC - however it MAY be multi-valued
	the AC to the AA or whatever network service acts on its		and each of its values will contain an EnvelopedData.
	behalf.
	We call this protocol the Limited AC Acquisition Protocol		Each value can contain a set of attributes (each possibly a multi-
	(LAAP). The are two entities involved, the LAAP requestor		valued attribute) encrypted for a set of recipients.
	(LRQ) and LAAP responder (LRP). The LR is typically an AC
	owner or an AC verifier; the LRP is typically the AA
	itself.
	LAAP is designed as a single-shot request/response		The cleartext that is encrypted has the type:
	protocol with no polling, retries, etc.
	The one and only feature of this protocol is to request		ACClearAttrs ::= SEQUENCE {
	an AC for a particular entity that may be either the		acIssuer GeneralName,
	requestor or some other entity. The response is the		acSerial INTEGER,
	requested AC or an error.		attrs SEQUENCE OF Attribute
			}
	The security of the request and response (e.g. whether		The DER encoding of the ACClearAttrs structure is used as the
	the requestor is authenticated or not) is out of scope		encryptedContent field of the EnvelopedData, i.e. the DER encoding
	and a matter for LAAP implementers. For example, an LRP		MUST be embedded in an OCTET STRING.
	may be configured so that it only ever issues ACs if the
	request is received over an authenticated channel (e.g.
	TLS with client authentication), or it may only issue
	"guest" privileges when the LRQ is not the owner of the
	AC.
	The protocol consists of a request message that may		The acIssuer and acSerial fields are present to prevent ciphertext
	specify the identity of the AC owner (for the third party		stealing - when an AC verifier has successfully decrypted an
	case), with an optional "profile". A profile is to be		encrypted attribute it MUST then check that the AC issuer and
	interpreted as a bilaterally agreed string that is mapped		serialNumber fields contain the same values. This prevents a
	to a set of AC contents by the LRP.		malicious AC issuer from copying ciphertext from another AC issuer's
			AC into an AC issued by the malicious AC issuer.
	LACRequestMessage ::= SEQUENCE {		The procedure for an AC issuer when encrypting attributes is
	owner [0] CHOICE{		illustrated by the following (any other procedure that gives the
	baseCertificateID [0] IssuerSerial,		same result MAY be used):
	-- the issuer and serial number of
	-- the owner's Public Key Certificate
	entityName [1] GeneralNames,
	-- the name of the claimant or role
	objectDigestInfo [2] ObjectDigestInfo
	-- if present, version must be v2
	} OPTIONAL,
	profile [1] UTF8String OPTIONAL
	}
	<<Note that this message syntax omits any "proof" that		1. Identify the sets of attributes that are to be encrypted for
	the LRQ has some valid reason to ask for an AC for the		each set of recipients.
	owner. It would be (at least) nice to be able to include		2. For each attribute set which is to be encrypted:
	such "proof", but can't be specified here since it might		2.1. Create an EnvelopedData structure for the data for this
	depend on the client/server authentication. Other than		set of recipients.
	via the profile field, the LRQ also cannot specify the		2.2. Encode the EnvelopedData as a value of the
	target(s) where the AC will have to be verified. We need		EncryptedAttributes attribute
	to consider if these are needed or not.>>		2.3. Ensure the cleartext attribute(s) are not present in the
			to-be-signed AC
			3. Add the EncryptedAttribute (with its multiple values) to the
			AC
	Each field is described below.		Note that the rule that each attribute type (the OID) only occurs
			once may not hold after decryption. That is, an AC MAY contain the
			same attribute type both in clear and in encrypted form (and indeed
			more than once if the decryptor is a recipient for more than one
			EnvelopedData). One approach implementers may choose, would be to
			merge attributes values following decryption in order to re-
			establish the "once only" constraint.
	"owner": when present this specifies that the LRQ wishes		name id-aca-encAttrs
	to acquire an AC for this owner. When absent, it means		OID { id-aca 6}
	that the LRQ is requesting an AC for itself (the LRP		Syntax ContentInfo
	should use the identity established from whatever		values Multiple Allowed
	underlying authentication is available). The rules for
	the owner field in the AC apply here (e.g. no use of
	objectDigestInfo).
	"profile": when present this is an request to the LRP		If an AC contains attributes apparently encrypted for the AC
	that an AC matching a certain profile be returned. The		verifier then the decryption process MUST not fail - if decryption
	definition of profiles is not in scope for this		fails then the AC MUST be rejected.
	specification and is expected to be a local matter. This
	field allows some simple switching.
	Note that this definition means that the minimal LAAP		7.2 Proxying
	request message consists of the octets `3000'H, an empty		In some circumstances, a server needs to proxy an AC when it acts as
	sequence. This message means "give me my current default		a client (for another server) on behalf of the AC owner. Such
	AC please".		proxying needs to be under the AC issuer's control, so that not
			every AC is proxiable and so that a given proxiable AC can be
			proxied in a targeted fashion. Support for chains of proxies (with
			more than one intermediate server) is also sometimes required.
	LACResponseMessage ::= CHOICE {		In order to meet this requirement we define another extension:
	ac [0] AttributeCertificate,		ProxyInfo, similar to the targeting extension.
	errorInfo [1] ErrorMsgContent -- from [CMP]
	}
	When an LRQ receives an AC from an LRP it SHOULD verify		When this extension is present the AC verifier must check that the
	the AC. In addition the LRQ SHOULD ensure that the AC		entity from which the AC was received was allowed to send it and
	"matches" the LAAP request issued. The only matching		that the AC is allowed to be used by this verifier.
	which applies in general is to ensure that the LAAP
	request owner field and the AC owner field are identical.
	Implementations may of course include additional checks.
	We define the following HTTP based transport for LAAP.		The proxying information consists of a set of proxy information,
			each of which is a set of targeting information. If the verifier and
			the sender of the AC are both named in the same proxy set then the
			AC can be accepted (the exact rule is given below).
	An LRQ should send a HTTP POST request to the LRP, the		The effect is that the AC owner can send the AC to any valid target
	POST data should consist of the DER encoding of the		which can then only proxy to targets which are in one of the same
	LACRequestMessage. The response is expected to have the		"proxy sets" as itself.
	MIME type "application/x-laapmsg" with the message data
	containing the DER encoding of the LACResponseMessage.
	<<how an LRQ knows the URL for an LRP is TBS>>		The following data structure is used to represent the
			targeting/proxying information.
	8. Conformance		ProxyInfo ::= SEQUENCE OF Targets
	This specification defines two levels of conformance,		A proxy check succeeds if
	basic and proxy-enabled. For each level the actors
	involved must meet different requirements. The intention
	is that support for basic conformance should allow for
	freely interoperable but fairly inflexible and
	"featureless" AC based authorization. Proxy-enabled
	conformance requires more effort from implementers, may
	not be as widely interoperable and is harder to
	administer, but does offer much more flexibility and many
	more features.
	A proxy-enabled AC issuer MUST be able to produce all of		(
	the attribute types and extensions specified above.		the identity of the sender as established by
			the underlying authentication service matches
			the owner field of the AC
			and
			(
			the current server "matches" any one of
			the proxy sets (where "matches" is as for
			the direct check above)
			)
			)
			or
			(
			the identity of the sender as established by
			the underlying authentication service "matches"
			one of the proxy sets (call it set "A")
			and
			(
			the current server is one of the targetName
			fields in the set "A"
			or
			the current server is a member of one of the
			targetGroup fields in set "A".
			)
			)
	A proxy-enabled AC verifier MUST "support" all of the		Where an AC is proxied more than once a number of targets will be on
	attribute types and extensions specified above.		the path from the original client, which is normally, but not
			always, the AC owner. In such cases prevention of AC "stealing"
			requires that the AC verifier MUST check that all targets on the
			path are members of the same proxy set. It is the responsibility of
			the AC using protocol to ensure that a trustworthy list of targets
			on the path is available to the AC verifier.
	"Support" in the previous paragraph means more than just		name id-pe-ac-proxying
	parsing. It means that the AC verifier MUST be able to		OID { id-pe 7 }
	reject any AC which should not be valid at that target		syntax ProxyInfo
	and MUST be able to make any attributes and extensions		criticality must be TRUE
	which were not fully processed available to the calling
	application.
	A proxy-enabled AC issuer is responsible to ensure that		7.3 Use of ObjectDigestInfo
	no AC produced could be accepted by a basic AC verifier
	in such a way as to cause a security breach.
	<<dunno if that can happen but it needs to be checked>>
	Basic conformance for an AC issuer means support for		<<In order to keep it simple, I've only allowed for a hash over a
	production of ACs which:		key, a hash over a certificate is thus not supported. If this or any
			other form of hash were allowed, then we'll need a
			digestedObjectInfo extension as well.>>
	1. MUST use the baseCertificateID owner field		In some environments it may be required that the AC is not linked
	alternative		either to an identity (via entityName) or to a PKC (via
	2. MUST NOT be post-dated		baseCertificateID). The objectDigestInfo choice in the owner field
	3. MAY contain AccessIdentity, Group and/or Role		allows support for this requirement.
	attributes with multiple values
	4. MUST NOT contain any other attributes which cannot
	safely be ignored by an AC verifier
	5. MAY contain the AuthorityKeyIdentifier extension
	6. MUST contain no critical extensions (and hence is
	not proxiable) except for authorityInformationAccess
	where revocation status checks are not provided
	7. MUST NOT contain encrypted attributes
	Basic conformance also requires support for the		If the owner is identified via the objectDigestInfo field then the
	AAControls PKC extension. A basic AC issuer MUST also		AC version field MUST contain v2 (i.e. the integer 1).
	support LAAP as specified in section 7 above.
	Basic conformance for an AC verifier means support for		The basic idea is to link the AC to an object by placing a hash of
	the validation of ACs which are produced by basic AC		that object into the owner field of the AC. For example, this allows
	issuers.		production of ACs that are linked to public keys rather than names
			or certificates, or production of ACs which contain privileges
			associated with an executable object (e.g. a Java class).
	A basic AC verifier MAY ignore the presence of any		In order to link an AC to a public key the hash must be calculated
	unsupported attributes or extensions (of course it must		over the representation of that public key which would be present in
	reject all ACs which contain unsupported critical		a PKC, specifically, the input for the hash algorithm MUST be the
	extensions) and need only make the values of the		DER encoding of a SubjectPublicKeyInfo representation of the key.
	remaining attributes available to applications.		Note: This includes the AlgorithmIdentifier as well as the BIT
			STRING. The rules given in [RFC2459] and [ECDSA] for encoding keys
			MUST be followed.
	A basic AC verifier MUST support the AAControls PKC		Note that if the public key value used as input to the hash function
	extension.		has been extracted from a PKC, then it is possible that the
			SubjectPublicKeyInfo from that PKC is NOT the value which should be
			hashed. This can occur if, e.g. DSA Dss-parms are inherited as
			described in section 7.3.3 of [RFC2459]. The correct input for
			hashing in this context will include the value of the parameters
			inherited from the CA's PKC, and thus may differ from the
			SubjectPublicKeyInfo present in the PKC.
	9. Security Considerations		Implementations which support this feature MUST be able to handle
			the representations of keys for the algorithms specified in section
			7.3 of [RFC2459] and those specified in [ECDSA].
	<<tbs>>		7.4 AC Chaining
	10. References		Section 5 above specifies a way of embedding AAControls into PKCs in
			order to control the attribute types for which an AA will be trusted
			by an AC verifier.
	[CMC] Myers, M., et al. "Certificate Management		There are two drawbacks to this mechanism:
	Messages over CMS",
	draft-ietf-pkix-cmc-03.txt, March 1999.
	[CMP] Adams, C., Farrell, S., "Internet X.509
	Public Key Infrastructure - Certificate
	Management Protocols", RFC2510.
	[CMS] Housley, R., "Cryptographic Message Syntax",
	draft-ietf-smime-cms-12.txt, March 1999.
	[ESS] Hoffman, P., "Enhanced Security Services for
	S/MIME",
	draft-ietf-smime-ess-12.txt, March 1999.
	[RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D.,		- PKC issuers have to know about authorization attribute types
	"Internet Public Key Infrastructure - X.509		- It is likely to require more frequent changes to AA's PKCs
	Certificate and CRL profile", RFC2459.
	[RFC2119] Bradner, S., "Key words for use in RFCs to
	Indicate Requirement Levels", RFC 2119.
	[X.509] ITU-T Recommendation X.509 (1997 E):
	Information Technology - Open Systems
	Interconnection - The Directory:
	Authentication Framework, June 1997.
	[X.208-88] CCITT. Recommendation X.208: Specification
	of Abstract Syntax Notation One (ASN.1).
	1988.
	[X.209-88] CCITT. Recommendation X.209: Specification
	of Basic Encoding Rules for Abstract Syntax
	Notation One (ASN.1). 1988.
	[X.501-88] CCITT. Recommendation X.501: The Directory -
	Models. 1988.
	[X.509-88] CCITT. Recommendation X.509: The Directory -
	Authentication Framework. 1988.
	[X.509-97] ITU-T. Recommendation X.509: The Directory -		These problems can be avoided by placing the equivalent information
	Authentication Framework. 1997.		into an AC for which the owner is an AA. However, this mechanism
	[XPDAM] ISO 9594-8 Information Technology - Open		requires chaining of ACs and thus imposes possibly significant costs
	systems Interconnection - The Directory:		both in terms of implementation and deployment complexity.
	Authentication Framework - Proposed Draft
	Amendment 1: Certificate Extensions,		In order to use this feature, an AC verifier presented with an AC,
	September 1998.		(belonging say to an end entity, call this EE-AC), must retrieve an
			AC which is owned by the issuer of EE-AC (call this AA-AC). The AC
			verifier next verifies AA-AC, extracts the AAControls information
			from AA-AC and uses this to decide which attributes from EE-AC
			should be trusted.
			Of course, the issuer of AA-AC may or may not be directly trusted by
			the AC verifier for the required attributes. In such a case, the AC
			verifier may have to retrieve another AC (AA2-AC), etc. until it
			finds one issued by a directly trusted AC issuer for each of the
			relevant attributes.
			AC verifiers which support this feature MUST also support the use of
			aaControls placed within PKCs.
			When verifying an AC, the verifier needs to determine when a chain
			of ACs is needed.
			When AAControls are present in an AC, they are placed as an
			extension of the AC, using the same extension defined in section
			4.6.1 above.
			When chaining ACs the following additional verification rules apply
			1. EE-AC.issuer and AA-AC.owner MUST contain the same value
			2. At the time of evaluation all ACs in the chain MUST be valid
			<<probably needs more about the AC chain validation algorithm>>
			8. Security Considerations
			Implementers MUST ensure that following validation of an AC, only
			attributes that the issuer is trusted to issue are used in
			authorization decisions. Other attributes, which MAY be present MUST
			be ignored.
			There is often a requirement to map between the authentication
			supplied by a particular protocol (e.g. TLS, S/MIME) and the AC
			owner's identity. If the authentication uses PKCs then this mapping
			is straightforward. However, it is envisaged that ACs will also be
			used in environments where the owner may be authenticated using
			other means. Implementers SHOULD be very careful in mapping the
			authenticated identity to the AC owner.
			9. References
			[CMC] Myers, M., et al. "Certificate Management Messages over
			CMS",
			draft-ietf-pkix-cmc-03.txt, March 1999.
			[CMP] Adams, C., Farrell, S., "Internet X.509 Public Key
			Infrastructure - Certificate Management Protocols",
			RFC2510.
			[CMS] Housley, R., "Cryptographic Message Syntax",
			draft-ietf-smime-cms-12.txt, March 1999.
			[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
			draft-ietf-smime-ess-12.txt, March 1999.
			[ECDSA] D. Johnson, W. Polk, "Internet X.509 Public Key
			Infrastructure Representation of Elliptic Curve Digital
			Signature Algorithm (ECDSA) Keys and Signatures in
			Internet X.509 Public Key Infrastructure Certificates"
			draft-ietf-pkix-ipki-ecdsa-01.txt, June 1999.
			[RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
			Public Key Infrastructure - X.509 Certificate and CRL
			profile", RFC2459.
			[RFC2560] Myers, M., et al., " X.509 Internet Public Key
			Infrastructure - Online Certificate Status Protocol -
			OCSP", RFC2560.
			[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
			3", RFC 2026, BCP 9, October 1996.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119.
			[X.501] ITU-T Recommendation X.501 : Information Technology -
			Open Systems Interconnection - The Directory: Models,
			1993.
			[X.509] ITU-T Recommendation X.509 (1997 E): Information
			Technology - Open Systems Interconnection - The
			Directory: Authentication Framework, June 1997.
			[X.208-88] CCITT Recommendation X.208: Specification of Abstract
			Syntax Notation One (ASN.1). 1988.
			[X.209-88] CCITT Recommendation X.209: Specification of Basic
			Encoding Rules for Abstract Syntax Notation One (ASN.1).
			1988.
			[X.501-88] CCITT Recommendation X.501: The Directory - Models.
			1988.
			[X.509-88] CCITT Recommendation X.509: The Directory -
			Authentication Framework. 1988.
			[X.509-97] ITU-T Recommendation X.509: The Directory -
			Authentication Framework. 1997.
			[FPDAM] ISO 9594-8 Information Technology û Open systems
			Interconnection - The Directory: Authentication
			Framework - Proposed Draft Amendment 1: Certificate
			Extensions, April 1999.
	Author's Addresses		Author's Addresses
	Stephen Farrell,		Stephen Farrell,
	SSE Ltd.		Baltimore Technologies
	Fitzwilliam Court,		61/62 Fitzwilliam Lane,
	Leeson Close,
	Dublin 2,		Dublin 2,
	IRELAND		IRELAND
	tel: +353-1-216-2910		tel: +353-1-647-3000
	email: stephen.farrell@sse.ie		email: stephen.farrell@baltimore.ie
	Russell Housley,		Russell Housley,
	SPYRUS,		SPYRUS,
	381 Elden Street,		381 Elden Street,
	Suite 1120,		Suite 1120,
	Herndon, VA 20170,		Herndon, VA 20170,
	USA		USA
	email: housley@spyrus.com		email: housley@spyrus.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (date). All Rights		Copyright (C) The Internet Society (date). All Rights Reserved.
	Reserved.
	This document and translations of it may be copied and		This document and translations of it may be copied and furnished to
	furnished to others, and derivative works that comment on		others, and derivative works that comment on or otherwise explain it
	or otherwise explain it or assist in its implementation		or assist in its implementation may be prepared, copied, published
	may be prepared, copied, published and distributed, in		and distributed, in whole or in part, without restriction of any
	whole or in part, without restriction of any kind,		kind, provided that the above copyright notice and this paragraph
	provided that the above copyright notice and this		are included on all such copies and derivative works. In addition,
	paragraph are included on all such copies and derivative		the ASN.1 module presented in Appendix B may be used in whole or in
	works. In addition, the ASN.1 module presented in		part without inclusion of the copyright notice. However, this
	Appendix B may be used in whole or in part without		document itself may not be modified in any way, such as by removing
	inclusion of the copyright notice. However, this		the copyright notice or references to the Internet Society or other
	document itself may not be modified in any way, such as		Internet organizations, except as needed for the purpose of
	by removing the copyright notice or references to the		developing Internet standards in which case the procedures for
	Internet Society or other Internet organizations, except		copyrights defined in the Internet Standards process shall be
	as needed for the purpose of developing Internet		followed, or as required to translate it into languages other than
	standards in which case the procedures for copyrights		English.
	defined in the Internet Standards process shall be
	followed, or as required to translate it into languages
	other than English.
	The limited permissions granted above are perpetual and		The limited permissions granted above are perpetual and will not be
	will not be revoked by the Internet Society or its		revoked by the Internet Society or its successors or assigns. This
	successors or assigns. This document and the information		document and the information contained herein is provided on an "AS
	contained herein is provided on an "AS IS" basis and THE		IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
	INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE		FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
	DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.
	Appendix A: Samples		Appendix A: "Compilable" ASN.1 Module
	tbs		PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
			internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-attribute-cert(12)}
	Appendix B: "Compilable" ASN.1 Module		DEFINITIONS EXPLICIT TAGS ::=
	<<tbs - will be supplied in '88 format>>		BEGIN
	Appendix C: Open Issues		-- EXPORTS ALL --
	This appendix lists open issues to be resolved (in order		IMPORTS
	of occurrence in the body of the document).
	1. Additional introductory text is required to motivate		-- PKIX Certificate Extensions
	the use of ACs		Attribute, AlgorithmIdentifier, CertificateSerialNumber,
	2. The ASN.1 has to be synched with the ISO FPDAM where		Extensions, UniqueIdentifier,
	necessary		id-pkix, id-pe, id-kp, id-ad
	3. An OID for ietf-ac has to be allocated		FROM PKIX1Explicit88 {iso(1) identified-organization(3)
	4. The objectDigest choice for owner has to be a MUST		dod(6) internet(1) security(5) mechanisms(5)
	NOT or else profiled (and explained!)		pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
	5. Are "restrictions" needed?
	6. Is "IetfAttrSyntax" needed?		GeneralName, GeneralNames
	7. Should OS-specific group attribute types be defined?		FROM PKIX1Implicit88 {iso(1) identified-organization(3)
	8. More explanatory text for encryptedAttributes is		dod(6) internet(1) security(5) mechanisms(5)
	needed.		pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
	9. Is a new AC acquisition protocol required? If not,
	how are ACs acquired? If so, should it be part of this		id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
	specification?		id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 }
	10. Are different conformance levels needed? If so, are		id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
	these the right ones?		id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 }
	11. Security considerations text needed
	12. References section to be fixed		id-pe-ac-targeting-all OBJECT IDENTIFIER ::=
	13. Compilable ASN.1 and samples are needed		{ id-pe-ac-targeting 1 }
			id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
			id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
			id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
			id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
			id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
			id-aca-role OBJECT IDENTIFIER ::= { id-aca 5 }
			id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
			id-ad-noRevStat OBJECT IDENTIFIER ::= { id-ad 3 }
			id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4 }
			AttributeCertificate ::= SEQUENCE {
			acinfo AttributeCertificateInfo,
			signatureAlgorithm AlgorithmIdentifier,
			signatureValue BIT STRING
			}
			AttributeCertificateInfo ::= SEQUENCE {
			version AttCertVersion DEFAULT v1,
			owner Owner,
			issuer AttCertIssuer,
			signature AlgorithmIdentifier,
			serialNumber CertificateSerialNumber,
			attrCertValidityPeriod AttCertValidityPeriod,
			attributes SEQUENCE OF Attribute,
			issuerUniqueID UniqueIdentifier OPTIONAL,
			extensions Extensions OPTIONAL
			}
			AttCertVersion ::= INTEGER {v1(0), v2(1) }
			Owner ::= SEQUENCE {
			baseCertificateID [0] IssuerSerial OPTIONAL,
			-- the issuer and serial number of
			-- the owner's Public Key Certificate
			entityName [1] GeneralNames OPTIONAL,
			-- the name of the claimant or role
			objectDigestInfo [2] ObjectDigestInfo OPTIONAL
			-- if present, version must be v2
			}
			ObjectDigestInfo ::= SEQUENCE {
			digestAlgorithm AlgorithmIdentifier,
			objectDigest OCTET STRING
			}
			AttCertIssuer ::= SEQUENCE {
			issuerName GeneralNames OPTIONAL,
			baseCertificateId [0] IssuerSerial OPTIONAL
			}
			IssuerSerial ::= SEQUENCE {
			issuer GeneralNames,
			serial CertificateSerialNumber,
			issuerUID UniqueIdentifier OPTIONAL
			}
			AttCertValidityPeriod ::= SEQUENCE {
			notBeforeTime GeneralizedTime,
			notAfterTime GeneralizedTime
			}
			Targets ::= SEQUENCE OF Target
			Target ::= CHOICE {
			targetName [0] GeneralName,
			targetGroup [1] GeneralName
			}
			IetfAttrSyntax ::= SEQUENCE OF SEQUENCE {
			policyAuthority[0] GeneralNames OPTIONAL,
			values SEQUENCE OF CHOICE {
			octets OCTET STRING,
			oid OBJECT IDENTIFIER,
			string UTF8String
			}
			}
			SvceAuthInfo ::= SEQUENCE {
			service GeneralName,
			ident GeneralName,
			authInfo OCTET STRING OPTIONAL
			}
			Clearance ::= SEQUENCE {
			policyId OBJECT IDENTIFIER,
			classList ClassList DEFAULT {unclassified},
			securityCategories
			SET OF SecurityCategory OPTIONAL
			}
			ClassList ::= BIT STRING {
			unmarked (0),
			unclassified (1),
			restricted (2),
			confidential (3),
			secret (4),
			topSecret (5)
			}
			SecurityCategory ::= SEQUENCE {
			type [0] IMPLICIT OBJECT IDENTIFIER,
			value [1] ANY DEFINED BY type
			}
			AAControls ::= SEQUENCE {
			pathLenConstraint INTEGER (0..MAX) OPTIONAL,
			permittedAttrs [0] AttrSpec OPTIONAL,
			excludedAttrs [1] AttrSpec OPTIONAL,
			permitUnSpecified BOOLEAN DEFAULT TRUE
			}
			AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
			ACClearAttrs ::= SEQUENCE {
			acIssuer GeneralName,
			acSerial INTEGER,
			attrs SEQUENCE OF Attribute
			}
			ProxyInfo ::= SEQUENCE OF Targets
			END
			Appendix B: Samples
			<<TBS>>
			Appendix C: Changes this version / Open Issues
			This appendix lists major changes since the previous revision and
			open issues to be resolved (in order of occurrence in the body of
			the document).
			Major changes since last revision:
			1. Re-structured conformance to profile + options as per Oslo
			consensus
			2. Moved acquisition protocol (LAAP)_to separate I-D
			3. Removed restrictions entirely
			4. Added new AC revocation options
			5. Added optional support for use of objectDigestInfo for keys
			6. Added optional support for chains of ACs
			7. Changed some syntax:
			Added UTF8String to IetfAttrSyntax value choice
			Split target & proxy extensions, removed owner from proxyInfo
			8. Allocated PKIX OIDs (note: check with repository before using
			these, the PKIX arc is currently available at
			http://www.imc.org/ietf-pkix/pkix-oid.asn)
			9. Added compiled ASN.1 module
			Open issues remaining:
			1. Should an AC without any attributes be allowed?
			2. Should OS-specific group attribute types be defined?
			3. Is the expansion of the SecurityCategory MACRO correct?
			4. Are three revocation schemes needed? Correct?
			5. Should more types of objectDigestInfo be allowed?
			6. AC chain section needs more description of chain validation.
			7. Samples - should they be a separate draft?
End of changes. 261 change blocks.
	1145 lines changed or deleted		1168 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/