< draft-ietf-pkix-ac509prof-02.txt   draft-ietf-pkix-ac509prof-03.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
March 2000 May 2000
An Internet Attribute Certificate An Internet Attribute Certificate
Profile for Authorization Profile for Authorization
<draft-ietf-pkix-ac509prof-02.txt> <draft-ietf-pkix-ac509prof-03.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 48 skipping to change at page 2, line 7
broad spectrum of interoperability goals and a broader spectrum of broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security support for Internet electronic mail, IPSec, and WWW security
applications. 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...............................................2
1. Introduction.................................................3 1. Introduction.................................................3
1.1 Delegation and AC chains...............................4 1.1 Delegation and AC chains...............................4
1.2 Attribute Certificate Distribution ("push" vs "pull")..4 1.2 Attribute Certificate Distribution ("push" vs "pull")..4
1.3 Document Structure.....................................6 1.3 Document Structure.....................................5
2. Terminology..................................................7 2. Terminology..................................................6
3. Requirements.................................................8 3. Requirements.................................................7
4. The AC Profile...............................................9 4. Attribute Certificate Profile................................8
4.1 X.509 Attribute Certificate Definition.................9 4.1 X.509 Attribute Certificate Definition.................8
4.2 Profile of Standard Fields............................11 4.2 Profile of Standard Fields............................10
4.2.1 Version.........................................11 4.2.1 Version.........................................10
4.2.2 Holder..........................................11 4.2.2 Holder..........................................10
4.2.3 Issuer..........................................12 4.2.3 Issuer..........................................11
4.2.4 Signature.......................................12 4.2.4 Signature.......................................12
4.2.5 Serial Number...................................13 4.2.5 Serial Number...................................12
4.2.6 Validity Period.................................13 4.2.6 Validity Period.................................12
4.2.7 Attributes......................................13 4.2.7 Attributes......................................13
4.2.8 Issuer Unique Identifier........................14 4.2.8 Issuer Unique Identifier........................13
4.2.9 Extensions......................................14 4.2.9 Extensions......................................13
4.3 Extensions............................................14 4.3 Extensions............................................14
4.3.1 Audit Identity..................................14 4.3.1 Audit Identity..................................14
4.3.2 AC Targeting....................................15 4.3.2 AC Targeting....................................15
4.3.3 Authority Key Identifier........................16 4.3.3 Authority Key Identifier........................16
4.3.4 Authority Information Access....................17 4.3.4 Authority Information Access....................16
4.3.5 CRL Distribution Points.........................17 4.3.5 CRL Distribution Points.........................16
4.3.6 No Revocation Available.........................17 4.3.6 No Revocation Available.........................17
4.4 Attribute Types.......................................18 4.4 Attribute Types.......................................17
4.4.1 Service Authentication Information..............18 4.4.1 Service Authentication Information..............18
4.4.2 Access Identity.................................19 4.4.2 Access Identity.................................18
4.4.3 Charging Identity...............................19 4.4.3 Charging Identity...............................18
4.4.4 Group...........................................19 4.4.4 Group...........................................19
4.4.5 Role............................................19 4.4.5 Role............................................19
4.4.6 Clearance.......................................20 4.4.6 Clearance.......................................19
4.5 Profile of AC Issuer's PKC............................21 4.5 Profile of AC issuer's PKC............................21
5. Attribute Certificate Validation............................22 5. Attribute Certificate Validation............................22
6. Revocation..................................................23 6. Revocation..................................................23
7. Optional Features...........................................24 7. Optional Features...........................................24
7.1 Attribute Encryption..................................24 7.1 Attribute Encryption..................................24
7.2 Proxying..............................................25 7.2 Proxying..............................................25
7.3 Use of ObjectDigestInfo...............................26 7.3 Use of ObjectDigestInfo...............................26
7.4 AA Controls...........................................27 7.4 AA Controls...........................................27
8. Security Considerations.....................................29 8. Security Considerations.....................................29
9. References..................................................30 9. References..................................................31
Author's Addresses..............................................31 Author's Addresses.............................................32
Full Copyright Statement........................................31 Full Copyright Statement.......................................32
Appendix B: Object Identifiers..................................32 Appendix A: Object Identifiers.................................33
Appendix B: "Compilable" ASN.1 Module...........................33 Appendix B: ASN.1 Module.......................................34
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-97], [X.509-DAM], X.509 public key certificates (PKCs) [X.509-97, X.509-DAM, PKIXPROF]
[PKIXPROF] bind an identity and a public key. The identity may be bind an identity and a public key. The identity may be used to
used to support identity-based access control decisions after the support identity-based access control decisions after the client
client proves that it has access to the private key that corresponds proves that it has access to the private key that corresponds to the
to the public key contained in the PKC. The public key is used to public key contained in the PKC. The public key is used to validate
validate digital signatures or cryptographic key management digital signatures or cryptographic key management operations.
operations. However, not all access control decisions are identity- However, not all access control decisions are identity-based. Rule-
based. Rule-based, role-based, and rank-based access control based, role-based, and rank-based access control decisions require
decisions require additional information. For example, information additional information. For example, information about a client's
about a client's ability to pay for a resource access may be more ability to pay for a resource access may be more important than the
important than the client's identity. Authorization information to client's identity. Authorization information to support such access
support such access control decisions may be placed in a PKC control decisions may be placed in a PKC extension or placed in a
extension or placed in a separate attribute certificate (AC). 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 often
not have the same lifetime as the binding of the identity and the does not have the same lifetime as the binding of the identity and
public key. When authorization information is placed in a PKC the 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 AC provides
certificate (AC) provides this protection, and it is simply a this protection; it is simply a digitally signed (or certified) set
digitally signed (or certified) set of attributes. 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 the AC contains no public key. An AC may contain attributes
specify group membership, role, security clearance, and other access that specify group membership, role, security clearance, or other
control information associated with the AC holder. The syntax for access control information associated with the AC holder. The syntax
the AC is defined in Recommendation X.509 (making the term "X.509 for the AC is defined in Recommendation X.509, making the term
certificate" ambiguous). This document specifies a profile of the "X.509 certificate" ambiguous. This document specifies a profile of
X.509 AC suitable for use with authorization information within the 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
holder 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 reference 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 Some people constantly confuse PKCs and ACs. An analogy may make the
ACs, an analogy may help. A PKC can be considered to be like a distinction clear. A PKC can be considered to be like a passport: it
passport: it identifies the holder, tends to last for a long time identifies the holder, tends to last for a long time, and should not
and should not be trivial to obtain. An AC is more like an entry be trivial to obtain. An AC is more like an entry visa: it is
visa: it is typically issued by a different authority and does not typically issued by a different authority and does not last for as
last for as long a time. As acquiring an entry visa typically long a time. As acquiring an entry visa typically requires
requires presenting a passport, getting a visa can be a simpler presenting a passport, getting a visa can be a simpler process.
process.
1.1 Delegation and AC chains 1.1 Delegation and AC chains
The X.509 standard defines delegation as "Conveyance of privilege The X.509 standard [X.509-DAM] defines authorization as the
from one entity that holds such privilege, to another entity". It "conveyance of privilege from one entity that holds such privilege,
further defines a delegation path as "An ordered sequence of to another entity". An AC is one authorization mechanism.
certificates which, together with authentication of a privilege
asserter's identity can be processed to verify the authenticity of a An ordered sequence of ACs could be used to verify the authenticity
privilege asserter's privilege". It then goes on to define various of a privilege asserter's privilege. In this way, chains or paths of
mechanisms for use in delegation cases involving "chains" of ACs. ACs could be employed to delegate authorization.
As the administration and processing associated with such AC chains As the administration and processing associated with such AC chains
is potentially much more complex than use of a single AC, and as the is more complex than use of one AC issued by a single authority, and
use of ACs in the Internet is today in its infancy, this as the use of ACs in the Internet today is quite limited, this
specification does not address such AC chains. Other (future) specification does NOT RECOMMEND the use of AC chains. Other
specifications may address the use of AC chains. (future) specifications may address the use of AC chains.
This means that conformant implementations are only REQUIRED to be This means that conformant implementations are only REQUIRED to be
able to "handle" a single AC at a time. Note however, that 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 validation of that AC MAY require validation of a chain of PKCs, as
specified in [PKIXPROF]. specified in [PKIXPROF].
1.2 Attribute Certificate Distribution ("push" vs "pull") 1.2 Attribute Certificate Distribution ("push" vs "pull")
As discussed above, ACs provide a mechanism to securely provide As discussed above, ACs provide a mechanism to securely provide
authorization information to access control decision functions. authorization information to access control decision functions.
However, there are a number of possible communication paths that an However, there are a number of possible communication paths for ACs.
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
the client or client-server protocol. It is also more suitable for the client or to the client-server protocol. It is also more
some inter-domain cases where the client's rights should be assigned suitable for some inter-domain cases where the client's rights
within the server's domain, rather than within the client's "home" should be assigned within the server's domain, rather than within
domain. the client's domain.
There are a number of possible exchanges that can occur and three There are a number of possible exchanges involving three entities:
entities involved (client, server and AC issuer). In addition the the client, the server, and the AC issuer. In addition, a directory
use of a directory service or other repository for AC retrieval MAY service or other repository for AC retrieval MAY be supported.
be supported.
Figure 1 shows an abstract view of the exchanges that may involve Figure 1 shows an abstract view of the exchanges that may involve
ACs. This profile does not specify protocol for these exchanges. ACs. This profile does not specify protocol for these exchanges.
+--------------+ +--------------+
| | Server Acquisition | | Server Acquisition
| AC Issuer +----------------------------+ | AC issuer +----------------------------+
| | | | | |
+--+-----------+ | +--+-----------+ |
| | | |
| Client | | Client |
| Acquisition | | Acquisition |
| | | |
+--+-----------+ +--+------------+ +--+-----------+ +--+------------+
| | AC "push" | | | | AC "push" | |
| Client +-------------------------+ Server | | Client +-------------------------+ Server |
| | (part of app. protocol) | | | | (part of app. protocol) | |
skipping to change at page 6, line 7 skipping to change at page 5, line 47
| Lookup +--------------+ | Lookup | Lookup +--------------+ | Lookup
| | | | | | | |
+---------------+ Repository +---------+ +---------------+ Repository +---------+
| | | |
+--------------+ +--------------+
Figure 1: AC Exchanges Figure 1: AC Exchanges
1.3 Document Structure 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
Section 3 specifies the requirements that this profile is to meet requirements that this profile is to meet; Section 4 contains the
Section 4 contains the profile of the X.509 AC profile of the X.509 AC; Section 5 specifies rules for AC
Section 5 specifies rules for AC validation 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; and
Appendices contain the list of OIDs required to support this Appendices contain the list of OIDs required to support this
specification and a "compilable" ASN.1 module. specification and a 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. For example, ACs may be used
context, the mail user agent would, by turns, be both "client" and in the S/MIME v3 context, where the mail user agent would be both a
"server" in the sense the terms are used here. "client" and a "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 holder the entity indicated (perhaps indirectly) in the AC holder the entity indicated (perhaps indirectly) in the
holder 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
certificate". certificate".
Server the entity which requires that the authorization Server the entity which requires that the authorization
checks are made checks are made
3. Requirements 3. Requirements
This Attribute Certificate profile meets the following requirements. This AC profile meets the following requirements.
Time/Validity requirements: Time/Validity requirements:
1. Support for short-lived or long-lived ACs is required. Typical 1. Support for short-lived as well as long-lived ACs is required.
validity periods might be measured in hours, as opposed to Typical validity periods might be measured in hours, as opposed
months for X.509 public key certificates. Short validity to months for PKCs. Short validity periods allow ACs to be
periods mean that ACs can be useful without a revocation useful without a revocation mechanism.
mechanism.
Attribute Types: Attribute Types:
2. Issuers of ACs should be able to define their own attribute 2. Issuers of ACs should be able to define their own attribute
types for use within closed domains. types for use within closed domains.
3. Some standard attribute types should be defined which can be 3. Some standard attribute types should be defined which can be
contained within ACs, for example "access identity", "group", contained within ACs. examples include "access identity",
"role", "clearance", "audit identity", "charging id" etc. "group", "role", "clearance", "audit identity", and "charging
4. Standard attribute types should be defined so that it is id".
possible for an AC verifier to distinguish between e.g. the 4. Standard attribute types should be defined in a manner that
permits an AC verifier to distinguish between uses of the same
attribute in different domains. For example, the
"Administrators group" as defined by Baltimore and the "Administrators group" as defined by Baltimore and the
"Administrators group" as defined by SPYRUS. "Administrators group" as defined by SPYRUS should be easily
distinguished.
Targeting of ACs: Targeting of ACs:
5. It should be possible to "target" an AC. This means that a 5. It should be possible to "target" an AC at one, or a small
given AC may be "targeted" at one, or a small number of, number of, servers. This means that a trustworthy non-target
servers in the sense that a trustworthy non- target will reject server will reject the AC for authorization decisions.
the AC for authorization decisions.
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. Attribute Certificate Profile
Attribute certificates may be used in a wide range of applications ACs may be used in a wide range of applications and environments
and environments covering a broad spectrum of interoperability goals covering a broad spectrum of interoperability goals and a broader
and a broader spectrum of operational and assurance requirements. spectrum of operational and assurance requirements. The goal of
The goal of this document is to establish a common baseline for this document is to establish a common baseline for generic
generic applications requiring broad interoperability and limited applications requiring broad interoperability and limited special
special purpose requirements. In particular, the emphasis will be purpose requirements. In particular, the emphasis will be on
on supporting the use of attribute certificates for informal supporting the use of attribute certificates for informal Internet
Internet electronic mail, IPSec, and WWW applications. electronic mail, IPSec, and WWW applications.
This section presents a profile for attribute certificates that will This section presents a profile for ACs that will foster
foster interoperability. This section also defines some private interoperability. This section also defines some private extensions
extensions for the Internet community. for the Internet community.
While the ISO/IEC/ITU documents use the 1993 (or later) version of 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 ASN.1; this document uses the 1988 ASN.1 syntax, as has been done
1988 ASN.1 syntax, the encoded certificate and standard extensions for PKCs [PKIXPROF]. However, the encoded certificate and standard
are equivalent. extensions are equivalent.
Where maximum lengths for fields are specified, these lengths refer Where maximum lengths for fields are specified, these lengths refer
to the DER encoding and do not include the ASN.1 tag or length to the DER encoding and do not include the ASN.1 tag or length
fields. 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 AC given below. All types that
below. Types that are not defined can be found in [PKIXPROF]. are not defined in this document 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,
holder Holder, 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 { Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL, baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of -- the issuer and serial number of
-- the holder'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 { digestedObjectType ENUMERATED {
publicKey (0), publicKey (0),
publicKeyCert (1), publicKeyCert (1),
otherObjectTypes (2) }, otherObjectTypes (2) },
-- otherObjectTypes MUST NOT -- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile -- be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier, digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING objectDigest BIT STRING
} }
AttCertIssuer ::= CHOICE { AttCertIssuer ::= CHOICE {
oldForm GeneralNames, v1Form GeneralNames, -- v1 or v2
newForm [0] SEQUENCE { v2Form [0] V2Form -- v2 only
issuerName GeneralNames OPTIONAL, }
baseCertificateId [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL V2Form ::= SEQUENCE {
--at least one of issuerName, baseCertificateId or -- issuerName GeneralNames OPTIONAL,
-- objectDigestInfo must be present -- baseCertificateID [0] IssuerSerial OPTIONAL,
-- if newForm is used, version must be v2-- objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- at least one of issuerName, baseCertificateID
-- or objectDigestInfo MUST be present
} }
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
} }
Although the Attribute syntax is defined in [PKIXPROF], we repeat Although the Attribute syntax is defined in [PKIXPROF], we repeat
the definition here for convenience. the definition here for convenience.
Attribute ::= SEQUENCE { Attribute ::= SEQUENCE {
type AttributeType, type AttributeType,
values SET OF AttributeValue values SET OF AttributeValue
-- at least one value is required -- -- at least one value is required
} }
AttributeType ::= OBJECT IDENTIFIER AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY AttributeValue ::= ANY
Implementers should note that the DER encoding (DER is defined in Implementers should note that the DER encoding (DER is defined in
[X.208-88]) of the SET OF values requires ordering of the encodings [X.208-88]) of the SET OF values requires ordering of the encodings
of the values. Though this issue arises with respect to of the values. Though this issue arises with respect to
distinguished names, and has to be handled by [PKIXPROF] distinguished names, and has to be handled by [PKIXPROF]
implementations, its is much more significant in this context, since implementations, its is much more significant in this context, since
the inclusion of multiple values is much more common in ACs. the inclusion of multiple values is much more common in ACs.
4.2 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 (except as
x400Address, ediPartyName and registeredID options MUST NOT be used noted below), x400Address, ediPartyName and registeredID options
unless otherwise specified (e.g. as in the description of targeting MUST NOT be used. The use of Kerberos [KRB] format names, encoded
extension). into the otherName, SHOULD however, be supported using the
krb5PrincipalName OID and the KerberosName syntax as defined in
The use of Kerberos [KRB] format names, encoded into the otherName, [PKINIT].
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 Conforming implementations MUST be able to support the dNSName,
attribute), conforming implementations MUST be able to support the directoryName, uniformResourceIdentifier, and iPAddress fields in
dNSName, directoryName, uniformResourceIdentifier and iPAddress all cases where GeneralName is used. This is compatible with the
fields in all cases where GeneralName is used. The MUST support GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7).
requirements for each of these fields are as specified in
[PKIXPROF], (mainly in section 4.2.1.7).
4.2.1 Version 4.2.1 Version
This MUST be the default value of v1, i.e. not present in the DER The version field MUST be the default value of v1. That is, the
encoding, except where the holder is identified using the optional version field is not present in the DER encoding, except when the
objectDigestInfo field, as specified in section 7.3. holder is identified using the optional objectDigestInfo field, as
specified in section 7.3.
4.2.2 Holder 4.2.2 Holder
For any environment where the AC is passed in an authenticated For any environment where the AC is passed in an authenticated
message or session, and where the authentication is based on the use message or session and where the authentication is based on the use
of an X.509 public key certificate (PKC), the holder field SHOULD of an X.509 PKC, the holder field SHOULD use the baseCertificateID.
use the baseCertificateID. Note that this profile uses the field name "baseCertificateID"
everywhere, whereas [X.509-DAM] sometimes uses this, and sometimes
uses the field name "baseCertificateId" (i.e. ending with a
lowercase "d"). The use of different names causes programming
difficulties so developers may need to be aware of which ASN.1
module has been used (i.e. the [X.509-DAM] one, or the one from
Appendix B).
With the baseCertificateID option, the holder's PKC serialNumber and With the baseCertificateID option, the holder's PKC serialNumber and
issuer MUST be identical to the AC holder field. The PKC issuer MUST issuer MUST be identical to the AC holder field. The PKC issuer MUST
have a non empty distinguished name which is to be present as the have a non-empty distinguished name which is to be present as the
single value of the holder.baseCertificateID.issuer construct in the single value of the holder.baseCertificateID.issuer construct in the
directoryName field. The holder.baseCertificateID.issuerUID field directoryName field. The holder.baseCertificateID.issuerUID field
MUST only be used if the holder's PKC contains an issuerUniqueID MUST only be used if the holder's PKC contains an issuerUniqueID
field (in which case, the same value MUST be present in the field. If both the holder.baseCertificateID.issuerUID and the
holder.baseCertificateID.issuerUID_field). Thus, the issuerUniqueID fields are present, then the same value MUST be
baseCertificateID is only usable with PKC profiles (like [PKIXPROF]) present in both _fields. Thus, the baseCertificateID is only usable
which mandate that the PKC issuer field contain a non empty with PKC profiles (like [PKIXPROF]) which mandate that the PKC
distinguished name value. issuer field contain a non-empty distinguished name value.
Note: An "empty" distinguished name is a distinguished name where Note: An empty distinguished name is a distinguished name where the
the SEQUENCE OF relative distinguished names is of zero length. In a SEQUENCE OF relative distinguished names is of zero length. In a DER
DER encoding this has the value '3000'H. encoding this has the value '3000'H.
If the holder 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, unless the PKC subject field contains same as the PKC subject field, unless the PKC subject field contains
an empty distinguished name. In that case, the entityName field MUST an empty distinguished name. If the PKC subject field contains an
be identical to one of the values of the PKC subjectAltName field empty distinguished name, then the entityName field MUST be
identical to one of the values of the PKC subjectAltName field
extension. Note that [PKIXPROF] mandates that the subjectAltNames extension. Note that [PKIXPROF] mandates that the subjectAltNames
extension be present if the PKC subject is a non empty distinguished extension be present if the PKC subject is an empty distinguished
name. name.
In any other case where the holder 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
holder option is to be used and how this fits with the supported holder option is to be used and how this fits with the supported
authentication schemes define in that protocol. authentication schemes defined in that protocol.
4.2.3 Issuer 4.2.3 Issuer
ACs conforming to this profile MUST use the newForm.issuerName ACs conforming to this profile MUST use the v1Form choice, which
choice, which MUST contain one and only one GeneralName, which MUST MUST contain one and only one GeneralName, which MUST contain a non-
contain a non empty distinguished name in the directoryName field. empty distinguished name in the directoryName field. This means that
This means that all AC issuers MUST have non empty distinguished all AC issuers MUST have non-empty distinguished names.
names.
Part of the reason for the use of the issuerName field is that it Part of the reason for the use of the v1Form field is that it allows
allows the AC verifier to be independent of the AC issuer's public the AC verifier to be independent of the AC issuer's public key
key infrastructure. Using the baseCertificateId field to reference infrastructure. Using the baseCertificateID field to reference the
the AC issuer would mean that the AC verifier would have such a AC issuer would mean that the AC verifier would have such a
dependency. dependency.
4.2.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 [PKIXPROF] This MUST be one of the following algorithms defined in [PKIXPROF]
section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha- section 7.2 or [ECDSA] section 3.2: md5WithRSAEncryption, id-dsa-
1WithRSAEncryption, or ecdsa-with-SHA1 defined in [ECDSA] section with-sha1, sha-1WithRSAEncryption, or ecdsa-with-SHA1.
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.2.5 Serial Number 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.
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 sign bit in the DER encoding of the INTEGER value MUST that is, the sign bit in the DER encoding of the INTEGER value MUST
be zero - this can be done by adding a leading (leftmost) `00'H be zero - this can be done by adding a leading (leftmost) '00'H
octet if necessary. This removes a potential ambiguity in mapping octet if necessary. This removes a potential ambiguity in mapping
between a string of octets and an integer value. 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. AC users MUST be able to can be expected to contain long integers. AC users MUST be able to
handle serialNumber values longer than 32 bits. Conformant ACs MUST handle serialNumber values longer than 4 octets. Conformant ACs MUST
NOT use serialNumber values longer than 20 octets. NOT contain 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, but they MUST be unique for a be monotonically increasing with time. Each AC issuer MUST ensure
given AC issuer. that each AC that it issues contain a unique serial number.
4.2.6 Validity Period 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
holder 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. The GeneralizedTime
GeneralizedTime field can include a representation of the time field can optionally include a representation of the time
differential between local and Greenwich Mean Time. differential between the local time zone 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: this is the same as specified in [PKIXPROF], 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 AC users MUST be able to handle an AC which, at the time of
issued, which (at the time of parsing), has its entire validity processing, has its entire validity period in the future (a post-
period in the future (a "post-dated" AC). This is valid for some dated AC). This is valid for some applications, such as backup.
applications, e.g. backup.
4.2.7 Attributes 4.2.7 Attributes
The attributes field gives information about the AC holder. 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. Each The attributes field contains a SEQUENCE OF Attribute. Each
Attribute MAY contain a SET OF values. For a given AC each attribute Attribute MAY contain a SET OF values. For a given AC, each
type OID in the sequence MUST be unique, that is, only one instance AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That
of each attribute can occur in a single AC. All instances can is, only one instance of each attribute can occur in a single AC,
however, be multi-valued. but each instance can 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 an AC MUST contain at least one attribute, that is, the An AC MUST contain at least one attribute. That is, the SEQUENCE OF
SEQUENCE OF Attributes MUST NOT be of zero length. Attributes MUST NOT be of zero length.
Some standard attribute types are defined in section 4.5. Some standard attribute types are defined in section 4.5.
4.2.8 Issuer Unique Identifier 4.2.8 Issuer Unique Identifier
This field MUST NOT be used unless it is also used in the AC 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] 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 states that this field SHOULD NOT be used by conforming CAs, but
that applications SHOULD be able to parse PKCs containing the field. that applications SHOULD be able to parse PKCs containing the field.
4.2.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 holder. opposed to information about the AC holder.
Section 4.3 defines the extensions that MAY be used with this An AC that has no extensions conforms to the profile; however,
profile. An AC that has no extensions conforms to the profile. If section 4.3 defines the extensions that MAY be used with this
any other critical extension is used, then the AC does not conform profile. If any other critical extension is used, then the AC does
to this profile. An AC that contains additional non-critical not conform to this profile. However, if any other non-critical
extensions still conforms. extension is used, then the AC does conform to this profile.
The extensions defined for ACs provide methods for associating The extensions defined for ACs provide methods for associating
additional attributes with holders. This profile also allows additional attributes with holders. This profile also allows
communities to define private extensions to carry information unique communities to define private extensions to carry information unique
to those communities. Each extension in an AC may be designated as 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 critical or non-critical. An AC using system MUST reject an AC if
it encounters a critical extension it does not recognize; however, a it encounters a critical extension it does not recognize; however, a
non-critical extension may be ignored if it is not recognized. non-critical extension may be ignored if it is not recognized.
Section 4.3 presents recommended extensions used within Internet Section 4.3 presents recommended extensions used within Internet ACs
certificates and standard locations for information. Communities and standard locations for information. Communities may elect to
may elect to use additional extensions; however, caution should be use additional extensions; however, caution should be exercised in
exercised in adopting any critical extensions in ACs, which might adopting any critical extensions in ACs, which might prevent use in
prevent use in a general context. a general context.
4.3 Extensions. 4.3 Extensions
4.3.1 Audit Identity 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 holder directly identify individuals. This circumstance may make the use of
field of the AC unsuitable for use in audit trails. the AC holder field unsuitable for use in audit trails.
In order to allow for such cases an AC MAY contain an audit identity To allow for such cases, an AC MAY contain an audit identity
extension. Ideally it SHOULD be infeasible to derive the AC holder'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 without the co-operation of
of the AC issuer. the AC issuer.
The value of the audit identity plus the AC issuer/serial SHOULD The value of the audit identity along with the AC issuer/serial
then be used for audit/logging purposes. If the value of the audit SHOULD then be used for audit/logging purposes. If the value of the
identity is suitably chosen then a server/service administrator can audit identity is suitably chosen, then a server/service
use audit trails to track the behavior of an AC holder without being administrator can use audit trails to track the behavior of an AC
able to identify the AC holder. holder without being 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 holder 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 determine
"backwards" from the audit identity to the actual identity of the AC the actual identity of the AC holder from the audit identity.
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 holder however, this method doesn't allow tracking the same AC holder with
across different ACs. This means that an audit identity is only multiple ACs. Thus, an audit identity is only useful if it lasts for
useful if it lasts for longer than the typical AC lifetime - how longer than the typical AC lifetime. Auditing could also be based on
much longer is an issue for the AC issuer implementation. Auditing the AC holder's PKC issuer/serial; however, this will often allow
could also be based on the AC holder's PKC issuer/serial however, the server/service administrator identify the AC holder.
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 holder 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
holder 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 do not contain identifying
information.
The value of an audit identity MUST NOT be longer than 20 octets. The value of an audit identity MUST be longer than zero octets. 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.3.2 AC Targeting 4.3.2 AC Targeting
In order to allow that an AC is "targeted", the target information To target an AC , the target information extension, imported from
extension MAY be used to specify a number of servers/services. The [X.509-DAM], MAY be used to specify a number of servers/services.
intent is that the AC SHOULD only be usable at the specified The 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
be accepted by any server. may be accepted by any server.
In this profile, the targeting information simply consists of a list In this profile, the targeting information simply consists of a list
of named targets 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 {
targetName [0] GeneralName, Target ::= CHOICE {
targetGroup [1] GeneralName, targetName [0] GeneralName,
targetCertificate [2] IssuerSerial, targetGroup [1] GeneralName,
targetDigest [3] ObjectDigestInfo targetCert [2] TargetCert
} }
The targetCertificate and targetDigest fields are only present to TargetCert ::= SEQUENCE {
allow future compatibility with [X.509-DAM] and MUST NOT be used. targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
The targetCert CHOICE is only present to allow future compatibility
with [X.509-DAM] and MUST NOT be used.
The targets check passes if the current server (recipient) is one of The targets check passes if the current server (recipient) is one of
the targetName fields in the targets part, or, the current server is the targetName fields in the Targets SEQUENCE, or if the current
a member of one of the targetGroup fields in the targets part. In server is a member of one of the targetGroup fields in the Targets
this case, the current server is said to "match" the targeting SEQUENCE. In this case, the current server is said to "match" the
extension. targeting extension.
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 targetGroups to which it belongs or can otherwise
determine its membership. For example, if the targetGroup were to be determine its membership. For example, the targetGroup specifies a
a DNS domain and the AC verifier knows the DNS domain to which it DNS domain, and the AC verifier knows the DNS domain to which it
belongs. Another example would be where the targetGroup is belongs. For another example, the targetGroup specifies "PRINTERS,"
"PRINTERS" and the AC verifier "knows" that it's a printer or print and the AC verifier knows whether or not it is a printer or print
server. server.
name id-pe-ac-targeting name id-ce-targetInformation
<<will change this to id-ce-targetInformation from DAM if ISO can OID { id-ce 55 }
change its syntax otherwise stick with the PKIX OID and live with
two different targeting extensions>>
OID { id-pe 5 }
syntax Targets syntax Targets
criticality MUST be TRUE criticality MUST be TRUE
4.3.3 Authority Key Identifier 4.3.3 Authority Key Identifier
The authorityKeyIdentifier extension as profiled in [PKIXPROF] MAY The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY
be used to assist the AC verifier in checking the signature of the be used to assist the AC verifier in checking the signature of the
AC. The [PKIXPROF] 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 Note: An AC where the issuer field used the baseCertificateID CHOICE
would not need an authorityKeyIdentifier extension as it is would not need an authorityKeyIdentifier extension as it is
explicitly linked to the key in the referred certificate. However, explicitly linked to the key in the referred certificate. However,
as this profile states (in section 4.2.3) that ACs MUST use the as this profile states (in section 4.2.3) that ACs MUST use the
entityName choice, this does not arise here. v1Form CHOICE, this duplication does not arise.
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.3.4 Authority Information Access 4.3.4 Authority Information Access
The authorityInformationAccess extension as defined in [PKIXPROF] 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. Note that support for the id-ad-caIssuers status of the AC. Support for the id-ad-caIssuers accessMethod is
accessMethod defined in [PKIXPROF] is NOT REQUIRED as in this NOT REQUIRED by this profile since AC chains are not expected. The
profile, the authorityInformationAccess is only used for revocation authorityInformationAccess extension is only used to support
status checking. Conformant ACs containing this extension MUST revocation status checking, therefore conformant ACs containing this
contain exactly one AccessDescription. extension MUST contain exactly one AccessDescription.
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 [OCSP]: defined in [OCSP]:
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
The accessLocation must contain a URI, this MUST contain an HTTP The accessLocation MUST contain a URI, and theURI MUST contain an
URL, specifying the location of an OCSP responder. The AC issuer HTTP URL [URL] that specifies the location of an OCSP responder. The
MUST, of course, maintain an OCSP responder at this location. 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 FALSE criticality MUST be FALSE
4.3.5 CRL Distribution Points 4.3.5 CRL Distribution Points
The crlDistributionPoints extension as profiled in [PKIXPROF] MAY be The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY
used to assist the AC verifier in checking the revocation status of be used to assist the AC verifier in checking the revocation status
the AC. See section 6 on revocation below for details. of the AC. See section 6 for details on revocation.
Exactly one distribution point MUST be present, it MUST use the If the crlDistributionPoints extension is present, then exactly one
DistributionPointName option, which MUST contain a fullName, which distribution point MUST be present. The crlDistributionPoints
MUST contain a single name form. That name MUST contain either an extension MUST use the DistributionPointName option, which MUST
HTTP URL or a distinguished name. contain a fullName, which MUST contain a single name form. That name
MUST contain either a distinguished name or a URI. The URI MUST be
either an HTTP URL or an LDAP URL [URL].
name id-ce-cRLDistributionPoints name id-ce-cRLDistributionPoints
OID { id-ce 31 } OID { id-ce 31 }
syntax CRLDistPointsSyntax syntax CRLDistPointsSyntax
criticality MUST be FALSE criticality MUST be FALSE
4.3.6 No Revocation Available 4.3.6 No Revocation Available
This extension (imported from [X.509-DAM]) allows an AC issuer to The noRevAvail extension, defined in [X.509-DAM], allows an AC
indicate that no revocation information will be made available for issuer to indicate that no revocation information will be made
this AC. available for this AC.
This extension MUST be non-critical, on the basis that an AC This extension MUST be non-critical. An AC verifier that does not
verifier that does not understand it can still find a revocation understand this extension might be able to find a revocation list
list (for example), but won't ever find an entry for the AC. from the AC issuer, but the revocation list will never include an
entry for the AC.
name id-ce-noRevAvail name id-ce-noRevAvail
OID { id-ce 56 } OID { id-ce 56 }
syntax NULL (i.e. '0500'H is the DER encoding) syntax NULL (i.e. '0500'H is the DER encoding)
criticality MUST be FALSE criticality MUST be FALSE
4.4 Attribute Types 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, also defined below. The reasons for using this
are: type 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 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,
OID and UTF8String, which reduces some of the matching OBJECT IDENTIFIER, and UTF8String, which significantly reduces
complexities associated with more general syntaxes. All multi- the complexity associated with matching more general syntaxes.
valued attributes using this syntax are restricted so that each All multi-valued attributes using this syntax are restricted so
value MUST use the same choice of value syntax, that is, it is that each value MUST use the same choice of value syntax. For
not allowed that one value use an OID but that a second value example, AC issuers must not use one value with an oid and a
uses a string. second value with a string.
IetfAttrSyntax ::= 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
} }
} }
In the descriptions below, each attribute type is tagged as either In the descriptions below, each attribute type is tagged as either
"Multiple Allowed" or "One Attribute value only; multiple values "Multiple Allowed" or "One Attribute value only; multiple values
within the IetfAttrSyntax". This refers to the SET OF within the IetfAttrSyntax". This refers to the SET OF
AttributeValue, the AttributeType still only occurs once, as AttributeValue, the AttributeType still only occurs once, as
specified in section 4.2.7. specified in section 4.2.7.
4.4.1 Service Authentication Information 4.4.1 Service Authentication Information
This attribute type identifies the AC holder to the server/service The SvceAuthInfo attribute identifies the AC holder to the
by a name and MAY include optional service specific authentication server/service by a name, and the attribute MAY include optional
information. Typically this will contain a username/password pair service specific authentication information. Typically this will
for a "legacy" application. contain a username/password pair for a "legacy" application.
This attribute type will typically need to be encrypted if the This attribute type will typically be encrypted when the authInfo
authInfo field contains sensitive information (e.g. a password). field contains sensitive information, such as 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.4.2 Access Identity 4.4.2 Access Identity
An access identity identifies the AC holder to the server/service. The accessIdentity attribute identifies the AC holder to the
For this attribute the authInfo field MUST NOT be present. server/service. 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.4.3 Charging Identity 4.4.3 Charging Identity
This attribute type identifies the AC holder for charging purposes. The chargingIdentity attribute identifies the AC holder for charging
Note that, in general, the charging identity will be different from purposes. In general, the charging identity will be different from
other identities of the holder, for example, when the holderÆs other identities of the holder. For example, the holder's company
company is to be charged for service. may 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: One Attribute value only; multiple values within the values: One Attribute value only; multiple values within the
IetfAttrSyntax IetfAttrSyntax
4.4.4 Group 4.4.4 Group
This attribute carries information about group memberships of the AC The group attribute carries information about group memberships of
holder. the AC holder.
name id-aca-group name id-aca-group
OID { id-aca 4 } OID { id-aca 4 }
syntax IetfAttrSyntax syntax IetfAttrSyntax
values: One Attribute value only; multiple values within the values: One Attribute value only; multiple values within the
IetfAttrSyntax IetfAttrSyntax
4.4.5 Role 4.4.5 Role
This attribute (imported from [X.509-DAM]) carries information about The role attribute, specified in [X.509-DAM], carries information
role allocations of the AC holder. about role allocations of the AC holder.
The syntax used for this attribute is: The syntax used for this attribute is:
RoleSyntax ::= SEQUENCE { RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL, roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName roleName [1] GeneralName
} }
The roleAuthority field MUST NOT be used. The roleName field MUST be The roleAuthority field MUST NOT be used. The roleName field MUST be
present and MUST use the uniformResourceIdentifier field of the present, and roleName MUST use the uniformResourceIdentifier CHOICE
GeneralName. of the GeneralName.
name id-at-role name id-at-role
OID { id-aca 5 } OID { id-at 72 }
syntax RoleSyntax syntax RoleSyntax
values: Multiple allowed values: Multiple allowed
4.4.6 Clearance 4.4.6 Clearance
This attribute (imported from [X.501]) carries clearance (security The clearance attribute, specified in [X.501-93], carries clearance
labeling) information about the AC holder. (associated with security labeling) information about the AC holder.
The policyId field is used to identify the security policy to which
the clearance relates. The policyId indicates the semantics of the
classList and securityCategories fields.
This specification includes the classList field exactly as is
specified in [X.501-93]. Additional security classification values,
and their position in the classification hierarchy, may be defined
by a security policy as a local matter or by bilateral agreement.
The basic security classification hierarchy is, in ascending order:
unmarked, unclassified, restricted, confidential, secret, and top-
secret.
An organization can develop its own security policy that defines
security classification values and their meanings. However, the BIT
STRING positions 0 through 5 are reserved for the basic security
classification hierarchy.
If present, the SecurityCategory field provides further
authorization information. The security policy identified by the
policyId field indicates the syntaxes that are allowed to be present
in the securityCategories SET. An OBJECT IDENTIFIER identifies each
of the allowed syntaxes. When one of these syntaxes is present in
the securityCategories SET, the OBJECT IDENTIFIER associated with
that syntax is carried in the SecurityCategory.type field.
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),
unclassified (1), unclassified (1),
restricted (2) restricted (2)
confidential (3), confidential (3),
secret (4), secret (4),
topSecret (5) topSecret (5)
} }
skipping to change at page 21, line 5 skipping to change at page 20, line 47
-- 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
The security category value above can uses the ASN.1 ANY construct.
Conformant ACs MUST only use UTF8String, OID and OCTET STRING
syntaxes for this value.
name { id-at-clearance } name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) module(1) selected- OID { joint-iso-ccitt(2) ds(5) module(1)
attribute-types(5) clearance (55) } selected-attribute-types(5) clearance (55) }
syntax Clearance - imported from [X.501] syntax Clearance - imported from [X.501-93]
values Multiple allowed values Multiple allowed
4.5 Profile of AC Issuer's PKC 4.5 Profile of AC issuer's PKC
The AC Issuer's PKC MUST conform to [PKIXPROF] and its keyUsage MUST The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
NOT explicitly indicate that the AC issuer can't sign. In order to extension in the PKC MUST NOT explicitly indicate that the AC
avoid confusion (e.g. over serial numbers or revocations) an AC issuer's public key cannot be used to validate a digital signature.
issuer MUST NOT also be a PKC Issuer (i.e. it can't be a CA as In order to avoid confusion regarding serial numbers and
well), so the AC Issuer's PKC MUST NOT have a basicConstraints revocations, an AC issuer MUST NOT also be a PKC Issuer. That is,
extension with isACA set to TRUE. an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST
NOT have a basicConstraints extension with the cA BOOLEAN 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
MUST satisfy. Some additional checks are also described which AC 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 entire certification path (including the AC issuer's issuer's entire PKC certification path MUST be verified in
PKC) MUST be verified in accordance with [PKIXPROF]. 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.5 above. in section 4.5 above.
3. The AC issuer MUST be directly trusted as an AC issuer (by 3. The AC issuer MUST be directly trusted as an AC issuer (by
configuration or otherwise). configuration or otherwise).
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 timelyand 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.3.2 above) 5. The AC targeting check MUST pass as specified in section 4.3.2.
6. If the AC contains any "unsupported" critical extensions then 6. If the AC contains a critical extension that is not listed in
the AC MUST be rejected. section 4.3, then 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, 1. The AC verifier MUST be able to parse the extension value.
b. where the extension value SHOULD cause the AC to be rejected, the 2. Where the extension value SHOULD cause the AC to be rejected,
AC verifier MUST reject the AC. the AC verifier MUST reject the AC.
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 attributes.
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. For example, an AC verifier might be
not to return certain attributes to certain targets. configured not to return certain attributes to certain servers.
6. Revocation 6. Revocation
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 Two revocation schemes are defined, and the AC issuer should elect
revocation related schemes. the one that is best suited to the environment in which the AC will
be employed.
"Never revoke" scheme: ACs may be marked so that the relying party "Never revoke" scheme:
understands that no revocation status information will be made
available. A noRevAvail extension as defined in section 4.3.6 above
MUST be present in the AC to indicate this.
Where no noRevAvail is not present, then the AC issuer is implicitly ACs may be marked so that the relying party understands that no
stating that revocation status checks are supported and some method revocation status information will be made available. The
MUST be provided to allow AC verifiers to establish the revocation noRevAvail extension is defined in section 4.3.6, and the
status of the AC. noRevAvail extension MUST be present in the AC to indicate use
of this scheme.
"Pointer in AC" scheme: ACs may be marked (like PKCs) to "point" to Where no noRevAvail is not present, then the AC issuer is
sources of revocation status information (using an implicitly stating that revocation status checks are supported,
authorityInfoAccess or crlDistributionPoints extension in the AC and some revocation method MUST be provided to allow AC
itself). verifiers to establish the revocation status of the AC.
For AC users, the "never revoke" scheme MUST be supported, the "Pointer in AC" scheme:
ACs may "point" to sources of revocation status information,
using either an authorityInfoAccess extension or a
crlDistributionPoints extension within the AC.
For AC users, the "never revoke" scheme MUST be supported, and the
"pointer in AC" scheme SHOULD be supported. If only the "never "pointer in AC" scheme SHOULD be supported. If only the "never
revoke" scheme is supported, then all ACs that do not contain a revoke" scheme is supported, then all ACs that do not contain a
noRevAvail extension, MUST be rejected. noRevAvail extension, MUST be rejected.
For AC issuers, the "never revoke" scheme MUST be supported. If all For AC issuers, the "never revoke" scheme MUST be supported. If all
ACs that will ever be issued by that AC issuer, will contain a ACs that will ever be issued by that AC issuer, will contain a
noRevAvail extension, then the "pointer in AC" scheme NEED NOT be noRevAvail extension, then the "pointer in AC" scheme need not be
supported. If any AC can be issued that does not contain the supported. If any AC can be issued that does not contain the
noRevAvail extension, then the "pointer in AC" scheme MUST be noRevAvail extension, then the "pointer in AC" scheme MUST be
supported. supported.
All conformant ACs MUST contain exactly one of the noRevAvail, All conformant ACs MUST contain exactly one of the noRevAvail,
authorityInformationAccess or crlDistributionPoints extensions. That authorityInformationAccess or crlDistributionPoints extensions. That
is, the crlDistributionPoints, authorityInformationAccess and is, the crlDistributionPoints, authorityInformationAccess and
noRevAvail extensions are mutually exclusive for a single AC and an noRevAvail extensions are mutually exclusive for a single AC, and
AC MUST NOT contain more than one of these extensions. This differs one AC MUST NOT contain more than one of these extensions. This
from the case with PKCs. An AC verifier MAY use other (e.g. differs from PKCs, which permit both authorityInformationAccess and
configured) sources for AC revocation status information. crlDistributionPoints extensions within one PKC.
An AC verifier MAY any use source 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 profile does NOT require support for these features;
however, if these features are offered, they MUST be offered as
described below.
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 like a legacy
application username/password) then encryption of AC attributes MAY application username/password, then encryption of AC attributes MAY
be needed. be needed.
When a set of attributes are to be encrypted within an AC, the When a set of attributes are to be encrypted within an AC, the
cryptographic message syntax, EnvelopedData structure [CMS] is used Cryptographic Message Syntax, EnvelopedData structure [CMS] is used
to carry the ciphertext(s) and associated per-recipient keying to carry the ciphertext and associated per-recipient keying
information. information.
This type of attribute encryption is targeted, which means that This type of attribute encryption is targeted. Before the AC is
before the AC is signed the attributes have been encrypted for a set signed, the attributes are encrypted for a set of predetermined
of predetermined recipients. recipients.
The AC then contains the ciphertext(s) inside its signed data. The The AC then contains the ciphertext inside its signed data. The
"enveloped-data" (id-envelopedData) ContentType is used and the EenvelopedData (id-envelopedData) ContentType is used, and the
content field will contain the EnvelopedData type. content field will contain the EnvelopedData type.
The set of ciphertexts is included into the AC as the value of an The ciphertext is included in the AC as the value of an encAttrs
encrypted attributes attribute. Only one encrypted attributes attribute. Only one encAttrs attribute can be present in an AC;
attribute can be present in an AC - however it MAY be multi-valued however, the encAttrs attribue MAY be multi-valued, and each of its
and each of its values will contain an EnvelopedData. values will contain an independent EnvelopedData.
Each value can contain a set of attributes (each possibly a multi- Each value can contain a set of attributes (each possibly a multi-
valued attribute) encrypted for a set of recipients. valued attribute) encrypted for a set of predetermined recipients.
The cleartext that is encrypted has the type: The cleartext that is encrypted has the type:
ACClearAttrs ::= SEQUENCE { ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName, acIssuer GeneralName,
acSerial INTEGER, acSerial INTEGER,
attrs SEQUENCE OF Attribute attrs SEQUENCE OF Attribute
} }
The DER encoding of the ACClearAttrs structure is used as the The DER encoding of the ACClearAttrs structure is used as the
encryptedContent field of the EnvelopedData, i.e. the DER encoding encryptedContent field of the EnvelopedData. The DER encoding MUST
MUST be embedded in an OCTET STRING. be embedded in an OCTET STRING.
The acIssuer and acSerial fields are present to prevent ciphertext The acIssuer and acSerial fields are present to prevent ciphertext
stealing - when an AC verifier has successfully decrypted an stealing. When an AC verifier has successfully decrypted an
encrypted attribute it MUST then check that the AC issuer and encrypted attribute it MUST then check that the AC issuer and
serialNumber fields contain the same values. This prevents a serialNumber fields contain the same values. This prevents a
malicious AC issuer from copying ciphertext from another AC issuer's malicious AC issuer from copying ciphertext from another AC (without
AC into an AC issued by the malicious AC issuer. knowing its corresponding plaintext).
The procedure for an AC issuer when encrypting attributes is The procedure for an AC issuer when encrypting attributes is
illustrated by the following (any other procedure that gives the illustrated by the following (any other procedure that gives the
same result MAY be used): same result MAY be used):
1. Identify the sets of attributes that are to be encrypted for 1. Identify the sets of attributes that are to be encrypted for
each set of recipients. each set of recipients.
2. For each attribute set which is to be encrypted: 2. For each attribute set which is to be encrypted:
2.1. Create an EnvelopedData structure for the data for this 2.1. Create an EnvelopedData structure for the data for this
set of recipients. set of recipients.
2.2. Encode the EnvelopedData as a value of the 2.2. Encode the ContentInfo containing the EnvelopedData as a
EncryptedAttributes attribute value of the encAttrs attribute
2.3. Ensure the cleartext attribute(s) are not present in the 2.3. Ensure the cleartext attributes are not present in the
to-be-signed AC to-be-signed AC
3. Add the EncryptedAttribute (with its multiple values) to the 3. Add the encAttrs (with its multiple values) to the AC
AC
Note that the rule that each attribute type (the OID) only occurs Note that there may be more than one attribute of the same type (the
once may not hold after decryption. That is, an AC MAY contain the same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain
same attribute type both in clear and in encrypted form (and indeed the same attribute type both in clear and in encrypted form (and
more than once if the decryptor is a recipient for more than one indeed several times if the same recipient is associated with more
EnvelopedData). One approach implementers may choose, would be to than one EnvelopedData). One approach implementers may choose, would
merge attributes values following decryption in order to re- be to merge attributes values following decryption in order to re-
establish the "once only" constraint. establish the "once only" constraint.
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. does fail, 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 When a server acts as a client for another server on behalf of the
a client (for another server) on behalf of the AC holder. Such AC holder, the server MAY need to proxy an AC. Such proxying MAY
proxying may have to be under the AC issuer's control, so that not have to be done under the AC issuer's control, so that not every AC
every AC is proxiable and so that a given proxiable AC can be is proxiable and so that a given proxiable AC can be proxied in a
proxied in a targeted fashion. Support for chains of proxies (with targeted fashion. Support for chains of proxies (with more than one
more than one intermediate server) is also sometimes required. Note intermediate server) MAY also be required. Note that this does not
that this does not involve a chain of ACs. 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 holder 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
As in the case of targeting, the targetCertificate and targetDigest As in the case of targeting, the targetCert CHOICE MUST NOT be used.
fields MUST NOT be used.
A proxy check succeeds if either one of the conditions below is met: A proxy check succeeds if either one of the conditions below is met:
1. 1. The identity of the sender as established by the underlying
The identity of the sender as established by the underlying authentication service matches the holder field of the AC, and the
authentication service matches the holder field of the AC, and, current server "matches" any one of the proxy sets. Recall that
the current server "matches" any one of the proxy sets (where "matches" is as defined section 4.3.2.
"matches" is as defined for the targeting check in section 4.3.2
above).
2. 2. The identity of the sender as established by the underlying
The identity of the sender as established by the underlying authentication service "matches" one of the proxy sets (call it
authentication service "matches" one of the proxy sets (call it set "A"), and the current server is one of the targetName fields
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
in the set "A", or, the current server is a member of one of the targetGroup fields in set "A".
targetGroup fields in set "A".
Where an AC is proxied more than once a number of targets will be on When 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 holder. 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 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 holder field baseCertificateID). The objectDigestInfo CHOICE in the holder field
allows support for this requirement. allows support for this requirement.
If the holder is identified via the objectDigestInfo field then the If the holder is identified with the objectDigestInfo field, then
AC version field MUST contain v2 (i.e. the integer 1). the AC version field MUST contain v2 (the integer 1).
The basic idea is to link the AC to an object by placing a hash of The idea is to link the AC to an object by placing a hash of that
that object into the holder field of the AC. For example, this object into the holder field of the AC. For example, this allows
allows production of ACs that are linked to public keys rather than production of ACs that are linked to public keys rather than names.
names, or production of ACs which contain privileges associated with
an executable object (e.g. a Java class).
However, this profile only specifies how to use a hash over a public It also allows production of ACs which contain privileges associated
key or PKC, that is, conformant ACs MUST NOT use the with an executable object such as a Java class. However, this
otherObjectTypes value for the digestedObjectType. 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 To link an AC to a public key, the hash must be calculated over the
over the representation of that public key which would be present in representation of that public key which would be present in a PKC,
a PKC, specifically, the input for the hash algorithm MUST be the specifically, the input for the hash algorithm MUST be the DER
DER encoding of a SubjectPublicKeyInfo representation of the key. encoding of a SubjectPublicKeyInfo representation of the key. Note:
Note: This includes the AlgorithmIdentifier as well as the BIT This includes the AlgorithmIdentifier as well as the BIT STRING. The
STRING. The rules given in [PKIXPROF] and [ECDSA] for encoding keys rules given in [PKIXPROF] and [ECDSA] for encoding keys MUST be
MUST be followed. In this case the digestedObjectType MUST be followed. In this case the digestedObjectType MUST be publicKey and
publicKey and the otherObjectTypeID field MUST NOT be present. 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 DSA Dss-parms are inherited as described
described in section 7.3.3 of [PKIXPROF]. The correct input for in section 7.3.3 of [PKIXPROF]. The correct input for hashing in
hashing in this context will include the value of the parameters this context will include the value of the parameters inherited from
inherited from the CA's PKC, and thus may differ from the the CA's PKC, and thus may differ from the SubjectPublicKeyInfo
SubjectPublicKeyInfo present in the PKC. 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 public keys for the algorithms specified in
7.3 of [PKIXPROF] and those specified in [ECDSA]. In this case the section 7.3 of [PKIXPROF] and those specified in [ECDSA]. In this
digestedObjectType MUST be publicKey and the otherObjectTypeID field case the digestedObjectType MUST be publicKey and the
MUST NOT be present. otherObjectTypeID field MUST NOT be present.
In order to link an AC to a PKC via a digest, the digest MUST be 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 calculated over the DER encoding of the entire PKC, including the
the signature bits). In this case the digestedObjectType MUST be signature value. In this case the digestedObjectType MUST be
publicKeyCert and the otherObjectTypeID field MUST NOT be present. publicKeyCert and the otherObjectTypeID field MUST NOT be present.
7.4 AA Controls 7.4 AA Controls
During AC validation a relying party has to answer the question: "is During AC validation a relying party has to answer the question: is
this AC issuer trusted to issue ACs containing this attribute?" The this AC issuer trusted to issue ACs containing this attribute? The
AAControls PKC extension, intended to be used in CA and AC Issuer AAControls PKC extension MAY be used to help answer the question.
PKCs, MAY be used to help answer the question. The AAControls extension is intended to be used in CA and AC issuer
PKCs.
Note that this extension is quite likely to change in future based
on experience with the use of ACs in the Internet.
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
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
The aaControls extension is used as follows: The AAControls extension is used as follows:
The pathLenConstraint, if present, is interpreted as in [PKIXPROF], The pathLenConstraint, if present, is interpreted as in [PKIXPROF].
but now restricts the allowed "distance" between the AA CA, (a CA It restricts the allowed distance between the AA CA, (a CA directly
directly trusted to include AAControls in its PKCs), and the AC trusted to include AAControls in its PKCs), and the AC issuer.
issuer.
The permittedAttrs field specifies a set of attribute types that any 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 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 field is not present, it means that no attribute types are
explicitly allowed (though the permitUnSpecified field may open explicitly allowed.
things up).
The excludedAttrs field specifies a set of attribute types that no The excludedAttrs field specifies a set of attribute types that no
AC issuer is allowed to include in ACs. If this field is not AC issuer is allowed to include in ACs. If this field is not
present, it means that no attribute types are explicitly disallowed 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 The permitUnSpecified field specifies how to handle attribute types
which are not present in either the permittedAttrs or excludedAttrs which are not present in either the permittedAttrs or excludedAttrs
fields. TRUE (the default) means that any unspecified attribute type fields. TRUE (the default) means that any unspecified attribute type
is allowed in ACs; FALSE means that no unspecified attribute type is is allowed in ACs; FALSE means that no unspecified attribute type is
allowed. allowed.
Where aaControls are used then the following additional checks on an When AAControls are used, the following additional checks on an AA's
AA's PKC chain MUST all succeed for the AC to be valid: PKC chain MUST all succeed for the AC to be valid:
1. Some CA on the AC's certificate path MUST be directly trusted 1. Some CA on the ACs certificate path MUST be directly trusted to
to issue PKCs which precede the AC issuer in the certification issue PKCs which precede the AC issuer in the certification
path, call this CA the "AA CA". path, call this CA the "AA CA".
2. All PKC's on the path from the AA CA down to and including the 2. All PKCs on the path from the AA CA down to and including the
AC issuer's PKC MUST contain an aaControls extension as defined AC issuer's PKC MUST contain an AAControls extension; however,
below (the PKC with the AA CA's as subject need not contain the AA CA's PKC need not contain this extension.
this extension).
3. Only those attributes in the AC which are allowed according to 3. Only those attributes in the AC which are allowed according to
all of the aaControls extension values in all of the PKCs from all of the AAControls extension values in all of the PKCs from
the AA CA to the AC issuer, may be used for authorization the AA CA to the AC issuer, may be used for authorization
decisions, all other attributes MUST be ignored (note that this decisions, all other attributes MUST be ignored. This check
check MUST be applied to the set of attributes following MUST be applied to the set of attributes following attribute
attribute decryption and that in such cases the id-aca-encAttrs decryption, and the id-aca-encAttrs type MUST also be checked.
type MUST also be checked).
name id-pe-aaControls name id-pe-aaControls
OID { id-pe 6 } OID { id-pe 6 }
syntax AAControls syntax AAControls
criticality MAY be TRUE criticality MAY be TRUE
8. Security Considerations 8. Security Considerations
The protection afforded private keys is a critical factor in
maintaining security. Failure of AC issuers to protect their
private keys will permit an attacker to masquerade as them,
potentially generating false ACs or revocation status. Existence of
bogus ACs and revocation status will undermine confidence in the
system. If the compromise is detected, all ACs issued to the AC
issuer MUST be revoked. Rebuilding after such a compromise will be
problematic, so AC issuers are advised to implement a combination of
strong technical measures (e.g., tamper-resistant cryptographic
modules) and appropriate management procedures (e.g., separation of
duties) to avoid such an incident.
Loss of a AC issuer's private signing key may also be problematic.
The AC issuer would not be able to produce revocation status or
perform AC renewal. AC issuer's are advised to maintain secure
backup for signing keys. The security of the key backup procedures
is a critical factor in avoiding key compromise.
The availability and freshness of revocation status will affect the
degree of assurance that should be placed in a long-lived AC. While
long-lived ACs expire naturally, events may occur during its natural
lifetime which negate the binding between the AC holder and the
attributes. If revocation status is untimely or unavailable, the
assurance associated with the binding is clearly reduced.
The binding between an AC holder and attributes cannot be stronger
than the cryptographic module implementation and algorithms used to
generate the signature. Short key lengths or weak hash algorithms
will limit the utility of an AC. AC issuers are encouraged to note
advances in cryptology so they can employ strong cryptographic
techniques.
Inconsistent application of name comparison rules may result in
acceptance of invalid targeted or proxied AC, or rejection of valid
ones. The X.500 series of specifications defines rules for
comparing distinguished names. These rules require comparison of
strings without regard to case, character set, multi-character white
space substrings, or leading and trailing white space. This
specification and [PKIXPROF] relaxes these requirements, requiring
support for binary comparison at a minimum.
AC issuers MUST encode the distinguished name in the AC
holder.entityName field identically to the distinguished name in the
holder's PKC. If different encodings are used, implementations of
this specification may fail to recognize that the AC and PKC belong
to the same entity.
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. Given that the AA controls PKC extension is optional to be ignored. Given that the AA controls PKC extension is optional to
implement, this means that AC verifiers MUST be provided with the implement, AC verifiers MUST be provided with this information by
required information by other means - e.g. by configuration. This other means. Configuration information is a likely alternative
becomes very important if an AC verified trusts more than one AC means. This becomes very important if an AC verified trusts more
issuer. 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 security protocol (e.g. TLS, S/MIME) and
holder's identity. If the authentication uses PKCs then this mapping the AC holder's identity. If the authentication uses PKCs, then this
is straightforward. However, it is envisaged that ACs will also be mapping is straightforward. However, it is envisaged that ACs will
used in environments where the holder may be authenticated using also be used in environments where the holder may be authenticated
other means. Implementers SHOULD be very careful in mapping the using other means. Implementers SHOULD be very careful in mapping
authenticated identity to the AC holder. the 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", draft-ietf-pkix-cmc-05.txt, July 1999. CMS", draft-ietf-pkix-cmc-05.txt, July 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", RFC 2630. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
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-02.txt, October 1999. draft-ietf-pkix-ipki-ecdsa-02.txt, October 1999.
[LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
(v3)", RFC 2251. RFC2634.
[KRB] Kohl, J., Neuman, C., "The Kerberos Network [KRB] Kohl, J., Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510. Authentication Service (V5)", RFC 1510.
[LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol
(v3)", RFC 2251.
[OCSP] Myers, M., et al., " X.509 Internet Public Key
Infrastructure - Online Certificate Status Protocol -
OCSP", RFC 2560.
[PKINIT] Tung, B., et al., "Public Key Cryptography for Initial [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial
Authentication in Kerberos", draft-ietf-cat-kerberos-pk- Authentication in Kerberos", draft-ietf-cat-kerberos-pk-
init-10.txt init-10.txt
[PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet [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",RFC 2459. Profile", RFC 2459.
[OCSP] Myers, M., et al., " X.509 Internet Public Key
Infrastructure - Online Certificate Status Protocol -
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 - [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform
Open Systems Interconnection - The Directory: Models, Resource Locators (URL)", RFC 1738.
1993.
[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.501-93] ITU-T Recommendation X.501 : Information Technology -
Open Systems Interconnection - The Directory: Models,
1993.
[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.
[X.509-DAM] 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 - Draft Amendment 1: Certificate Extensions, Framework - Draft Amendment 1: Certificate Extensions,
October 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
email: stephen.farrell@baltimore.ie email: stephen.farrell@baltimore.ie
Russell Housley, Russell Housley
SPYRUS, SPYRUS
381 Elden Street, 381 Elden Street
Suite 1120, Suite 1120
Herndon, VA 20170, Herndon, VA 20170
USA USA
tel: +1-703-707-0696
email: housley@spyrus.com email: housley@spyrus.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
skipping to change at page 32, line 5 skipping to change at page 33, 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 B: Object Identifiers Appendix A: Object Identifiers
This (normative) appendix lists the new object identifiers which are This (normative) appendix lists the new object identifiers which are
defined in this specification. Some of these are required only for defined in this specification. Some of these are required only for
support of optional features and are not required for conformance to support of optional features and are not required for conformance to
this profile. this profile. This specification mandates support for OIDs which
have arc elements with values that are less than 2^32, (i.e. they
This specification mandates support for OIDs which have arc elements MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
with values that are less than 2^28, i.e. they MUST be between 0 and than 2^31 (i.e. less than or equal to 2,147,483,647). This allows
268,435,455 inclusive. This allows each arc element to be each arc element to be represented within a single 32 bit word.
represented within a single 32 bit word. Implementations MUST also Implementations MUST also support OIDs where the length of the
support OIDs where the length of the dotted decimal (see [LDAP], dotted decimal (see [LDAP], section 4.1.2) string representation can
section 4.1.2) string representation can be up to 100 bytes be up to 100 bytes (inclusive). Implementations MUST be able to
(inclusive). Implementations MUST be able to handle OIDs with up to handle OIDs with up to 20 elements (inclusive). AA's SHOULD NOT
20 elements (inclusive). AA's SHOULD NOT issue ACs which contain issue ACs which contain OIDs that breach these requirements.
OIDs that breach these requirements.
The following OIDs are imported from [PKIXPROF]: The following OIDs are imported from [PKIXPROF]:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) } dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
The following new ASN.1 module OID is defined: The following new ASN.1 module OID is defined:
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
The following AC extension OIDs are defined: The following AC extension OIDs are defined:
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-proxying OBJECT IDENTIFIER ::= { id-pe 7 } id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
The following PKC extension OIDs are defined: The following PKC extension OIDs are defined:
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
The following attribute OIDs are defined: The following attribute OIDs are defined:
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-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::=
{ joint-iso-ccitt(2) ds(5) module(1)
selected-attribute-types(5) clearance (55) }
Appendix B: "Compilable" ASN.1 Module Appendix B: 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 --
IMPORTS IMPORTS
-- PKIX Certificate Extensions -- PKIX Certificate Extensions
Attribute, AlgorithmIdentifier, CertificateSerialNumber, Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, Extensions, UniqueIdentifier,
id-pkix, id-pe, id-kp, id-ad id-pkix, id-pe, id-kp, id-ad, id-at
FROM PKIX1Explicit88 {iso(1) identified-organization(3) FROM PKIX1Explicit88 {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-explicit-88(1)} pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
GeneralName, GeneralNames GeneralName, GeneralNames, id-ce
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-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-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
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 5 } is reserved -- { id-aca 5 } is reserved
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72}
id-at-clearance OBJECT IDENTIFIER ::=
{ joint-iso-ccitt(2) ds(5) module(1)
selected-attribute-types(5) clearance (55) }
-- Uncomment this if using a 1988 level ASN.1 compiler
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
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,
holder Holder, holder Holder,
issuer AttCertIssuer, issuer AttCertIssuer,
skipping to change at page 34, line 24 skipping to change at page 35, line 32
baseCertificateID [0] IssuerSerial OPTIONAL, baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of -- the issuer and serial number of
-- the holder'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 { digestedObjectType ENUMERATED {
publicKey (0), publicKey (0),
publicKeyCert (1), publicKeyCert (1),
otherObjectTypes (2) }, otherObjectTypes (2) },
-- otherObjectTypes MUST NOT -- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile -- MUST NOT be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier, digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING objectDigest BIT STRING
} }
AttCertIssuer ::= CHOICE { AttCertIssuer ::= CHOICE {
oldForm GeneralNames, v1Form GeneralNames, -- v1 or v2
newForm [0] SEQUENCE { v2Form [0] V2Form -- v2 only
issuerName GeneralNames OPTIONAL, }
baseCertificateId [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL V2Form ::= SEQUENCE {
-- at least one of issuerName, baseCertificateId or -- issuerName GeneralNames OPTIONAL,
-- objectDigestInfo must be present -- baseCertificateID [0] IssuerSerial OPTIONAL,
-- if newForm is used, version must be v2-- objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- at least one of issuerName, baseCertificateID
-- or objectDigestInfo must be present
} }
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, targetCert [2] TargetCert
targetDigest [3] ObjectDigestInfo }
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
IetfAttrSyntax ::= 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,
ident GeneralName, ident GeneralName,
authInfo OCTET STRING OPTIONAL authInfo OCTET STRING OPTIONAL
} }
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
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),
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
} }
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 {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ProxyInfo ::= SEQUENCE OF Targets ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ProxyInfo ::= SEQUENCE OF Targets
END END
Appendix C: Changes History Appendix C: Change History
<<This Appendix to be deleted after last call>> <<This Appendix to be deleted after last call>>
This appendix lists major changes since the previous revision. This appendix lists major changes since the previous revision.
Major changes since last revision: Major changes since last revision:
Changes from -02 to -03
1. Many minor editorial changes
2. Changed OID max element arc text in app. A
3. Removed restriction on Clearance SecurityValue syntaxes to allow
support for various existing clearance schemes
4. Finalized alignment with 4th edition of X.509
Changes from -01 to -02 Changes from -01 to -02
1. Re-Synchronized with X.509 DAM 1. Re-Synchronized with X.509 DAM
2. Deleted AC chains concept 2. Deleted AC chains concept
3. Moved AAControls to "optional features" section 3. Moved AAControls to "optional features" section
4. Samples will be a separate draft 4. Samples will be a separate draft
5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459 5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459
mechanisms only mechanisms only
6. Deleted the special wildcard target "ALL" 6. Deleted the special wildcard target "ALL"
Changes from -00 to -01 Changes from -00 to -01
1. Re-structured conformance to profile + options as per Oslo 1. Re-structured conformance to profile + options as per Oslo
consensus consensus
2. Moved acquisition protocol (LAAP)_to separate I-D 2. Moved acquisition protocol (LAAP)_to separate I-D
3. Removed restrictions entirely 3. Removed restrictions entirely
4. Added new AC revocation options 4. Added new AC revocation options
5. Added optional support for use of objectDigestInfo for keys 5. Added optional support for use of objectDigestInfo for keys
6. Added optional support for chains of ACs 6. Added optional support for chains of ACs
7. Changed some syntax: 7. Changed some syntax:
Added UTF8String to IetfAttrSyntax value choice Added UTF8String to IetfAttrSyntax value choice
Split target & proxy extensions, removed owner from proxyInfo Split target & proxy extensions, removed owner from proxyInfo
8. Allocated PKIX OIDs (note: check with repository before using 8. Allocated PKIX OIDs (note: check with repository before using
these, the PKIX arc is currently available at these, the PKIX arc is currently available at
http://www.imc.org/ietf-pkix/pkix-oid.asn) http://www.imc.org/ietf-pkix/pkix-oid.asn)
9. Added compiled ASN.1 module 9. Added compiled ASN.1 module
 End of changes. 233 change blocks. 
639 lines changed or deleted 750 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/