< draft-ietf-pkix-ac509prof-01.txt   draft-ietf-pkix-ac509prof-02.txt >
PKIX Working Group S. Farrell PKIX Working Group S. Farrell
INTERNET-DRAFT Baltimore Technologies INTERNET-DRAFT Baltimore Technologies
Expires in six months R. Housley Expires in six months R. Housley
SPYRUS SPYRUS
October 1999 March 2000
An Internet Attribute Certificate An Internet Attribute Certificate
Profile for Authorization Profile for Authorization
<draft-ietf-pkix-ac509prof-01.txt> <draft-ietf-pkix-ac509prof-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at page 1, line 32 skipping to change at page 1, line 33
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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 accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
<<Comments are contained in angle brackets like this.>>
Abstract Abstract
Authorization services are required for numerous Internet protocols, This specification defines a profile for the use of X.509 Attribute
including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate Certificates in Internet Protocols. Attribute certificates may be
provides a structure that can form the basis for such services used in a wide range of applications and environments covering a
[X.509]. This specification defines a profile for the use of X.509 broad spectrum of interoperability goals and a broader spectrum of
Attribute Certificates to provide authorization services for operational and assurance requirements. The goal of this document is
Internet protocols. Some optional features are also specified which to establish a common baseline for generic applications requiring
are not required for conformance to the base profile. broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications.
Table of Contents Table of Contents
Status of this Memo.............................................1 Status of this Memo..............................................1
Abstract........................................................1 Abstract.........................................................1
Table of Contents...............................................1 Table of Contents................................................1
1. Introduction.................................................3 1. Introduction.................................................3
2. Terminology..................................................5 1.1 Delegation and AC chains...............................4
3. Requirements.................................................6 1.2 Attribute Certificate Distribution ("push" vs "pull")..4
4. The AC Profile...............................................7 1.3 Document Structure.....................................6
4.1 X.509 Attribute Certificate Definition.................7 2. Terminology..................................................7
4.2 Object Identifiers.....................................8 3. Requirements.................................................8
4.3 Profile of Standard Fields.............................9 4. The AC Profile...............................................9
4.3.1 version..........................................9 4.1 X.509 Attribute Certificate Definition.................9
4.3.2 owner...........................................10 4.2 Profile of Standard Fields............................11
4.3.3 issuer..........................................10 4.2.1 Version.........................................11
4.3.4 signature.......................................10 4.2.2 Holder..........................................11
4.3.5 serialNumber....................................11 4.2.3 Issuer..........................................12
4.3.6 attrCertValidityPeriod..........................11 4.2.4 Signature.......................................12
4.3.7 attributes......................................12 4.2.5 Serial Number...................................13
4.3.8 issuerUniqueID..................................12 4.2.6 Validity Period.................................13
4.3.9 extensions......................................12 4.2.7 Attributes......................................13
4.4 Extensions............................................12 4.2.8 Issuer Unique Identifier........................14
4.4.1 Audit Identity..................................12 4.2.9 Extensions......................................14
4.4.2 AC Targeting....................................13 4.3 Extensions............................................14
4.4.3 authorityKeyIdentifier..........................14 4.3.1 Audit Identity..................................14
4.4.4 authorityInformationAccess......................14 4.3.2 AC Targeting....................................15
4.4.5 crlDistributionPoints...........................15 4.3.3 Authority Key Identifier........................16
4.5 Attribute Types.......................................15 4.3.4 Authority Information Access....................17
4.5.1 Service Authentication Info.....................16 4.3.5 CRL Distribution Points.........................17
4.5.2 Access Identity.................................16 4.3.6 No Revocation Available.........................17
4.5.3 Charging Identity...............................16 4.4 Attribute Types.......................................18
4.5.4 Group...........................................17 4.4.1 Service Authentication Information..............18
4.5.5 Role............................................17 4.4.2 Access Identity.................................19
4.5.6 Clearance.......................................17 4.4.3 Charging Identity...............................19
4.6 PKC Extensions........................................18 4.4.4 Group...........................................19
4.6.1 AAControls......................................18 4.4.5 Role............................................19
4.7 Profile of AC Issuer's PKC............................19 4.4.6 Clearance.......................................20
5. Attribute Certificate Validation............................19 4.5 Profile of AC Issuer's PKC............................21
6. Revocation..................................................21 5. Attribute Certificate Validation............................22
6.1.1 "Never revoke" method...........................21 6. Revocation..................................................23
6.1.2 "Pointer from above" method.....................22 7. Optional Features...........................................24
6.1.3 "Pointer in AC" method..........................22 7.1 Attribute Encryption..................................24
7. Optional Features...........................................22 7.2 Proxying..............................................25
7.1 Attribute Encryption..................................22 7.3 Use of ObjectDigestInfo...............................26
7.2 Proxying..............................................23 7.4 AA Controls...........................................27
7.3 Use of ObjectDigestInfo...............................25 8. Security Considerations.....................................29
7.4 AC Chaining...........................................26 9. References..................................................30
8. Security Considerations.....................................27 Author's Addresses..............................................31
9. References..................................................27 Full Copyright Statement........................................31
Author's Addresses.............................................28 Appendix B: Object Identifiers..................................32
Full Copyright Statement.......................................28 Appendix B: "Compilable" ASN.1 Module...........................33
Appendix A: "Compilable" ASN.1 Module..........................29
Appendix B: Samples............................................32
Appendix C: Changes this version / Open Issues.................32
1. Introduction 1. Introduction
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119]. in this document are to be interpreted as described in [RFC2119].
A server makes an access control decision when a client requests A server makes an access control decision when a client requests
access to a resource offered by that server. The server must ensure access to a resource offered by that server. The server must ensure
that the client is authorized to access that resource. The server that the client is authorized to access that resource. The server
decision is based on the access control policy, the context of the decision is based on the access control policy, the context of the
request, and the identity and authorizations of the client. The request, and the identity and authorizations of the client. The
access control policy and the context of the request are readily access control policy and the context of the request are readily
available to the server. Certificates may be used to provide available to the server. Certificates may be used to provide
identity and authorization information about the client. identity and authorization information about the client.
Similar access control decisions are made in other network Similar access control decisions are made in other network
environments, such as a store-and-forward electronic mail environments, such as a store-and-forward electronic mail
environment. That is, access control decisions are not limited to environment. That is, access control decisions are not limited to
client-server protocol environments. client-server protocol environments.
X.509 public key certificates (PKCs) [X.509],[RFC2459] bind an X.509 public key certificates (PKCs) [X.509-97], [X.509-DAM],
identity and a public key. The identity may be used to support [PKIXPROF] bind an identity and a public key. The identity may be
identity-based access control decisions after the client proves that used to support identity-based access control decisions after the
it has access to the private key that corresponds to the public key client proves that it has access to the private key that corresponds
contained in the PKC. The public key is used to validate digital to the public key contained in the PKC. The public key is used to
signatures or cryptographic key management operations. However, not validate digital signatures or cryptographic key management
all access control decisions are identity-based. Rule-based, role- operations. However, not all access control decisions are identity-
based, and rank-based access control decisions require additional based. Rule-based, role-based, and rank-based access control
information. For example, information about a client's ability to decisions require additional information. For example, information
pay for a resource access may be more important than the client's about a client's ability to pay for a resource access may be more
identity. Authorization information to support such access control important than the client's identity. Authorization information to
decisions may be placed in a PKC extension or placed in a separate support such access control decisions may be placed in a PKC
attribute certificate (AC). extension or placed in a separate attribute certificate (AC).
The placement of authorization information in PKCs is usually The placement of authorization information in PKCs is usually
undesirable for two reasons. First, authorization information does undesirable for two reasons. First, authorization information does
not have the same lifetime as the binding of the identity and the not have the same lifetime as the binding of the identity and the
public key. When authorization information is placed in a PKC public key. When authorization information is placed in a PKC
extension, the general result is the shortening of the PKC useful extension, the general result is the shortening of the PKC useful
lifetime. Second, the PKC issuer is not usually authoritative for lifetime. Second, the PKC issuer is not usually authoritative for
the authorization information. This results in additional steps for the authorization information. This results in additional steps for
the PKC issuer to obtain authorization information from the the PKC issuer to obtain authorization information from the
authoritative source. authoritative source.
For these reasons, it is often better to separate this authorization For these reasons, it is often better to separate this authorization
information from the PKC. Yet, this authorization information also information from the PKC. Yet, this authorization information also
needs to be protected in a fashion similar to a PKC. An attribute needs to be protected in a fashion similar to a PKC. An attribute
certificate (AC) provides this protection, and it is simply a certificate (AC) provides this protection, and it is simply a
digitally signed (or certified) set of attributes. digitally signed (or certified) set of attributes.
An AC is a structure similar to a PKC; the main difference being An AC is a structure similar to a PKC; the main difference being
that it contains no public key. An AC may contain attributes that that it contains no public key. An AC may contain attributes that
specify group membership, role, security clearance, and other access specify group membership, role, security clearance, and other access
control information associated with the AC owner. The syntax for the control information associated with the AC holder. The syntax for
AC is defined in Recommendation X.509 (making the term "X.509 the AC is defined in Recommendation X.509 (making the term "X.509
certificate" ambiguous). This document specifies a profile of the certificate" ambiguous). This document specifies a profile of the
X.509 AC suitable for use with authorization information within X.509 AC suitable for use with authorization information within
Internet protocols. Internet protocols.
When making an access control decision based on an AC, an access When making an access control decision based on an AC, an access
control decision function may need to ensure that the appropriate AC control decision function may need to ensure that the appropriate AC
owner is the entity that has requested access. For example, one way holder is the entity that has requested access. For example, one way
in which the linkage between the request and the AC can be achieved 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 is if the AC has a "pointer" to a PKC for the requester and that PKC
has been used to authenticate the access request. has been used to authenticate the access request.
As there is often confusion about the difference between PKCs and 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 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 passport: it identifies the holder, tends to last for a long time
should not be trivial to obtain. An AC is more like an entry visa: and should not be trivial to obtain. An AC is more like an entry
it is typically issued by a different authority and does not last visa: it is typically issued by a different authority and does not
for as long a time. As acquiring an entry visa typically requires last for as long a time. As acquiring an entry visa typically
presenting a passport, getting a visa can be a simpler process. requires presenting a passport, getting a visa can be a simpler
process.
In conjunction with authentication services, ACs provide a means to 1.1 Delegation and AC chains
securely provide authorization information to applications. However,
there are a number of possible communication paths that an AC may The X.509 standard defines delegation as "Conveyance of privilege
take. from one entity that holds such privilege, to another entity". It
further defines a delegation path as "An ordered sequence of
certificates which, together with authentication of a privilege
asserter's identity can be processed to verify the authenticity of a
privilege asserter's privilege". It then goes on to define various
mechanisms for use in delegation cases involving "chains" of ACs.
As the administration and processing associated with such AC chains
is potentially much more complex than use of a single AC, and as the
use of ACs in the Internet is today in its infancy, this
specification does not address such AC chains. Other (future)
specifications may address the use of AC chains.
This means that conformant implementations are only REQUIRED to be
able to "handle" a single AC at a time. Note however, that
validation of that AC MAY require validation of a full PKC chain, as
specified in [PKIXPROF].
1.2 Attribute Certificate Distribution ("push" vs "pull")
As discussed above, ACs provide a mechanism to securely provide
authorization information to access control decision functions.
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 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 a server. This means that no new connections between the client and
server are required. It also means that no search burden is imposed 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 ("pull") authenticate to the server and for the server to request ("pull")
the client's AC from an AC issuer or a repository. A major benefit the client's AC from an AC issuer or a repository. A major benefit
of the "pull" model is that it can be implemented without changes to of the "pull" model is that it can be implemented without changes to
skipping to change at page 5, line 32 skipping to change at page 6, line 5
| | | |
| Client | Server | Client | Server
| Lookup +--------------+ | Lookup | Lookup +--------------+ | Lookup
| | | | | | | |
+---------------+ Repository +---------+ +---------------+ Repository +---------+
| | | |
+--------------+ +--------------+
Figure 1: AC Exchanges Figure 1: AC Exchanges
1.3 Document Structure
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 to meet Section 3 specifies the requirements that this profile is 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 optional features which MAY be supported but for Section 7 specifies optional features which MAY be supported but for
which support is not required for conformance to this profile which support is not required for conformance to this profile
Appendices contain a "compilable" ASN.1 module for this Appendices contain the list of OIDs required to support this
specification, samples and a list of changes and open issues. specification and a "compilable" ASN.1 module.
2. Terminology 2. Terminology
For simplicity, we use the terms client and server in this For simplicity, we use the terms client and server in this
specification. This is not intended to indicate that ACs are only to 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 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 context, the mail user agent would, by turns, be both "client" and
"server" in the sense the terms are used here. "server" in the sense the terms are used here.
Term Meaning Term Meaning
AA Attribute Authority, the entity that issues the AA Attribute Authority, the entity that issues the
AC, synonymous in this specification with "AC AC, synonymous in this specification with "AC
issuer" issuer"
AC Attribute Certificate AC Attribute Certificate
AC user any entity that parses or processes an AC AC user any entity that parses or processes an AC
AC verifier any entity that checks the validity of an AC and AC verifier any entity that checks the validity of an AC and
then makes use of the result then makes use of the result
AC issuer the entity which signs the AC, synonymous in this AC issuer the entity which signs the AC, synonymous in this
specification with "AA" specification with "AA"
AC owner the entity indicated (perhaps indirectly) in the AC holder the entity indicated (perhaps indirectly) in the
owner field of the AC holder field of the AC
Client the entity which is requesting the action for Client the entity which is requesting the action for
which authorization checks are to be made which authorization checks are to be made
Proxying In this specification, Proxying is used to mean Proxying In this specification, Proxying is used to mean
the situation where an application server acts as the situation where an application server acts as
an application client on behalf of a user. an application client on behalf of a user.
Proxying here does not mean granting of authority. Proxying here does not mean granting of authority.
PKC Public Key Certificate - uses the type ASN.1 PKC Public Key Certificate - uses the type ASN.1
Certificate defined in X.509 and profiled in RFC Certificate defined in X.509 and profiled in RFC
2459. This (non-standard) acronym is used in order 2459. This (non-standard) acronym is used in order
to avoid confusion about the term "X.509 to avoid confusion about the term "X.509
skipping to change at page 7, line 16 skipping to change at page 9, line 7
Push vs. Pull Push vs. Pull
6. ACs should be defined so that they can either be "pushed" by 6. ACs should be defined so that they can either be "pushed" by
the client to the server, or "pulled" by the server from a the client to the server, or "pulled" by the server from a
repository or other network service (which may be an online AC repository or other network service (which may be an online AC
issuer). issuer).
4. The AC Profile 4. The AC Profile
This section presents a profile for attribute certificates that will
foster interoperability. This section is based upon the X.509
attribute certificate format defined in [X.509]. The ISO/IEC/ITU
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.
Attribute certificates may be used in a wide range of applications Attribute certificates may be used in a wide range of applications
and environments covering a broad spectrum of interoperability goals and environments covering a broad spectrum of interoperability goals
and a broader spectrum of operational and assurance requirements. and a broader spectrum of operational and assurance requirements.
The goal of this document is to establish a common baseline for The goal of this document is to establish a common baseline for
generic applications requiring broad interoperability and limited generic applications requiring broad interoperability and limited
special purpose requirements. In particular, the emphasis will be special purpose requirements. In particular, the emphasis will be
on supporting the use of attribute certificates for informal on supporting the use of attribute certificates for informal
Internet electronic mail, IPSec, and WWW applications. Internet electronic mail, IPSec, and WWW applications.
This section presents a profile for attribute certificates that will
foster interoperability. This section also defines some private
extensions for the Internet community.
While the ISO/IEC/ITU documents use the 1993 (or later) version of
ASN.1; as has been done for PKCs [PKIXPROF], this document uses the
1988 ASN.1 syntax, the encoded certificate and standard extensions
are equivalent.
Where maximum lengths for fields are specified, these lengths refer
to the DER encoding and do not include the ASN.1 tag or length
fields.
Conforming implementations MUST support the profile specified in Conforming implementations MUST support the profile specified in
this section. this section.
4.1 X.509 Attribute Certificate Definition 4.1 X.509 Attribute Certificate Definition
X.509 contains the definition of an Attribute Certificate given X.509 contains the definition of an Attribute Certificate given
below. Types that are not defined can be found in [RFC2459]. below. Types that are not defined can be found in [PKIXPROF].
AttributeCertificate ::= SEQUENCE { AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING signatureValue BIT STRING
} }
AttributeCertificateInfo ::= SEQUENCE { AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion DEFAULT v1, version AttCertVersion DEFAULT v1,
owner Owner, holder Holder,
issuer AttCertIssuer, issuer AttCertIssuer,
signature AlgorithmIdentifier, signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber, serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute, attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL, issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL extensions Extensions OPTIONAL
} }
AttCertVersion ::= INTEGER {v1(0), v2(1) } AttCertVersion ::= INTEGER {v1(0), v2(1) }
Holder ::= SEQUENCE {
Owner ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL, baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of -- the issuer and serial number of
-- the owner's Public Key Certificate -- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL, entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role -- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- if present, version must be v2 -- if present, version must be v2
} }
ObjectDigestInfo ::= SEQUENCE { ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier, digestAlgorithm AlgorithmIdentifier,
objectDigest OCTET STRING objectDigest BIT STRING
} }
AttCertIssuer ::= SEQUENCE { AttCertIssuer ::= CHOICE {
issuerName GeneralNames OPTIONAL, oldForm GeneralNames,
baseCertificateId [0] IssuerSerial OPTIONAL newForm [0] SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateId [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
--at least one of issuerName, baseCertificateId or --
-- objectDigestInfo must be present --
-- if newForm is used, version must be v2--
} }
IssuerSerial ::= SEQUENCE { IssuerSerial ::= SEQUENCE {
issuer GeneralNames, issuer GeneralNames,
serial CertificateSerialNumber, serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL issuerUID UniqueIdentifier OPTIONAL
} }
AttCertValidityPeriod ::= SEQUENCE { AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime, notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime notAfterTime GeneralizedTime
} }
4.2 Object Identifiers Although the Attribute syntax is defined in [PKIXPROF], we repeat
the definition here for convenience.
This section lists the new object identifiers which are defined in
this specification. Some of these are required only for support of
optional features and are not required for conformance to this
profile.
The following OIDs are imported from [RFC2459]:
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 new ASN.1 module OID is defined:
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
The following AC extension OIDs are defined:
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 } Attribute ::= SEQUENCE {
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } type AttributeType,
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } values SET OF AttributeValue
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } -- at least one value is required --
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } }
id-aca-role OBJECT IDENTIFIER ::= { id-aca 5 } AttributeType ::= OBJECT IDENTIFIER
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
The following new access methods for an authorityInfoAccess AttributeValue ::= ANY
extension are defined:
id-ad-noRevStat OBJECT IDENTIFIER ::= { id-ad 3 } Implementers should note that the DER encoding (DER is defined in
id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4 } [X.208-88]) of the SET OF values requires ordering of the encodings
of the values. Though this issue arises with respect to
distinguished names, and has to be handled by [PKIXPROF]
implementations, its is much more significant in this context, since
the inclusion of multiple values is much more common in ACs.
4.3 Profile of Standard Fields 4.2 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 NOT be used x400Address, ediPartyName and registeredID options MUST NOT be used
unless otherwise specified (e.g. as in the description of targeting unless otherwise specified (e.g. as in the description of targeting
extension). extension).
This means that conforming implementations MUST be able to support The use of Kerberos [KRB] format names, encoded into the otherName,
the dNSName, directoryName, uniformResourceIdentifier and iPAddress SHOULD however, be supported using the krb5PrincipalName OID and the
KerberosName syntax as defined in [PKINIT].
This means that unless otherwise indicated,(e.g. for the role
attribute), conforming implementations MUST be able to support the
dNSName, directoryName, uniformResourceIdentifier and iPAddress
fields in all cases where GeneralName is used. The MUST support fields in all cases where GeneralName is used. The MUST support
requirements for each of these fields are as specified in [RFC2459], requirements for each of these fields are as specified in
(mainly in section 4.2.1.7). [PKIXPROF], (mainly in section 4.2.1.7).
4.3.1 version 4.2.1 Version
This must be the default value of v1, i.e. not present in encoding, This MUST be the default value of v1, i.e. not present in the DER
except where the owner is identified using the optional encoding, except where the holder is identified using the optional
objectDigestInfo field, as specified in section 7.3. objectDigestInfo field, as specified in section 7.3.
4.3.2 owner 4.2.2 Holder
For any protocol where the AC is passed in an authenticated message For any environment where the AC is passed in an authenticated
or session, and where the authentication is based on the use of an message or session, and where the authentication is based on the use
X.509 public key certificate (PKC), the owner field SHOULD use the of an X.509 public key certificate (PKC), the holder field SHOULD
baseCertificateID. use the baseCertificateID.
With the baseCertificateID option, the owner's PKC serialNumber and With the baseCertificateID option, the holder's PKC serialNumber and
issuer MUST be identical to the AC owner field. The PKC issuer MUST issuer MUST be identical to the AC holder field. The PKC issuer MUST
have a non-NULL X.500 name which is to be present as the single have a non empty distinguished name which is to be present as the
value of the owner.baseCertificateID.issuer construct in the single value of the holder.baseCertificateID.issuer construct in the
directoryName field. The owner.baseCertificateID.issuerUID field directoryName field. The holder.baseCertificateID.issuerUID field
MUST only be used if the owner's PKC contains an issuerUniqueID MUST only be used if the holder's PKC contains an issuerUniqueID
field. field (in which case, the same value MUST be present in the
holder.baseCertificateID.issuerUID_field). Thus, the
baseCertificateID is only usable with PKC profiles (like [PKIXPROF])
which mandate that the PKC issuer field contain a non empty
distinguished name value.
The above means that the baseCertificateID is only usable with PKC Note: An "empty" distinguished name is a distinguished name where
profiles (like RFC2459) which mandate that the PKC issuer field the SEQUENCE OF relative distinguished names is of zero length. In a
contain a value. DER encoding this has the value '3000'H.
If the owner field uses the entityName option and the underlying If the holder field uses the entityName option and the underlying
authentication is based on a PKC, then the entityName MUST be the authentication is based on a PKC, then the entityName MUST be the
same as the PKC subject field, or, if the PKC subject is a "NULL" same as the PKC subject field, unless the PKC subject field contains
DN, then the entityName field MUST be identical to one of the values an empty distinguished name. In that case, the entityName field MUST
of the PKC subjectAltName field extension. Note that [RFC2459] be identical to one of the values of the PKC subjectAltName field
mandates that the subjectAltNames extension be present if the PKC extension. Note that [PKIXPROF] mandates that the subjectAltNames
subject is a "NULL" DN. extension be present if the PKC subject is a non empty distinguished
name.
In any other case where the owner field uses the entityName option In any other case where the holder field uses the entityName option
then only one name SHOULD be present. then only one name SHOULD be present.
Implementations conforming to this profile are not required to Implementations conforming to this profile are not required to
support the use of the objectDigest field. However, section 7.3 support the use of the objectDigest field. However, section 7.3
specifies how this optional feature MAY be used. specifies how this optional feature MAY be used.
Any protocol conforming to this profile SHOULD specify which AC 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 holder option is to be used and how this fits with the supported
authentication in the protocol. authentication schemes define in that protocol.
4.3.3 issuer 4.2.3 Issuer
ACs conforming to this profile MUST use the issuerName choice, which ACs conforming to this profile MUST use the newForm.issuerName
MUST contain one and only one GeneralName, which MUST contain its choice, which MUST contain one and only one GeneralName, which MUST
non-null value in the directoryName field. This means that all AC contain a non empty distinguished name in the directoryName field.
issuers MUST have non-NULL X.500 names. This means that all AC issuers MUST have non empty distinguished
names.
Part of the reason for the use of the issuerName field is that it Part of the reason for the use of the issuerName field is that it
allows the AC verifier to be independent of the AC issuer's public allows the AC verifier to be independent of the AC issuer's public
key infrastructure. Using the baseCertificateId field to reference key infrastructure. Using the baseCertificateId field to reference
the AC issuer would mean that the AC verifier would have such a the AC issuer would mean that the AC verifier would have such a
dependency. dependency.
4.3.4 signature 4.2.4 Signature
Contains the algorithm identifier used to validate the AC signature. Contains the algorithm identifier used to validate the AC signature.
This MUST be one of the following algorithms defined in [RFC2459] This MUST be one of the following algorithms defined in [PKIXPROF]
section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha- section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha-
1WithRSAEncryption, or ecdsa-with-SHA1 defined in [ECDSA] section 1WithRSAEncryption, or ecdsa-with-SHA1 defined in [ECDSA] section
3.2. 3.2.
id-dsa-with-sha1 MUST be supported by all AC users. The other id-dsa-with-sha1 MUST be supported by all AC users. The other
algorithms SHOULD be supported. algorithms SHOULD be supported.
4.3.5 serialNumber 4.2.5 Serial Number
For any conforming AC, the issuer/serialNumber pair MUST form a For any conforming AC, the issuer/serialNumber pair MUST form a
unique combination, even if ACs are very short-lived (one second is unique combination, even if ACs are very short-lived (one second is
the shortest possible validity due to the use of GeneralizedTime). the shortest possible validity due to the use of GeneralizedTime).
AC issuers MUST force the serialNumber to be a positive integer, AC issuers MUST force the serialNumber to be a positive integer,
that is, the topmost bit in the DER encoding of the INTEGER value that is, the sign bit in the DER encoding of the INTEGER value MUST
MUST NOT be a `1'B - this is to be done by adding a leading be zero - this can be done by adding a leading (leftmost) `00'H
(leftmost) `00'H octet if necessary. This removes a potential octet if necessary. This removes a potential ambiguity in mapping
ambiguity in mapping between a string of octets and a serialNumber. between a string of octets and an integer value.
Given the uniqueness and timing requirements above serial numbers Given the uniqueness and timing requirements above serial numbers
can be expected to contain long integers, i.e. AC users MUST be able can be expected to contain long integers. AC users MUST be able to
to handle more than 32 bit integers here. handle serialNumber values longer than 32 bits. Conformant ACs MUST
NOT use serialNumber values longer than 20 octets.
There is no requirement that the serial numbers used by any AC There is no requirement that the serial numbers used by any AC
issuer follow any particular ordering, in particular, they need not issuer follow any particular ordering, in particular, they need not
be monotonically increasing with time. be monotonically increasing with time, but they MUST be unique for a
given AC issuer.
4.3.6 attrCertValidityPeriod 4.2.6 Validity Period
The attrCertValidityPeriod (a.k.a. validity) field specifies the The attrCertValidityPeriod (a.k.a. validity) field specifies the
period for which the AC issuer expects that the binding between the period for which the AC issuer expects that the binding between the
owner and the attributes fields will be valid. holder and the attributes fields will be valid.
The generalized time type, GeneralizedTime, is a standard ASN.1 type The generalized time type, GeneralizedTime, is a standard ASN.1 type
for variable precision representation of time. Optionally, the for variable precision representation of time. Optionally, the
GeneralizedTime field can include a representation of the time GeneralizedTime field can include a representation of the time
differential between local and Greenwich Mean Time. differential between local and Greenwich Mean Time.
For the purposes of this profile, GeneralizedTime values MUST be For the purposes of this profile, GeneralizedTime values MUST be
expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
times are YYYYMMDDHHMMSSZ), even where the number of seconds is times are YYYYMMDDHHMMSSZ), even where the number of seconds is
zero. GeneralizedTime values MUST NOT include fractional seconds. zero. GeneralizedTime values MUST NOT include fractional seconds.
(Note that the above is as specified in [RFC2459], section (Note that the above is as specified in [PKIXPROF], section
4.1.2.5.2.) 4.1.2.5.2.)
Note that AC users MUST be able to handle the case where an AC is Note that AC users MUST be able to handle the case where an AC is
issued, which (at the time of parsing), has its entire validity issued, which (at the time of parsing), has its entire validity
period in the future (a "post-dated" AC). This is valid for some period in the future (a "post-dated" AC). This is valid for some
applications, e.g. backup. applications, e.g. backup.
4.3.7 attributes 4.2.7 Attributes
The attributes field gives information about the AC owner. When the The attributes field gives information about the AC holder. When the
AC is used for authorization this will often contain a set of AC is used for authorization this will often contain a set of
privileges. privileges.
The attributes field contains a SEQUENCE OF Attribute. For a given The attributes field contains a SEQUENCE OF Attribute. Each
AC each attribute type in the sequence MUST be unique, that is, only Attribute MAY contain a SET OF values. For a given AC each attribute
one instance of each attribute type can occur in a single AC. Each type OID in the sequence MUST be unique, that is, only one instance
instance can however, be multi-valued. of each attribute can occur in a single AC. All instances can
however, be multi-valued.
AC users MUST be able to handle multiple values for all attribute AC users MUST be able to handle multiple values for all attribute
types. types.
Note that a conforming AC MAY contain an empty SEQUENCE, that is, no Note that an AC MUST contain at least one attribute, that is, the
attributes at all. <<Note: This is no longer required since we've SEQUENCE OF Attributes MUST NOT be of zero length.
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.2.8 Issuer Unique Identifier
This field MUST NOT be used. This field MUST NOT be used unless it is also used in the AC
issuer's PKC, in which case it MUST be used. Note that [PKIXPROF]
states that this field "SHOULD NOT" be used by conforming CAs, but
that applications SHOULD be able to parse PKCs containing the field.
4.3.9 extensions 4.2.9 Extensions
The extensions field generally gives information about the AC as The extensions field generally gives information about the AC as
opposed to information about the AC owner. opposed to information about the AC holder.
Section 4.4 defines the extensions that MAY be used with this Section 4.3 defines the extensions that MAY be used with this
profile. An AC that has no extensions conforms to the profile. If profile. An AC that has no extensions conforms to the profile. If
any other critical extension is used, then the AC does not conform any other critical extension is used, then the AC does not conform
to this profile. An AC that contains additional non-critical to this profile. An AC that contains additional non-critical
extensions still conforms. extensions still conforms.
4.4 Extensions. The extensions defined for ACs provide methods for associating
additional attributes with holders. This profile also allows
communities to define private extensions to carry information unique
to those communities. Each extension in an AC may be designated as
critical or non-critical. An AC using system MUST reject an AC if
it encounters a critical extension it does not recognize; however, a
non-critical extension may be ignored if it is not recognized.
Section 4.3 presents recommended extensions used within Internet
certificates and standard locations for information. Communities
may elect to use additional extensions; however, caution should be
exercised in adopting any critical extensions in ACs, which might
prevent use in a general context.
4.4.1 Audit Identity 4.3 Extensions.
4.3.1 Audit Identity
In some circumstances it is required (e.g. by data protection/data In some circumstances it is required (e.g. by data protection/data
privacy legislation) that audit trails do not contain records which privacy legislation) that audit trails do not contain records which
directly identify individuals. This may make the use of the owner directly identify individuals. This may make the use of the holder
field of the AC unsuitable for use in audit trails. field of the AC unsuitable for use in audit trails.
In order to allow for such cases an AC MAY contain an audit identity In order to allow for such cases an AC MAY contain an audit identity
extension. Ideally it SHOULD be infeasible to derive the AC owner's extension. Ideally it SHOULD be infeasible to derive the AC holder's
identity from the audit identity value except with the co-operation identity from the audit identity value except with the co-operation
of the AC issuer. of the AC issuer.
The value of the audit identity plus the AC issuer/serial should The value of the audit identity plus the AC issuer/serial SHOULD
then be used for audit/logging purposes. If the value of the audit then be used for audit/logging purposes. If the value of the audit
identity is suitably chosen then a server/service administrator can identity is suitably chosen then a server/service administrator can
track the behavior of an AC owner without being able to identify the use audit trails to track the behavior of an AC holder without being
AC owner. able to identify the AC holder.
The server/service administrator in combination with the AC issuer The server/service administrator in combination with the AC issuer
MUST be able to identify the AC owner in cases where misbehavior is MUST be able to identify the AC holder in cases where misbehavior is
detected. This means that the AC issuer MUST be able to map detected. This means that the AC issuer MUST be able to map
"backwards" from the audit identity to the actual identity of the AC "backwards" from the audit identity to the actual identity of the AC
owner. holder.
Of course, auditing could be based on the AC issuer/serial pair, Of course, auditing could be based on the AC issuer/serial pair,
however, this method doesn't allow tracking the same AC owner across however, this method doesn't allow tracking the same AC holder
different ACs. This means that an audit identity is only useful if across different ACs. This means that an audit identity is only
it lasts for longer than the typical AC lifetime - how much longer useful if it lasts for longer than the typical AC lifetime - how
is an issue for the AC issuer implementation. Auditing could also be much longer is an issue for the AC issuer implementation. Auditing
based on the AC owner's PKC issuer/serial however, this will often could also be based on the AC holder's PKC issuer/serial however,
allow the server/service administrator identify the AC owner. this will often allow the server/service administrator identify the
AC holder.
As the AC verifier might otherwise use the AC subject or some other As the AC verifier might otherwise use the AC subject or some other
identifying value for audit purposes, this extension MUST be identifying value for audit purposes, this extension MUST be
critical when used. critical when used.
Protocols that use ACs will often expose the identity of the AC Protocols that use ACs will often expose the identity of the AC
owner in the bits on-the-wire. In such cases, an "opaque" audit holder in the bits on-the-wire. In such cases, an "opaque" audit
identity does not make use of the AC anonymous, it simply ensures identity does not make use of the AC anonymous, it simply ensures
that the ensuing audit trails are "semi-anonymous". that the ensuing audit trails are "semi-anonymous".
The value of an audit identity MUST NOT be longer than 20 octets.
name id-pe-ac-auditIdentity name id-pe-ac-auditIdentity
OID { id-pe 4 } OID { id-pe 4 }
syntax OCTET STRING syntax OCTET STRING
criticality must be TRUE criticality must be TRUE
4.4.2 AC Targeting 4.3.2 AC Targeting
In order to allow that an AC is "targeted", the target information In order to allow that an AC is "targeted", the target information
extension MAY be used to specify a number of servers/services. The extension MAY be used to specify a number of servers/services. The
intent is that the AC should only be usable at the specified intent is that the AC SHOULD only be usable at the specified
servers/services - an (honest) AC verifier who is not amongst the servers/services - an (honest) AC verifier who is not amongst the
named servers/services MUST reject the AC. named servers/services MUST reject the AC.
If this extension is not present then the AC is not targeted and may If this extension is not present then the AC is not targeted and may
be accepted by any server. be accepted by any server.
The targeting information simply consists of a list of named targets In this profile, the targeting information simply consists of a list
or groups. of named targets or groups.
The following syntax is used to represent the targeting information: The following syntax is used to represent the targeting information:
Targets ::= SEQUENCE OF Target Targets ::= SEQUENCE OF Target
Target ::= CHOICE { Target ::= CHOICE {
targetName [0] GeneralName, targetName [0] GeneralName,
targetGroup [1] GeneralName targetGroup [1] GeneralName,
targetCertificate [2] IssuerSerial,
targetDigest [3] ObjectDigestInfo
} }
We represent a special target, called "ALL" which is a wildcard as a The targetCertificate and targetDigest fields are only present to
targetName with the registeredID choice and a value of {id-pe-ac- allow future compatibility with [X.509-DAM] and MUST NOT be used.
targeting 1}. This is an exception to the general rule stated above
about the use of GeneralName choices.
The targets check passes if:
the targets field contains one targetName which The targets check passes if the current server (recipient) is one of
is the "ALL" value, the targetName fields in the targets part, or, the current server is
or, a member of one of the targetGroup fields in the targets part. In
the current server (recipient) is one of the this case, the current server is said to "match" the targeting
targetName fields in the targets part, extension.
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 determined is How the membership of a target within a targetGroup is determined is
not defined here. It is assumed that any given target "knows" the not defined here. It is assumed that any given target "knows" the
names of the targetGroup's to which it belongs or can otherwise names of the targetGroup's to which it belongs or can otherwise
determine its membership. For example, if the targetGroup were to be 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 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 belongs. Another example would be where the targetGroup is
"knows" that it's a printer or print server. "PRINTERS" and the AC verifier "knows" that it's a printer or print
server.
name id-pe-ac-targeting name id-pe-ac-targeting
<<will change this to id-ce-targetInformation from DAM if ISO can
change its syntax otherwise stick with the PKIX OID and live with
two different targeting extensions>>
OID { id-pe 5 } OID { id-pe 5 }
syntax Targets syntax Targets
criticality must be TRUE criticality MUST be TRUE
4.4.3 authorityKeyIdentifier 4.3.3 Authority Key Identifier
The authorityKeyIdentifier extension as profiled in [RFC2459] MAY be The authorityKeyIdentifier extension as profiled in [PKIXPROF] MAY
used to assist the AC verifier in checking the signature of the AC. be used to assist the AC verifier in checking the signature of the
The [RFC2459] description should be read as if "CA" meant "AC AC. The [PKIXPROF] description should be read as if "CA" meant "AC
issuer". As with PKCs this extension SHOULD be included in ACs. issuer". As with PKCs this extension SHOULD be included in ACs.
Note: An AC where the issuer field used the baseCertificateID choice
would not need an authorityKeyIdentifier extension as it is
explicitly linked to the key in the referred certificate. However,
as this profile states (in section 4.2.3) that ACs MUST use the
entityName choice, this does not arise here.
name id-ce-authorityKeyIdentifier name id-ce-authorityKeyIdentifier
OID { id-ce 35 } OID { id-ce 35 }
syntax AuthorityKeyIdentifier syntax AuthorityKeyIdentifier
criticality MUST be FALSE criticality MUST be FALSE
4.4.4 authorityInformationAccess 4.3.4 Authority Information Access
The authorityInformationAccess extension as profiled in [RFC2459] The authorityInformationAccess extension as defined in [PKIXPROF]
MAY be used to assist the AC verifier in checking the revocation MAY be used to assist the AC verifier in checking the revocation
status of the AC. See section 6 on revocation below for details. status of the AC. Note that support for the id-ad-caIssuers
accessMethod defined in [PKIXPROF] is NOT REQUIRED as in this
The following accessMethod is used to indicate that revocation profile, the authorityInformationAccess is only used for revocation
status checking is not provided for this AC: status checking. Conformant ACs containing this extension MUST
contain exactly one AccessDescription.
id-ad-noRevStat OBJECT IDENTIFIER ::=
{ id-ad 3 }
The following accessMethod is used to indicate that revocation The following accessMethod is used to indicate that revocation
status checking is provided for this AC, using the OCSP protocol status checking is provided for this AC, using the OCSP protocol
defined in [RFC2560]: defined in [OCSP]:
id-ad-ocsp OBJECT IDENTIFIER ::=
{ id-ad 1 }
The following accessMethod is used to indicate that revocation
status checking is provided "below" this PKC or AC:
id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
{ id-ad 4 }
The accessLocation field MUST contain a NULL directoryName. The accessLocation must contain a URI, this MUST contain an HTTP
URL, specifying the location of an OCSP responder. The AC issuer
MUST, of course, maintain an OCSP responder at this location.
name id-ce-authorityInfoAccess name id-ce-authorityInfoAccess
OID { id-pe 1 } OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax syntax AuthorityInfoAccessSyntax
criticality MUST be TRUE criticality MUST be FALSE
4.4.5 crlDistributionPoints 4.3.5 CRL Distribution Points
The crlDistributionPoints extension as profiled in [RFC2459] MAY be The crlDistributionPoints extension as profiled in [PKIXPROF] MAY be
used to assist the AC verifier in checking the revocation status of used to assist the AC verifier in checking the revocation status of
the AC. See section 6 on revocation below for details. the AC. See section 6 on revocation below for details.
Exactly one distribution point MUST be present, it MUST use the
DistributionPointName option, which MUST contain a fullName, which
MUST contain a single name form. That name MUST contain either an
HTTP URL or a distinguished name.
name id-ce-cRLDistributionPoints name id-ce-cRLDistributionPoints
OID { id-ce 31 } OID { id-ce 31 }
syntax CRLDistPointsSyntax syntax CRLDistPointsSyntax
criticality SHOULD be FALSE criticality MUST be FALSE
4.5 Attribute Types 4.3.6 No Revocation Available
This extension (imported from [X.509-DAM]) allows an AC issuer to
indicate that no revocation information will be made available for
this AC.
This extension MUST be non-critical, on the basis that an AC
verifier that does not understand it can still find a revocation
list (for example), but won't ever find an entry for the AC.
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e. '0500'H is the DER encoding)
criticality MUST be FALSE
4.4 Attribute Types
Some of the attribute types defined below make use of the Some of the attribute types defined below make use of the
IetfAttrSyntax type defined below. The reasons for using this type IetfAttrSyntax type defined below. The reasons for using this type
are: are:
1. It allows a separation between the AC issuer and the attribute 1. It allows a separation between the AC issuer and the attribute
policy authority. This is useful for situations where a single policy authority. This is useful for situations where a single
policy authority (e.g. an organization) allocates attribute policy authority (e.g. an organization) allocates attribute
values, but where multiple AC issuers are deployed for values, but where multiple AC issuers are deployed for
performance, network or other reasons. performance, network or other reasons.
2. The syntaxes allowed for values are restricted to OCTET STRING 2. The syntaxes allowed for values are restricted to OCTET STRING
and OID, which reduces some of the matching complexities OID and UTF8String, which reduces some of the matching
associated with GeneralName. All multi-valued attributes using complexities associated with more general syntaxes. All multi-
this syntax are restricted so that each value MUST use the same valued attributes using this syntax are restricted so that each
choice of value syntax, that is, it is not allowed that one value MUST use the same choice of value syntax, that is, it is
value use an OID but that a second value uses a string. not allowed that one value use an OID but that a second value
uses a string.
IetfAttrSyntax ::= SEQUENCE OF SEQUENCE { IetfAttrSyntax ::= SEQUENCE {
policyAuthority[0] GeneralNames OPTIONAL, policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE { values SEQUENCE OF CHOICE {
octets OCTET STRING, octets OCTET STRING,
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
string UTF8String string UTF8String
} }
} }
4.5.1 Service Authentication Info In the descriptions below, each attribute type is tagged as either
"Multiple Allowed" or "One Attribute value only; multiple values
within the IetfAttrSyntax". This refers to the SET OF
AttributeValue, the AttributeType still only occurs once, as
specified in section 4.2.7.
This attribute type identifies the AC owner to the server/service by 4.4.1 Service Authentication Information
a name and with optional authentication information. Typically this
will contain a username/password pair for a "legacy" application
(and hence MAY need to be encrypted).
This attribute type will typically be encrypted if the authInfo This attribute type identifies the AC holder to the server/service
field contains sensitive information (e.g. a password). by a name and MAY include optional service specific authentication
information. Typically this will contain a username/password pair
for a "legacy" application.
This attribute type will typically need to be encrypted if the
authInfo field contains sensitive information (e.g. a password).
name id-aca-authenticationInfo name id-aca-authenticationInfo
OID { id-aca 1 } OID { id-aca 1 }
Syntax SvceAuthInfo Syntax SvceAuthInfo
values: Multiple allowed values: Multiple allowed
SvceAuthInfo ::= SEQUENCE { SvceAuthInfo ::= SEQUENCE {
service GeneralName, service GeneralName,
ident GeneralName, ident GeneralName,
authInfo OCTET STRING OPTIONAL authInfo OCTET STRING OPTIONAL
} }
4.5.2 Access Identity 4.4.2 Access Identity
An access identity identifies the AC owner to the server/service. An access identity identifies the AC holder to the server/service.
For this attribute the authInfo field MUST NOT be present. For this attribute the authInfo field MUST NOT be present.
name id-aca-accessIdentity name id-aca-accessIdentity
OID { id-aca 2 } OID { id-aca 2 }
syntax SvceAuthInfo syntax SvceAuthInfo
values: Multiple allowed values: Multiple allowed
4.5.3 Charging Identity 4.4.3 Charging Identity
This attribute type identifies the AC owner for charging purposes. This attribute type identifies the AC holder for charging purposes.
Note that, in general, the charging identity will be different from Note that, in general, the charging identity will be different from
other identities of the owner, for example, when the ownerÆs company other identities of the holder, for example, when the holderÆs
is to be charged for service. company is to be charged for service.
name id-aca-chargingIdentity name id-aca-chargingIdentity
OID { id-aca 3 } OID { id-aca 3 }
syntax IetfAttrSyntax syntax IetfAttrSyntax
values: Multiple allowed values: One Attribute value only; multiple values within the
IetfAttrSyntax
4.5.4 Group 4.4.4 Group
This attribute carries information about group memberships of the AC This attribute carries information about group memberships of the AC
owner. holder.
<<Might it be more useful to define OS-specific group attribute
types which map to UNIX gids and/or NT SIDs? 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 id-aca-group name id-aca-group
OID { id-aca 4 } OID { id-aca 4 }
syntax IetfAttrSyntax syntax IetfAttrSyntax
values: Multiple allowed values: One Attribute value only; multiple values within the
IetfAttrSyntax
4.5.5 Role 4.4.5 Role
This attribute carries information about role allocations of the AC This attribute (imported from [X.509-DAM]) carries information about
owner. role allocations of the AC holder.
name id-aca-role The syntax used for this attribute is:
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
The roleAuthority field MUST NOT be used. The roleName field MUST be
present and MUST use the uniformResourceIdentifier field of the
GeneralName.
name id-at-role
OID { id-aca 5 } OID { id-aca 5 }
syntax IetfAttrSyntax syntax RoleSyntax
values: Multiple allowed values: Multiple allowed
4.5.6 Clearance 4.4.6 Clearance
This attribute (imported from [X.501]) carries clearance (security This attribute (imported from [X.501]) carries clearance (security
labeling) information about the AC owner. labeling) information about the AC holder.
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) module(1) selected-
attribute-types(5) clearance (55) }
syntax Clearance - imported from [X.501]
values Multiple allowed
Clearance ::= SEQUENCE { Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER, policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified}, classList ClassList DEFAULT {unclassified},
securityCategories securityCategories
SET OF SecurityCategory OPTIONAL SET OF SecurityCategory OPTIONAL
} }
ClassList ::= BIT STRING { ClassList ::= BIT STRING {
unmarked (0), unmarked (0),
skipping to change at page 18, line 4 skipping to change at page 20, line 38
SET OF SecurityCategory OPTIONAL SET OF SecurityCategory OPTIONAL
} }
ClassList ::= BIT STRING { ClassList ::= BIT STRING {
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
restricted (2) restricted (2)
confidential (3), confidential (3),
secret (4), secret (4),
topSecret (5) topSecret (5)
} }
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER, type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type value [1] ANY DEFINED BY type
} }
-- original syntax with MACRO -- This is the same as the original syntax which was defined
-- <<is the above equivalent??>> -- using the MACRO construct, as follows:
-- SecurityCategory ::= SEQUENCE { -- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT SECURITY-CATEGORY, -- type [0] IMPLICIT SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type -- value [1] ANY DEFINED BY type
-- } -- }
-- --
-- SECURITY-CATEGORY MACRO ::= -- SECURITY-CATEGORY MACRO ::=
-- BEGIN -- BEGIN
-- TYPE NOTATION ::= type | empty -- TYPE NOTATION ::= type | empty
-- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
-- END -- END
4.6 PKC Extensions The security category value above can uses the ASN.1 ANY construct.
Conformant ACs MUST only use UTF8String, OID and OCTET STRING
Public key certificate extensions which assist in AC handling are syntaxes for this value.
defined in this section. At the moment only one new extension is
defined.
4.6.1 AAControls
During AC validation a relying party has to answer the question "is
this AC issuer trusted to issue ACs containing this attribute"? The
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.
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
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
The aaControls extension is used as follows:
The pathLenConstraint if present is interpreted as in [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 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 types that no
AC issuer is allowed to include in ACs. If this field is not
present, it means that no attribute types are explicitly disallowed
(though the permitUnSpecified field may close things down).
The permitUnSpecified field specifies how to handle attribute types
which are not present in either the 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.
4.7 Profile of AC Issuer's PKC
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.
If the AC issuer supports revocation of ACs then the AC issuer's PKC
SHOULD contain an authorityInfoAccess extension with a new
accessMethod which assists the AC verifier in checking the status of
an AC.
The new accessMethod is:
id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4} name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) module(1) selected-
attribute-types(5) clearance (55) }
syntax Clearance - imported from [X.501]
values Multiple allowed
The accessLocation field MUST contain a single GeneralName 4.5 Profile of AC Issuer's PKC
containing either an X.500 Name or a URL. If accessLocation contains
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.
Note that in contrast to the use of authorityInfoAccess described in The AC Issuer's PKC MUST conform to [PKIXPROF] and its keyUsage MUST
section 4.4.4, in this case the extension is not present in the AC, NOT explicitly indicate that the AC issuer can't sign. In order to
but rather in the AC issuer's PKC. 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.
5. Attribute Certificate Validation 5. Attribute Certificate Validation
This section describes a basic set of rules that all "valid" ACs This section describes a basic set of rules that all "valid" ACs
MUST satisfy. Some additional checks are also described which AC MUST satisfy. Some additional checks are also described which AC
verifiers MAY choose to implement. verifiers MAY choose to implement.
To be valid an AC MUST satisfy all of the following: To be valid an AC MUST satisfy all of the following:
1. The AC signature must be cryptographically correct and the AC 1. The AC signature must be cryptographically correct and the AC
issuer's PKC MUST be verified in accordance with [RFC2459]. issuer's entire certification path (including the AC issuer's
PKC) MUST be verified in accordance with [PKIXPROF].
2. The AC issuer's PKC MUST also conform to the profile specified 2. The AC issuer's PKC MUST also conform to the profile specified
in section 4.7 above. in section 4.5 above.
3. If the AC issuer is not directly trusted as an AC issuer (by 3. The AC issuer MUST be directly trusted as an AC issuer (by
configuration or otherwise), then the AC issuer's certification configuration or otherwise).
path must satisfy the additional PKC checks described below
4. The time for which the AC is being evaluated MUST be within the 4. The time for which the AC is being evaluated MUST be within the
AC validity (if the evaluation time is equal to either AC validity (if the evaluation time is equal to either
notBeforeTime or notAfterTime then the AC is timely, i.e. this notBeforeTime or notAfterTime then the AC is timely, i.e. this
check succeeds). Note that in some applications, the evaluation check succeeds). Note that in some applications, the evaluation
time MAY not be the same as the current time. time MAY not be the same as the current time.
5. The AC targeting check MUST pass (see section 4.4.3 above) 5. The AC targeting check MUST pass (see section 4.3.2 above)
6. If the AC contains any "unsupported" critical extensions then 6. If the AC contains any "unsupported" critical extensions then
the AC MUST be rejected. the AC MUST be rejected.
"Support" for an extension in this context means: "Support" for an extension in this context means:
a. the AC verifier MUST be able to parse the extension value, and, a. the AC verifier MUST be able to parse the extension value, and,
b. where the extension value SHOULD cause the AC to be rejected, the b. where the extension value SHOULD cause the AC to be rejected, the
AC verifier MUST reject the AC. AC verifier MUST reject the AC.
The following additional certification path checks (referred to in
(2) above) MUST all succeed:
1. Some CA on the AC's certificate path MUST be directly trusted
to issue PKCs which precede the AC issuer in the certification
path, call this CA the "AA CA".
2. All PKC's on the path from the AA CA down to and 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 id-aca-encAttrs
type MUST also be checked).
Additional Checks: Additional Checks:
1. The AC MAY be rejected on the basis of further AC verifier 1. The AC MAY be rejected on the basis of further AC verifier
configuration, for example an AC verifier may be configured to configuration, for example an AC verifier may be configured to
reject ACs which contain or lack certain attribute types. reject ACs which contain or lack certain attribute types.
2. If the AC verifier provides an interface that allows 2. If the AC verifier provides an interface that allows
applications to query the contents of the AC, then the AC applications to query the contents of the AC, then the AC
verifier MAY filter the attributes from the AC on the basis of verifier MAY filter the attributes from the AC on the basis of
configured information, e.g. an AC verifier might be configured configured information, e.g. an AC verifier might be configured
not to return certain attributes to certain targets. not to return certain attributes to certain targets.
6. Revocation 6. Revocation
<<Input is solicited on the suitability of the 3-scheme approach.>>
In many environments, the validity period of an AC is less than the In many environments, the validity period of an AC is less than the
time required to issue and distribute revocation information. time required to issue and distribute revocation information.
Therefore, short-lived ACs typically do not require revocation Therefore, short-lived ACs typically do not require revocation
support. However, long-lived ACs and environments where ACs enable support. However, long-lived ACs and environments where ACs enable
high value transactions MAY require revocation support. high value transactions MAY require revocation support.
The basic approach taken is to allow use of the following AC The basic approach taken is to allow use of the following AC
revocation related schemes. revocation related schemes.
"Never revoke" scheme: ACs may be marked so that the relying party "Never revoke" scheme: ACs may be marked so that the relying party
understands that no revocation status information will be made understands that no revocation status information will be made
available. available. A noRevAvail extension as defined in section 4.3.6 above
MUST be present in the AC to indicate this.
"Pointer from above" scheme: The PKC (or AC see section 7.4) of an Where no noRevAvail is not present, then the AC issuer is implicitly
AC issuer may "point" to sources of revocation status information stating that revocation status checks are supported and some method
for all ACs issued by that AC issuer, (with the exception of those MUST be provided to allow AC verifiers to establish the revocation
marked using the never-revoke method above). status of the AC.
"Pointer in AC" scheme: ACs may be marked (like PKCs) to "point" to "Pointer in AC" scheme: ACs may be marked (like PKCs) to "point" to
sources of revocation status information (using an sources of revocation status information (using an
authorityInfoAccess or crlDistributionPoints extension in the AC authorityInfoAccess or crlDistributionPoints extension in the AC
itself). itself).
The never revoke scheme requires a new authorityInfoAccess For AC users, the "never revoke" scheme MUST be supported, the
accessMethod. The pointer from above scheme also requires a new "pointer in AC" scheme SHOULD be supported. If only the "never
authorityInfoAccess accessMethod. The pointer in AC scheme is as revoke" scheme is supported, then all ACs that do not contain a
specified in [RFC2459] and [RFC2560]. noRevAvail extension, MUST be rejected.
The never revoke scheme MUST be supported, the other schemes SHOULD
be supported.
6.1.1 "Never revoke" method
Where an AC issuer does not support revocation status checks for a
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.
Where no authority information access is present with this
accessMethod, then the AC issuer is implicitly stating that
revocation status checks are supported and one of the other methods
below MUST be provided to allow AC verifiers to establish the
revocation status of the AC.
6.1.2 "Pointer from above" method
In this case the AC issuer's PKC contains an authority information
access extension with an id-ad-acRevStatusLocation accessMethod as
described in section 4.7 above.
6.1.3 "Pointer in AC" method
AC revocation status MAY be checked using the methods described in For AC issuers, the "never revoke" scheme MUST be supported. If all
[RFC2459], but substituting the AC issuer wherever a CA is ACs that will ever be issued by that AC issuer, will contain a
mentioned. noRevAvail extension, then the "pointer in AC" scheme NEED NOT be
supported. If any AC can be issued that does not contain the
noRevAvail extension, then the "pointer in AC" scheme MUST be
supported.
In these cases, the AC contains either an authorityInfoAccess or All conformant ACs MUST contain exactly one of the noRevAvail,
crlDistributionPoints extensions as defined in [RFC2459] and authorityInformationAccess or crlDistributionPoints extensions. That
[RFC2560] respectively. is, the crlDistributionPoints, authorityInformationAccess and
noRevAvail extensions are mutually exclusive for a single AC and an
AC MUST NOT contain more than one of these extensions. This differs
from the case with PKCs. An AC verifier MAY use other (e.g.
configured) sources for AC revocation status information.
7. Optional Features 7. Optional Features
This section specifies features that MAY be implemented. Conformance This section specifies features that MAY be implemented. Conformance
to this specification does NOT require support for these features. to this specification does NOT require support for these features.
7.1 Attribute Encryption 7.1 Attribute Encryption
Where an AC will be carried in clear within an application 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 or where an AC contains some sensitive information (e.g. a legacy
skipping to change at page 24, line 4 skipping to change at page 25, line 39
name id-aca-encAttrs name id-aca-encAttrs
OID { id-aca 6} OID { id-aca 6}
Syntax ContentInfo Syntax ContentInfo
values Multiple Allowed values Multiple Allowed
If an AC contains attributes apparently encrypted for the AC If an AC contains attributes apparently encrypted for the AC
verifier then the decryption process MUST not fail - if decryption verifier then the decryption process MUST not fail - if decryption
fails then the AC MUST be rejected. fails then the AC MUST be rejected.
7.2 Proxying 7.2 Proxying
In some circumstances, a server needs to proxy an AC when it acts as In some circumstances, a server needs to proxy an AC when it acts as
a client (for another server) on behalf of the AC owner. Such a client (for another server) on behalf of the AC holder. Such
proxying needs to be under the AC issuer's control, so that not proxying may have to be under the AC issuer's control, so that not
every AC is proxiable and so that a given proxiable AC can be every AC is proxiable and so that a given proxiable AC can be
proxied in a targeted fashion. Support for chains of proxies (with proxied in a targeted fashion. Support for chains of proxies (with
more than one intermediate server) is also sometimes required. more than one intermediate server) is also sometimes required. Note
that this does not involve a chain of ACs.
In order to meet this requirement we define another extension: In order to meet this requirement we define another extension,
ProxyInfo, similar to the targeting extension. ProxyInfo, similar to the targeting extension.
When this extension is present the AC verifier must check that the When this extension is present the AC verifier must check that the
entity from which the AC was received was allowed to send it and entity from which the AC was received was allowed to send it and
that the AC is allowed to be used by this verifier. that the AC is allowed to be used by this verifier.
The proxying information consists of a set of proxy information, The proxying information consists of a set of proxy information,
each of which is a set of targeting information. If the verifier and 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 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). AC can be accepted (the exact rule is given below).
The effect is that the AC owner can send the AC to any valid target The effect is that the AC holder can send the AC to any valid target
which can then only proxy to targets which are in one of the same which can then only proxy to targets which are in one of the same
"proxy sets" as itself. "proxy sets" as itself.
The following data structure is used to represent the The following data structure is used to represent the
targeting/proxying information. targeting/proxying information.
ProxyInfo ::= SEQUENCE OF Targets ProxyInfo ::= SEQUENCE OF Targets
A proxy check succeeds if As in the case of targeting, the targetCertificate and targetDigest
fields MUST NOT be used.
( A proxy check succeeds if either one of the conditions below is met:
the identity of the sender as established by
the underlying authentication service matches 1.
the owner field of the AC The identity of the sender as established by the underlying
and authentication service matches the holder field of the AC, and,
( the current server "matches" any one of the proxy sets (where
the current server "matches" any one of "matches" is as defined for the targeting check in section 4.3.2
the proxy sets (where "matches" is as for above).
the direct check above)
) 2.
) The identity of the sender as established by the underlying
or authentication service "matches" one of the proxy sets (call it
( set "A"), and, the current server is one of the targetName fields
the identity of the sender as established by in the set "A", or, the current server is a member of one of the
the underlying authentication service "matches" targetGroup fields in set "A".
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 will be on Where an AC is proxied more than once a number of targets will be on
the path from the original client, which is normally, but not the path from the original client, which is normally, but not
always, the AC owner. In such cases prevention of AC "stealing" always, the AC holder. In such cases prevention of AC "stealing"
requires that the AC verifier MUST check that all targets on the 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 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 the AC using protocol to ensure that a trustworthy list of targets
on the path is available to the AC verifier. on the path is available to the AC verifier.
name id-pe-ac-proxying name id-pe-ac-proxying
OID { id-pe 7 } OID { id-pe 7 }
syntax ProxyInfo syntax ProxyInfo
criticality must be TRUE criticality MUST be TRUE
7.3 Use of ObjectDigestInfo 7.3 Use of ObjectDigestInfo
<<In order to keep it simple, I've only allowed for a hash over a
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.>>
In some environments it may be required that the AC is not linked In some environments it may be required that the AC is not linked
either to an identity (via entityName) or to a PKC (via either to an identity (via entityName) or to a PKC (via
baseCertificateID). The objectDigestInfo choice in the owner field baseCertificateID). The objectDigestInfo choice in the holder field
allows support for this requirement. allows support for this requirement.
If the owner is identified via the objectDigestInfo field then the If the holder is identified via the objectDigestInfo field then the
AC version field MUST contain v2 (i.e. the integer 1). AC version field MUST contain v2 (i.e. the integer 1).
The basic idea is to link the AC to an object by placing a hash of The basic idea is to link the AC to an object by placing a hash of
that object into the owner field of the AC. For example, this allows that object into the holder field of the AC. For example, this
production of ACs that are linked to public keys rather than names allows production of ACs that are linked to public keys rather than
or certificates, or production of ACs which contain privileges names, or production of ACs which contain privileges associated with
associated with an executable object (e.g. a Java class). an executable object (e.g. a Java class).
However, this profile only specifies how to use a hash over a public
key or PKC, that is, conformant ACs MUST NOT use the
otherObjectTypes value for the digestedObjectType.
In order to link an AC to a public key the hash must be calculated In order to link an AC to a public key the hash must be calculated
over the representation of that public key which would be present in over the representation of that public key which would be present in
a PKC, specifically, the input for the hash algorithm MUST be the a PKC, specifically, the input for the hash algorithm MUST be the
DER encoding of a SubjectPublicKeyInfo representation of the key. DER encoding of a SubjectPublicKeyInfo representation of the key.
Note: This includes the AlgorithmIdentifier as well as the BIT Note: This includes the AlgorithmIdentifier as well as the BIT
STRING. The rules given in [RFC2459] and [ECDSA] for encoding keys STRING. The rules given in [PKIXPROF] and [ECDSA] for encoding keys
MUST be followed. MUST be followed. In this case the digestedObjectType MUST be
publicKey and the otherObjectTypeID field MUST NOT be present.
Note that if the public key value used as input to the hash function Note that if the public key value used as input to the hash function
has been extracted from a PKC, then it is possible that the has been extracted from a PKC, then it is possible that the
SubjectPublicKeyInfo from that PKC is NOT the value which should be SubjectPublicKeyInfo from that PKC is NOT the value which should be
hashed. This can occur if, e.g. DSA Dss-parms are inherited as 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 described in section 7.3.3 of [PKIXPROF]. The correct input for
hashing in this context will include the value of the parameters hashing in this context will include the value of the parameters
inherited from the CA's PKC, and thus may differ from the inherited from the CA's PKC, and thus may differ from the
SubjectPublicKeyInfo present in the PKC. SubjectPublicKeyInfo present in the PKC.
Implementations which support this feature MUST be able to handle Implementations which support this feature MUST be able to handle
the representations of keys for the algorithms specified in section the representations of keys for the algorithms specified in section
7.3 of [RFC2459] and those specified in [ECDSA]. 7.3 of [PKIXPROF] and those specified in [ECDSA]. In this case the
digestedObjectType MUST be publicKey and the otherObjectTypeID field
MUST NOT be present.
7.4 AC Chaining In order to link an AC to a PKC via a digest, the digest MUST be
calculated over the DER encoding of the entire PKC (i.e. including
the signature bits). In this case the digestedObjectType MUST be
publicKeyCert and the otherObjectTypeID field MUST NOT be present.
Section 5 above specifies a way of embedding AAControls into PKCs in 7.4 AA Controls
order to control the attribute types for which an AA will be trusted
by an AC verifier.
There are two drawbacks to this mechanism: During AC validation a relying party has to answer the question: "is
this AC issuer trusted to issue ACs containing this attribute?" The
AAControls PKC extension, intended to be used in CA and AC Issuer
PKCs, MAY be used to help answer the question.
- PKC issuers have to know about authorization attribute types Note that this extension is quite likely to change in future based
- It is likely to require more frequent changes to AA's PKCs on experience with the use of ACs in the Internet.
These problems can be avoided by placing the equivalent information id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
into an AC for which the owner is an AA. However, this mechanism
requires chaining of ACs and thus imposes possibly significant costs
both in terms of implementation and deployment complexity.
In order to use this feature, an AC verifier presented with an AC, AAControls ::= SEQUENCE {
(belonging say to an end entity, call this EE-AC), must retrieve an pathLenConstraint INTEGER (0..MAX) OPTIONAL,
AC which is owned by the issuer of EE-AC (call this AA-AC). The AC permittedAttrs [0] AttrSpec OPTIONAL,
verifier next verifies AA-AC, extracts the AAControls information excludedAttrs [1] AttrSpec OPTIONAL,
from AA-AC and uses this to decide which attributes from EE-AC permitUnSpecified BOOLEAN DEFAULT TRUE
should be trusted. }
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
Of course, the issuer of AA-AC may or may not be directly trusted by The aaControls extension is used as follows:
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 The pathLenConstraint, if present, is interpreted as in [PKIXPROF],
aaControls placed within PKCs. but now restricts the allowed "distance" between the AA CA, (a CA
directly trusted to include AAControls in its PKCs), and the AC
issuer.
When verifying an AC, the verifier needs to determine when a chain The permittedAttrs field specifies a set of attribute types that any
of ACs is needed. 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).
When AAControls are present in an AC, they are placed as an The excludedAttrs field specifies a set of attribute types that no
extension of the AC, using the same extension defined in section AC issuer is allowed to include in ACs. If this field is not
4.6.1 above. present, it means that no attribute types are explicitly disallowed
(though the permitUnSpecified field may close things down).
When chaining ACs the following additional verification rules apply The permitUnSpecified field specifies how to handle attribute types
which are not present in either the 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.
1. EE-AC.issuer and AA-AC.owner MUST contain the same value Where aaControls are used then the following additional checks on an
2. At the time of evaluation all ACs in the chain MUST be valid AA's PKC chain MUST all succeed for the AC to be valid:
<<probably needs more about the AC chain validation algorithm>> 1. Some CA on the AC's certificate path MUST be directly trusted
to issue PKCs which precede the AC issuer in the certification
path, call this CA the "AA CA".
2. All PKC's on the path from the AA CA down to and 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 id-aca-encAttrs
type MUST also be checked).
name id-pe-aaControls
OID { id-pe 6 }
syntax AAControls
criticality MAY be TRUE
8. Security Considerations 8. Security Considerations
Implementers MUST ensure that following validation of an AC, only Implementers MUST ensure that following validation of an AC, only
attributes that the issuer is trusted to issue are used in attributes that the issuer is trusted to issue are used in
authorization decisions. Other attributes, which MAY be present MUST authorization decisions. Other attributes, which MAY be present MUST
be ignored. be ignored. Given that the AA controls PKC extension is optional to
implement, this means that AC verifiers MUST be provided with the
required information by other means - e.g. by configuration. This
becomes very important if an AC verified trusts more than one AC
issuer.
There is often a requirement to map between the authentication There is often a requirement to map between the authentication
supplied by a particular protocol (e.g. TLS, S/MIME) and the AC supplied by a particular protocol (e.g. TLS, S/MIME) and the AC
owner's identity. If the authentication uses PKCs then this mapping holder's identity. If the authentication uses PKCs then this mapping
is straightforward. However, it is envisaged that ACs will also be is straightforward. However, it is envisaged that ACs will also be
used in environments where the owner may be authenticated using used in environments where the holder may be authenticated using
other means. Implementers SHOULD be very careful in mapping the other means. Implementers SHOULD be very careful in mapping the
authenticated identity to the AC owner. authenticated identity to the AC holder.
9. References 9. References
[CMC] Myers, M., et al. "Certificate Management Messages over [CMC] Myers, M., et al. "Certificate Management Messages over
CMS", CMS", draft-ietf-pkix-cmc-05.txt, July 1999.
draft-ietf-pkix-cmc-03.txt, March 1999.
[CMP] Adams, C., Farrell, S., "Internet X.509 Public Key [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key
Infrastructure - Certificate Management Protocols", Infrastructure - Certificate Management Protocols",
RFC2510. RFC2510.
[CMS] Housley, R., "Cryptographic Message Syntax", [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.
draft-ietf-smime-cms-12.txt, March 1999.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
draft-ietf-smime-ess-12.txt, March 1999. RFC2634.
[ECDSA] D. Johnson, W. Polk, "Internet X.509 Public Key [ECDSA] D. Johnson, W. Polk, "Internet X.509 Public Key
Infrastructure Representation of Elliptic Curve Digital Infrastructure Representation of Elliptic Curve Digital
Signature Algorithm (ECDSA) Keys and Signatures in Signature Algorithm (ECDSA) Keys and Signatures in
Internet X.509 Public Key Infrastructure Certificates" Internet X.509 Public Key Infrastructure Certificates"
draft-ietf-pkix-ipki-ecdsa-01.txt, June 1999. draft-ietf-pkix-ipki-ecdsa-02.txt, October 1999.
[RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol
(v3)", RFC 2251.
[KRB] Kohl, J., Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510.
[PKINIT] Tung, B., et al., "Public Key Cryptography for Initial
Authentication in Kerberos", draft-ietf-cat-kerberos-pk-
init-10.txt
[PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
Public Key Infrastructure - X.509 Certificate and CRL Public Key Infrastructure - X.509 Certificate and CRL
profile", RFC2459. profile",RFC 2459.
[RFC2560] Myers, M., et al., " X.509 Internet Public Key [OCSP] Myers, M., et al., " X.509 Internet Public Key
Infrastructure - Online Certificate Status Protocol - Infrastructure - Online Certificate Status Protocol -
OCSP", RFC2560. OCSP", RFC 2560.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996. 3", RFC 2026, BCP 9, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119.
[X.501] ITU-T Recommendation X.501 : Information Technology - [X.501] ITU-T Recommendation X.501 : Information Technology -
Open Systems Interconnection - The Directory: Models, Open Systems Interconnection - The Directory: Models,
1993. 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 [X.208-88] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT Recommendation X.209: Specification of Basic [X.209-88] CCITT Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988. 1988.
[X.501-88] CCITT Recommendation X.501: The Directory - Models. [X.501-88] CCITT Recommendation X.501: The Directory - Models.
1988. 1988.
[X.509-88] CCITT Recommendation X.509: The Directory - [X.509-88] CCITT Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
[X.509-97] ITU-T Recommendation X.509: The Directory - [X.509-97] ITU-T Recommendation X.509: The Directory -
Authentication Framework. 1997. Authentication Framework. 1997.
[FPDAM] ISO 9594-8 Information Technology û Open systems [X.509-DAM] ISO 9594-8 Information Technology - Open systems
Interconnection - The Directory: Authentication Interconnection - The Directory: Authentication
Framework - Proposed Draft Amendment 1: Certificate Framework - Draft Amendment 1: Certificate Extensions,
Extensions, April 1999. October 1999.
Author's Addresses Author's Addresses
Stephen Farrell, Stephen Farrell,
Baltimore Technologies Baltimore Technologies
61/62 Fitzwilliam Lane, 61/62 Fitzwilliam Lane,
Dublin 2, Dublin 2,
IRELAND IRELAND
tel: +353-1-647-3000 tel: +353-1-647-3000
skipping to change at page 29, line 14 skipping to change at page 32, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A: "Compilable" ASN.1 Module Appendix B: Object Identifiers
This (normative) appendix lists the new object identifiers which are
defined in this specification. Some of these are required only for
support of optional features and are not required for conformance to
this profile.
This specification mandates support for OIDs which have arc elements
with values that are less than 2^28, i.e. they MUST be between 0 and
268,435,455 inclusive. This allows each arc element to be
represented within a single 32 bit word. Implementations MUST also
support OIDs where the length of the dotted decimal (see [LDAP],
section 4.1.2) string representation can be up to 100 bytes
(inclusive). Implementations MUST be able to handle OIDs with up to
20 elements (inclusive). AA's SHOULD NOT issue ACs which contain
OIDs that breach these requirements.
The following OIDs are imported from [PKIXPROF]:
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 new ASN.1 module OID is defined:
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
The following AC extension OIDs are defined:
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 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-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
Appendix B: "Compilable" ASN.1 Module
PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert(12)} id-mod-attribute-cert(12)}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
skipping to change at page 29, line 46 skipping to change at page 33, line 37
GeneralName, GeneralNames GeneralName, GeneralNames
FROM PKIX1Implicit88 {iso(1) identified-organization(3) FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 } id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 } id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 }
id-pe-ac-targeting-all OBJECT IDENTIFIER ::=
{ id-pe-ac-targeting 1 }
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-role OBJECT IDENTIFIER ::= { id-aca 5 } -- { id-aca 5 } is reserved
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 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 { AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo, acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING signatureValue BIT STRING
} }
AttributeCertificateInfo ::= SEQUENCE { AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion DEFAULT v1, version AttCertVersion DEFAULT v1,
owner Owner, holder Holder,
issuer AttCertIssuer, issuer AttCertIssuer,
signature AlgorithmIdentifier, signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber, serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod, attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute, attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL, issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL extensions Extensions OPTIONAL
} }
AttCertVersion ::= INTEGER {v1(0), v2(1) } AttCertVersion ::= INTEGER {v1(0), v2(1) }
Owner ::= SEQUENCE { Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL, baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of -- the issuer and serial number of
-- the owner's Public Key Certificate -- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL, entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role -- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- if present, version must be v2 -- if present, version must be v2
} }
ObjectDigestInfo ::= SEQUENCE { ObjectDigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier, digestedObjectType ENUMERATED {
objectDigest OCTET STRING publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
} }
AttCertIssuer ::= SEQUENCE { AttCertIssuer ::= CHOICE {
issuerName GeneralNames OPTIONAL, oldForm GeneralNames,
baseCertificateId [0] IssuerSerial OPTIONAL newForm [0] SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateId [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- at least one of issuerName, baseCertificateId or --
-- objectDigestInfo must be present --
-- if newForm is used, version must be v2--
} }
IssuerSerial ::= SEQUENCE { IssuerSerial ::= SEQUENCE {
issuer GeneralNames, issuer GeneralNames,
serial CertificateSerialNumber, serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL issuerUID UniqueIdentifier OPTIONAL
} }
AttCertValidityPeriod ::= SEQUENCE { AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime, notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime notAfterTime GeneralizedTime
} }
Targets ::= SEQUENCE OF Target Targets ::= SEQUENCE OF Target
Target ::= CHOICE { Target ::= CHOICE {
targetName [0] GeneralName, targetName [0] GeneralName,
targetGroup [1] GeneralName targetGroup [1] GeneralName,
targetCertificate [2] IssuerSerial,
targetDigest [3] ObjectDigestInfo
} }
IetfAttrSyntax ::= SEQUENCE OF SEQUENCE { IetfAttrSyntax ::= SEQUENCE {
policyAuthority[0] GeneralNames OPTIONAL, policyAuthority[0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE { values SEQUENCE OF CHOICE {
octets OCTET STRING, octets OCTET STRING,
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
string UTF8String string UTF8String
} }
} }
SvceAuthInfo ::= SEQUENCE { SvceAuthInfo ::= SEQUENCE {
service GeneralName, service GeneralName,
skipping to change at page 32, line 4 skipping to change at page 35, line 56
type [0] IMPLICIT OBJECT IDENTIFIER, type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type value [1] ANY DEFINED BY type
} }
AAControls ::= SEQUENCE { AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL, pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL, permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL, excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE permitUnSpecified BOOLEAN DEFAULT TRUE
} }
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
ACClearAttrs ::= SEQUENCE { ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName, acIssuer GeneralName,
acSerial INTEGER, acSerial INTEGER,
attrs SEQUENCE OF Attribute attrs SEQUENCE OF Attribute
} }
ProxyInfo ::= SEQUENCE OF Targets ProxyInfo ::= SEQUENCE OF Targets
END END
Appendix B: Samples Appendix C: Changes History
<<TBS>>
Appendix C: Changes this version / Open Issues <<This Appendix to be deleted after last call>>
This appendix lists major changes since the previous revision and This appendix lists major changes since the previous revision.
open issues to be resolved (in order of occurrence in the body of
the document).
Major changes since last revision: Major changes since last revision:
1. Re-structured conformance to profile + options as per Oslo Changes from -01 to -02
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. Re-Synchronized with X.509 DAM
2. Deleted AC chains concept
3. Moved AAControls to "optional features" section
4. Samples will be a separate draft
5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459
mechanisms only
6. Deleted the special wildcard target "ALL"
1. Should an AC without any attributes be allowed? Changes from -00 to -01
2. Should OS-specific group attribute types be defined?
3. Is the expansion of the SecurityCategory MACRO correct? 1. Re-structured conformance to profile + options as per Oslo
4. Are three revocation schemes needed? Correct? consensus
5. Should more types of objectDigestInfo be allowed? 2. Moved acquisition protocol (LAAP)_to separate I-D
6. AC chain section needs more description of chain validation. 3. Removed restrictions entirely
7. Samples - should they be a separate draft? 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
 End of changes. 197 change blocks. 
633 lines changed or deleted 672 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/