< draft-ietf-pkix-ac509prof-03.txt   draft-ietf-pkix-ac509prof-04.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
May 2000 14 July 2000
An Internet Attribute Certificate An Internet Attribute Certificate
Profile for Authorization Profile for Authorization
<draft-ietf-pkix-ac509prof-03.txt> <draft-ietf-pkix-ac509prof-04.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 2, line 9 skipping to change at page 2, line 9
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...............................................2 Table of Contents...............................................1
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.....................................5 1.3 Document Structure.....................................5
2. Terminology..................................................6 2. Terminology..................................................6
3. Requirements.................................................7 3. Requirements.................................................7
4. Attribute Certificate Profile................................8 4. Attribute Certificate Profile................................8
4.1 X.509 Attribute Certificate Definition.................8 4.1 X.509 Attribute Certificate Definition.................8
4.2 Profile of Standard Fields............................10 4.2 Profile of Standard Fields............................10
4.2.1 Version.........................................10 4.2.1 Version.........................................10
4.2.2 Holder..........................................10 4.2.2 Holder..........................................10
4.2.3 Issuer..........................................11 4.2.3 Issuer..........................................11
4.2.4 Signature.......................................12 4.2.4 Signature.......................................12
4.2.5 Serial Number...................................12 4.2.5 Serial Number...................................12
4.2.6 Validity Period.................................12 4.2.6 Validity Period.................................12
4.2.7 Attributes......................................13 4.2.7 Attributes......................................13
4.2.8 Issuer Unique Identifier........................13 4.2.8 Issuer Unique Identifier........................13
4.2.9 Extensions......................................13 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....................16 4.3.4 Authority Information Access....................16
4.3.5 CRL Distribution Points.........................16 4.3.5 CRL Distribution Points.........................17
4.3.6 No Revocation Available.........................17 4.3.6 No Revocation Available.........................17
4.4 Attribute Types.......................................17 4.4 Attribute Types.......................................17
4.4.1 Service Authentication Information..............18 4.4.1 Service Authentication Information..............18
4.4.2 Access Identity.................................18 4.4.2 Access Identity.................................18
4.4.3 Charging Identity...............................18 4.4.3 Charging Identity...............................19
4.4.4 Group...........................................19 4.4.4 Group...........................................19
4.4.5 Role............................................19 4.4.5 Role............................................19
4.4.6 Clearance.......................................19 4.4.6 Clearance.......................................20
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..................................................31 9. References..................................................31
Author's Addresses.............................................32 Author's Addresses.............................................32
Full Copyright Statement.......................................32 Full Copyright Statement.......................................32
Appendix A: Object Identifiers.................................33 Appendix A: Object Identifiers.................................33
Appendix B: ASN.1 Module.......................................34 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 X.509 public key certificates (PKCs) [X.509-97, X.509-2000,
access to a resource offered by that server. The server must ensure PKIXPROF] bind an identity and a public key. An attribute
that the client is authorized to access that resource. The server certificate (AC) is a structure similar to a PKC; the main
decision is based on the access control policy, the context of the difference being that the AC contains no public key. An AC may
request, and the identity and authorizations of the client. The contain attributes that specify group membership, role, security
access control policy and the context of the request are readily clearance, or other authorization information associated with the AC
available to the server. Certificates may be used to provide holder. The syntax for the AC is defined in Recommendation X.509,
identity and authorization information about the client. making the term "X.509 certificate" ambiguous.
Similar access control decisions are made in other network Some people constantly confuse PKCs and ACs. An analogy may make the
environments, such as a store-and-forward electronic mail distinction clear. A PKC can be considered to be like a passport: it
environment. That is, access control decisions are not limited to identifies the holder, tends to last for a long time, and should not
client-server protocol environments. be trivial to obtain. An AC is more like an entry visa: it is
typically issued by a different authority and does not last for as
long a time. As acquiring an entry visa typically requires
presenting a passport, getting a visa can be a simpler process.
X.509 public key certificates (PKCs) [X.509-97, X.509-DAM, PKIXPROF] Authorization information may be placed in a PKC extension or placed
bind an identity and a public key. The identity may be used to in a separate attribute certificate (AC). The placement of
support identity-based access control decisions after the client authorization information in PKCs is usually undesirable for two
proves that it has access to the private key that corresponds to the reasons. First, authorization information often does not have the
public key contained in the PKC. The public key is used to validate same lifetime as the binding of the identity and the public key.
digital signatures or cryptographic key management operations. When authorization information is placed in a PKC extension, the
However, not all access control decisions are identity-based. Rule- general result is the shortening of the PKC useful lifetime. Second,
based, role-based, and rank-based access control decisions require the PKC issuer is not usually authoritative for the authorization
additional information. For example, information about a client's information. This results in additional steps for the PKC issuer to
ability to pay for a resource access may be more important than the obtain authorization information from the authoritative source.
client's identity. Authorization information to support such access
control decisions may be placed in a PKC extension or placed in a
separate attribute certificate (AC).
The placement of authorization information in PKCs is usually For these reasons, it is often better to separate authorization
undesirable for two reasons. First, authorization information often information from the PKC. Yet, authorization information also needs
does not have the same lifetime as the binding of the identity and to be bound to an identity. An AC provides this binding; it is
the public key. When authorization information is placed in a PKC simply a digitally signed (or certified) identity and set of
extension, the general result is the shortening of the PKC useful attributes.
lifetime. Second, the PKC issuer is not usually authoritative for
the authorization information. This results in additional steps for
the PKC issuer to obtain authorization information from the
authoritative source.
For these reasons, it is often better to separate this authorization An AC may be used with various security services, including access
information from the PKC. Yet, this authorization information also control, data origin authentication, and non-repudiation.
needs to be protected in a fashion similar to a PKC. An AC provides
this protection; it is simply a digitally signed (or certified) set
of attributes.
An AC is a structure similar to a PKC; the main difference being PKCs can provide an identity to access control decision functions.
that the AC contains no public key. An AC may contain attributes However, in many contexts the identity is not the criterion that is
that specify group membership, role, security clearance, or other used for access control decisions, rather the role or group-
access control information associated with the AC holder. The syntax membership of the accessor is the criterion used. Such access
for the AC is defined in Recommendation X.509, making the term control schemes are called role-based access control.
"X.509 certificate" ambiguous. This document specifies a profile of
the X.509 AC suitable for use with authorization information within
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. One way in which the
in which the linkage between the request and the AC can be achieved linkage between the request or identity and the AC can be achieved
is if the AC has a reference to a PKC for the requester and that PKC is the inclusion of a reference to a PKC within the AC and the use
has been used to authenticate the access request. of the private key corresponding to the PKC for authentication
within the access request.
Some people constantly confuse PKCs and ACs. An analogy may make the ACs may also be used in the context of a data origin authentication
distinction clear. A PKC can be considered to be like a passport: it service and a non-repudiation service. In these contexts, the
identifies the holder, tends to last for a long time, and should not attributes contained in the AC provide additional information about
be trivial to obtain. An AC is more like an entry visa: it is the signing entity. This information can be used to make sure that
typically issued by a different authority and does not last for as the entity is authorized to sign the data. This kind of checking
long a time. As acquiring an entry visa typically requires depends either on the context in which the data is exchanged or on
presenting a passport, getting a visa can be a simpler process. the data that has been digitally signed.
1.1 Delegation and AC chains 1.1 Delegation and AC chains
The X.509 standard [X.509-DAM] defines authorization as the The X.509 standard [X.509-2000] defines authorization as the
"conveyance of privilege from one entity that holds such privilege, "conveyance of privilege from one entity that holds such privilege,
to another entity". An AC is one authorization mechanism. to another entity". An AC is one authorization mechanism.
An ordered sequence of ACs could be used to verify the authenticity An ordered sequence of ACs could be used to verify the authenticity
of a privilege asserter's privilege. In this way, chains or paths of of a privilege asserter's privilege. In this way, chains or paths of
ACs could be employed to delegate authorization. ACs could be employed to delegate authorization.
As the administration and processing associated with such AC chains Since the administration and processing associated with such AC
is more complex than use of one AC issued by a single authority, and chains is complex and the use of ACs in the Internet today is quite
as the use of ACs in the Internet today is quite limited, this limited, this specification does NOT RECOMMEND the use of AC chains.
specification does NOT RECOMMEND the use of AC chains. Other Other (future) specifications may address the use of AC chains. This
(future) specifications may address the use of AC chains. specification deals with the simple cases where one authority issues
all of the ACs for a particular set of attributes. However, this
simplification does not preclude the use of several different
authorities, each of which manages a different set of attributes.
For example, group membership may be included in one AC issued by
one authority, and security clearance may be included in another AC
issued by another authority.
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 process a single AC at a time. Processing of more than one
validation of that AC MAY require validation of a chain of PKCs, as AC, one after another, may be necessary. Note however, that
validation of an 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, for example, access control decision
However, there are a number of possible communication paths for ACs. functions. However, there are a number of possible communication
paths for ACs.
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 and that the AC verifier is
only presented with what it "needs to know." In inter-domain cases
where the client's rights should be assigned within client's "home"
domain, the "push" model is especially suitable.
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 or "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 to the client-server protocol. It is also more the client or to the client-server protocol. The "pull" model is
suitable for some inter-domain cases where the client's rights especially suitable for inter-domain cases where the client's rights
should be assigned within the server's domain, rather than within should be assigned within the server's domain, rather than within
the client's domain. the client's domain.
There are a number of possible exchanges involving three entities: There are a number of possible exchanges involving three entities:
the client, the server, and the AC issuer. In addition, a directory the client, the server, and the AC issuer. In addition, a directory
service or other repository for AC retrieval MAY be supported. service or other repository for AC retrieval MAY 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 a protocol for these exchanges.
+--------------+ +--------------+
| | Server Acquisition | | Server Acquisition
| AC issuer +----------------------------+ | AC issuer +----------------------------+
| | | | | |
+--+-----------+ | +--+-----------+ |
| | | |
| Client | | Client |
| Acquisition | | Acquisition |
| | | |
skipping to change at page 7, line 12 skipping to change at page 7, line 12
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 AC profile meets the following requirements. This AC profile meets the following requirements.
Time/Validity requirements: Time/Validity requirements:
1. Support for short-lived as well as long-lived ACs is required. 1. Support for short-lived as well as long-lived ACs is required.
Typical validity periods might be measured in hours, as opposed Typical short-lived validity periods might be measured in
to months for PKCs. Short validity periods allow ACs to be hours, as opposed to months for PKCs. Short validity periods
useful without a revocation mechanism. allow ACs to be useful without a revocation 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. examples include "access identity", contained within ACs. Examples include "access identity",
"group", "role", "clearance", "audit identity", and "charging "group", "role", "clearance", "audit identity", and "charging
id". id".
4. Standard attribute types should be defined in a manner that 4. Standard attribute types should be defined in a manner that
permits an AC verifier to distinguish between uses of the same permits an AC verifier to distinguish between uses of the same
attribute in different domains. For example, the 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 should be easily "Administrators group" as defined by SPYRUS should be easily
distinguished. distinguished.
Targeting of ACs: Targeting of ACs:
5. It should be possible to "target" an AC at one, or a small 5. It should be possible to "target" an AC at one, or a small
number of, servers. This means that a trustworthy non-target number of, servers. This means that a trustworthy non-target
server will reject the AC for authorization decisions. server will reject 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, including an online AC
issuer). issuer.
4. Attribute Certificate Profile 4. Attribute Certificate Profile
ACs may be used in a wide range of applications and environments ACs may be used in a wide range of applications and environments
covering a broad spectrum of interoperability goals and a broader covering a broad spectrum of interoperability goals and a broader
spectrum of operational and assurance requirements. The goal of spectrum of operational and assurance requirements. The goal of
this document is to establish a common baseline for generic this document is to establish a common baseline for generic
applications requiring broad interoperability and limited special applications requiring broad interoperability and limited special
purpose requirements. In particular, the emphasis will be on purpose requirements. In particular, the emphasis will be on
supporting the use of attribute certificates for informal Internet supporting the use of attribute certificates for informal Internet
electronic mail, IPSec, and WWW applications. electronic mail, IPSec, and WWW applications.
This section presents a profile for ACs that will foster This section presents a profile for ACs that will foster
interoperability. This section also defines some private extensions interoperability. This section also defines some private 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; this document uses the 1988 ASN.1 syntax, as has been done ASN.1; this document uses the 1988 ASN.1 syntax, as has been done
for PKCs [PKIXPROF]. However, the encoded certificate and standard for PKCs [PKIXPROF]. The encoded certificates and extensions from
extensions are equivalent. either ASN.1 version are bit-wise identical.
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
skipping to change at page 10, line 16 skipping to change at page 10, line 16
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 DEFINED BY AttributeType
Implementers should note that the DER encoding (DER is defined in Implementers should note that the DER encoding (see [X.509-
[X.208-88]) of the SET OF values requires ordering of the encodings 88],[X.208-88]) of the SET OF values requires ordering of the
of the values. Though this issue arises with respect to encodings 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 (except as For all GeneralName fields in this profile the otherName (except as
noted below), x400Address, ediPartyName and registeredID options noted below), x400Address, ediPartyName and registeredID options
MUST NOT be used. The use of Kerberos [KRB] format names, encoded MUST NOT be used. The use of Kerberos [KRB] principal names,
into the otherName, SHOULD however, be supported using the encoded into the otherName, SHOULD however, be supported using the
krb5PrincipalName OID and the KerberosName syntax as defined in krb5PrincipalName OID and the KerberosName syntax as defined in
[PKINIT]. [PKINIT].
Conforming implementations MUST be able to support the dNSName, Conforming implementations MUST be able to support the dNSName,
directoryName, uniformResourceIdentifier, and iPAddress fields in directoryName, uniformResourceIdentifier, and iPAddress fields in
all cases where GeneralName is used. This is compatible with the all cases where GeneralName is used. This is compatible with the
GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7). GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7).
4.2.1 Version 4.2.1 Version
The version field MUST be the default value of v1. That is, the The version field MUST be the default value of v1. That is, the
version field is not present in the DER encoding, except when the version field is not present in the DER encoding, except when the
holder is identified using the optional objectDigestInfo field, as holder is identified using the optional objectDigestInfo field, as
specified in section 7.3. 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 PKC, the holder field SHOULD use the baseCertificateID. of an X.509 PKC, the holder field SHOULD 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 AC 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. If both the holder.baseCertificateID.issuerUID and the field. If both the AC holder.baseCertificateID.issuerUID and the PKC
issuerUniqueID fields are present, then the same value MUST be issuerUniqueID fields are present, then the same value MUST be
present in both _fields. Thus, the baseCertificateID is only usable present in both fields. Thus, the baseCertificateID is only usable
with PKC profiles (like [PKIXPROF]) which mandate that the PKC with PKC profiles (like [PKIXPROF]) which mandate that the PKC
issuer field contain a non-empty distinguished name value. issuer field contain a non-empty distinguished name value.
Note: An empty distinguished name is a distinguished name where the Note: An empty distinguished name is a distinguished name where the
SEQUENCE OF relative distinguished names is of zero length. In a DER SEQUENCE OF relative distinguished names is of zero length. In a 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. If the PKC subject field contains an an empty distinguished name. If the PKC subject field contains an
empty distinguished name, then the entityName field MUST be empty distinguished name, then the entityName field MUST be
identical to one of the values of the PKC subjectAltName field 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 an empty distinguished extension be present if the PKC subject is an empty distinguished
name. name. See the security consideration section which mentions some
name collision problems that may arise when using the entityName
option.
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 defined 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 v1Form choice, which ACs conforming to this profile MUST use the v1Form choice, which
MUST contain one and only one GeneralName, which MUST contain a non- MUST contain one and only one GeneralName, which MUST contain a non-
empty distinguished name in the directoryName field. This means that empty distinguished name in the directoryName field. This means that
all AC issuers MUST have non-empty distinguished names. all AC issuers MUST have non-empty distinguished names.
Part of the reason for the use of the v1Form field is that it allows Part of the reason for the use of the v1Form field is that it means
the AC verifier to be independent of the AC issuer's public key that the AC issuer does not have to know which PKC the AC verifier
infrastructure. Using the baseCertificateID field to reference the will use for it (the AC issuer). Using the baseCertificateID field
AC issuer would mean that the AC verifier would have such a to reference the AC issuer would mean that the AC verifier would
dependency. have to trust the PKC that the AC issuer chose (for itself) at AC
creation time.
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 or [ECDSA] section 3.2: md5WithRSAEncryption, id-dsa- section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha-
with-sha1, sha-1WithRSAEncryption, or ecdsa-with-SHA1. 1WithRSAEncryption..
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. unique combination, even if ACs are very short-lived.
AC issuers MUST force the serialNumber to be a positive integer, AC issuers MUST force the serialNumber to be a positive integer,
skipping to change at page 12, line 34 skipping to change at page 12, line 34
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 4 octets. Conformant ACs MUST handle serialNumber values longer than 4 octets. Conformant ACs MUST
NOT contain 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. Each AC issuer MUST ensure be monotonically increasing with time. Each AC issuer MUST ensure
that each AC that it issues contain a unique serial number. 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 certifies that the binding between
holder and the attributes fields will be valid. the 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. The GeneralizedTime for variable precision representation of time. The GeneralizedTime
field can optionally include a representation of the time field can optionally include a representation of the time
differential between the local time zone 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 in Coordinated universal time (UTC) (also known as
times are YYYYMMDDHHMMSSZ), even where the number of seconds is Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times
zero. GeneralizedTime values MUST NOT include fractional seconds. are YYYYMMDDHHMMSSZ), even when the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
(Note: this is the same as specified in [PKIXPROF], section (Note: this is the same as specified in [PKIXPROF], section
4.1.2.5.2.) 4.1.2.5.2.)
AC users MUST be able to handle an AC which, at the time of AC users MUST be able to handle an AC which, at the time of
processing, has its entire validity period in the future (a post- processing, has parts of its validity period or all its validity
dated AC). This is valid for some applications, such as backup. period in the past or in the future (a post-dated AC). This is valid
for some applications, such as 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 MAY contain a SET OF values. For a given AC, each
AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That
skipping to change at page 13, line 39 skipping to change at page 13, line 41
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.
An AC that has no extensions conforms to the profile; however, An AC that has no extensions conforms to the profile; however,
section 4.3 defines the extensions that MAY be used with this section 4.3 defines the extensions that MAY be used with this
profile. If any other critical extension is used, then the AC does profile, and whether or not they may be marked criticial. If any
not conform to this profile. However, if any other non-critical other critical extension is used, then the AC does not conform to
extension is used, then the AC does conform to this profile. this profile. However, if any other non-critical 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 ACs Section 4.3 presents recommended extensions used within Internet ACs
and standard locations for information. Communities may elect to and standard locations for information. Communities may elect to
skipping to change at page 14, line 35 skipping to change at page 14, line 37
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 determine detected. This means that the AC issuer MUST be able to determine
the actual identity of the AC holder from the audit identity. the actual identity of the AC holder from the audit identity.
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 with however, this method doesn't allow tracking the same AC holder with
multiple ACs. Thus, an audit identity is only useful if it lasts for multiple ACs. Thus, an audit identity is only useful if it lasts for
longer than the typical AC lifetime. Auditing could also be based on longer than the typical AC lifetime. Auditing could also be based on
the AC holder's PKC issuer/serial; however, this will often allow the AC holder's PKC issuer/serial; however, this will often allow
the server/service administrator identify the AC holder. the server/service administrator to identify the AC holder.
As the AC verifier might otherwise use the AC holder 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 do not contain identifying that the ensuing audit trails do not contain identifying
information. information.
skipping to change at page 15, line 8 skipping to change at page 15, line 8
value of an audit identity MUST NOT be longer than 20 octets. 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
To target an AC , the target information extension, imported from To target an AC , the target information extension, imported from
[X.509-DAM], MAY be used to specify a number of servers/services. [X.509-2000], MAY be used to specify a number of servers/services.
The 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 If this extension is not present, then the AC is not targeted and
may 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.
skipping to change at page 15, line 35 skipping to change at page 15, line 35
targetGroup [1] GeneralName, targetGroup [1] GeneralName,
targetCert [2] TargetCert targetCert [2] TargetCert
} }
TargetCert ::= SEQUENCE { TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial, targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL, targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL certDigestInfo ObjectDigestInfo OPTIONAL
} }
The targetCert CHOICE is only present to allow future compatibility The targetCert CHOICE within the Target structure is only present to
with [X.509-DAM] and MUST NOT be used. allow future compatibility with [X.509-2000] 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 SEQUENCE, or if the current the targetName fields in the Targets SEQUENCE, or if the current
server is a member of one of the targetGroup fields in the Targets server is a member of one of the targetGroup fields in the Targets
SEQUENCE. In this case, the current server is said to "match" the SEQUENCE. In this case, the current server is said to "match" the
targeting 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 targetGroups to which it belongs or can otherwise names of the targetGroups to which it belongs or can otherwise
determine its membership. For example, the targetGroup specifies a determine its membership. For example, the targetGroup specifies 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. For another example, the targetGroup specifies "PRINTERS," belongs. For another example, the targetGroup specifies "PRINTERS,"
and the AC verifier knows whether or not it is a printer or print and the AC verifier knows whether or not it is a printer or print
server. server.
Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
Targets". Conforming AC issuer implementations MUST only produce one
"Targets" element. Confirming AC users MUST be able to accept a
"SEQUENCE OF Targets". If more than one Targets element is found in
an AC, then the extension MUST be treated as if all Target elements
had been found within one Targets element.
name id-ce-targetInformation name id-ce-targetInformation
OID { id-ce 55 } OID { id-ce 55 }
syntax Targets syntax SEQUENCE OF 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
skipping to change at page 16, line 28 skipping to change at page 16, line 35
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. Support for the id-ad-caIssuers accessMethod is status of the AC. Support for the id-ad-caIssuers accessMethod is
NOT REQUIRED by this profile since AC chains are not expected. The NOT REQUIRED by this profile since AC chains are not expected.
authorityInformationAccess extension is only used to support
revocation status checking, therefore conformant ACs containing this
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, and theURI MUST contain an The accessLocation MUST contain a URI, and theURI MUST contain an
HTTP URL [URL] that specifies the location of an OCSP responder. The HTTP URL [URL] that specifies the location of an OCSP responder. The
AC issuer MUST, of course, maintain an OCSP responder at this AC issuer MUST, of course, maintain an OCSP responder at this
skipping to change at page 17, line 15 skipping to change at page 17, line 25
MUST contain either a distinguished name or a URI. The URI MUST be MUST contain either a distinguished name or a URI. The URI MUST be
either an HTTP URL or an LDAP URL [URL]. 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
The noRevAvail extension, defined in [X.509-DAM], allows an AC The noRevAvail extension, defined in [X.509-2000], allows an AC
issuer to indicate that no revocation information will be made issuer to indicate that no revocation information will be made
available for this AC. available for this AC.
This extension MUST be non-critical. An AC verifier that does not This extension MUST be non-critical. An AC verifier that does not
understand this extension might be able to find a revocation list understand this extension might be able to find a revocation list
from the AC issuer, but the revocation list will never include an from the AC issuer, but the revocation list will never include an
entry for the AC. entry for the AC.
name id-ce-noRevAvail name id-ce-noRevAvail
OID { id-ce 56 } OID { id-ce 56 }
skipping to change at page 18, line 18 skipping to change at page 18, line 27
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
The SvceAuthInfo attribute identifies the AC holder to the The SvceAuthInfo attribute identifies the AC holder to the
server/service by a name, and the attribute MAY include optional server/service by a name, and the attribute MAY include optional
service specific authentication information. Typically this will service specific authentication information. Typically this will
contain a username/password pair for a "legacy" application. contain a username/password pair for a "legacy" application.
This attribute is intended to be used to provide information that
can be presented by the AC verifier to be interpreted and
authenticated by a separate application within the target system.
Note that this is a different use to that intended for the
accessIdentity attribute in 4.4.2 below.
This attribute type will typically be encrypted when the authInfo This attribute type will typically be encrypted when the authInfo
field contains sensitive information, such as 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
The accessIdentity attribute identifies the AC holder to the The accessIdentity attribute identifies the AC holder to the
server/service. For this attribute the authInfo field MUST NOT be server/service. For this attribute the authInfo field MUST NOT be
present. present.
This attribute is intended to be used to provide information about
the AC holder, that can be used by the AC verifier (or a larger
system of which the AC verifier is a component) to authorize the
actions of the AC holder within the AC verifier's system. Note that
this is a different use to that intended for the svceAuthInfo
attribute described in 4.4.1 above.
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
The chargingIdentity attribute identifies the AC holder for charging The chargingIdentity attribute identifies the AC holder for charging
purposes. 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, the holder's company other identities of the holder. For example, the holder's company
skipping to change at page 19, line 18 skipping to change at page 19, line 38
the AC 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
The role attribute, specified in [X.509-DAM], carries information The role attribute, specified in [X.509-2000], carries information
about 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 MAY be used to specify the issuing authority
present, and roleName MUST use the uniformResourceIdentifier CHOICE for the role specification certificate. There is no requirement that
of the GeneralName. a role specification certificate necessarily exists for the
roleAuthority. This differs from [X.500-2000], where the
roleAuthority field is assumed to name the issuer of a role
specification certificate. For example, to distinguish the
administrator role as defined by "Baltimore" from that defined by
"Spyrus", one could put the value "administrator" in the roleName
field and the value "Baltimore" or "Spyrus" in the roleAuthority
field.
The roleName field MUST be present, and roleName MUST use the
uniformResourceIdentifier CHOICE of the GeneralName.
name id-at-role name id-at-role
OID { id-at 72 } OID { id-at 72 }
syntax RoleSyntax syntax RoleSyntax
values: Multiple allowed values: Multiple allowed
4.4.6 Clearance 4.4.6 Clearance
The clearance attribute, specified in [X.501-93], carries clearance The clearance attribute, specified in [X.501-93], carries clearance
(associated with security labeling) information about the AC holder. (associated with security labeling) information about the AC holder.
skipping to change at page 22, line 22 skipping to change at page 22, line 22
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 PKC certification path MUST be verified in issuer's entire PKC certification path 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 timelyand this notBeforeTime or notAfterTime, then the AC is timely and 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 as specified in section 4.3.2. 5. The AC targeting check MUST pass as specified in section 4.3.2.
6. If the AC contains a critical extension that is not listed in 6. If the AC contains an unsupported critical extension, then the
section 4.3, then the AC MUST be rejected. AC MUST be rejected.
Support for an extension in this context means: Support for an extension in this context means:
1. The AC verifier MUST be able to parse the extension value. 1. The AC verifier MUST be able to parse the extension value.
2. Where the extension value SHOULD cause the AC to be rejected, 2. Where the extension value SHOULD cause the AC to be rejected,
the 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 attributes. 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. For example, an AC verifier might be configured information. For example, an AC verifier might be
skipping to change at page 23, line 48 skipping to change at page 23, line 48
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, An AC verifier MAY use any source for AC revocation status
authorityInformationAccess or crlDistributionPoints extensions. That
is, the crlDistributionPoints, authorityInformationAccess and
noRevAvail extensions are mutually exclusive for a single AC, and
one AC MUST NOT contain more than one of these extensions. This
differs from PKCs, which permit both authorityInformationAccess and
crlDistributionPoints extensions within one PKC.
An AC verifier MAY any use source for AC revocation status
information. 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 profile 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 however, if these features are offered, they MUST be offered as
described below. described below.
7.1 Attribute Encryption 7.1 Attribute Encryption
skipping to change at page 24, line 34 skipping to change at page 24, line 34
This type of attribute encryption is targeted. Before the AC is This type of attribute encryption is targeted. Before the AC is
signed, the attributes are encrypted for a set of predetermined signed, the attributes are encrypted for a set of predetermined
recipients. recipients.
The AC then contains the ciphertext inside its signed data. The The AC then contains the ciphertext inside its signed data. The
EenvelopedData (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 ciphertext is included in the AC as the value of an encAttrs The ciphertext is included in the AC as the value of an encAttrs
attribute. Only one encAttrs attribute can be present in an AC; attribute. Only one encAttrs attribute can be present in an AC;
however, the encAttrs attribue MAY be multi-valued, and each of its however, the encAttrs attribute MAY be multi-valued, and each of its
values will contain an independent 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 predetermined 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,
skipping to change at page 26, line 40 skipping to change at page 26, line 40
When 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 10 }
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.
skipping to change at page 27, line 16 skipping to change at page 27, line 16
with an executable object such as a Java class. However, this with an executable object such as a Java class. However, this
profile only specifies how to use a hash over a public key or PKC. 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 That is, conformant ACs MUST NOT use the otherObjectTypes value for
the digestedObjectType. the digestedObjectType.
To link an AC to a public key, the hash must be calculated over the To link an AC to a public key, the hash must be calculated over the
representation of that public key which would be present in a PKC, representation of that public key which would be present in a PKC,
specifically, the input for the hash algorithm MUST be the DER specifically, the input for the hash algorithm MUST be the DER
encoding of a SubjectPublicKeyInfo representation of the key. Note: encoding of a SubjectPublicKeyInfo representation of the key. Note:
This includes the AlgorithmIdentifier as well as the BIT STRING. The This includes the AlgorithmIdentifier as well as the BIT STRING. The
rules given in [PKIXPROF] and [ECDSA] for encoding keys MUST be rules given in [PKIXPROF] for encoding keys MUST be followed. In
followed. In this case the digestedObjectType MUST be publicKey and this case the digestedObjectType MUST be publicKey and the
the otherObjectTypeID field MUST NOT be present. 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 DSA Dss-parms are inherited as described hashed. This can occur if DSA Dss-parms are inherited as described
in section 7.3.3 of [PKIXPROF]. The correct input for hashing in in section 7.3.3 of [PKIXPROF]. The correct input for hashing in
this context will include the value of the parameters inherited from this context will include the value of the parameters inherited from
the CA's PKC, and thus may differ from the SubjectPublicKeyInfo the CA's PKC, and thus may differ from the 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 public keys for the algorithms specified in the representations of public keys for the algorithms specified in
section 7.3 of [PKIXPROF] and those specified in [ECDSA]. In this section 7.3 of [PKIXPROF]. In this case the digestedObjectType MUST
case the digestedObjectType MUST be publicKey and the be publicKey and the otherObjectTypeID field 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, including the calculated over the DER encoding of the entire PKC, including the
signature value. 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
skipping to change at page 29, line 12 skipping to change at page 29, line 12
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 The protection afforded private keys is a critical factor in
maintaining security. Failure of AC issuers to protect their maintaining security. Failure of AC issuers to protect their
private keys will permit an attacker to masquerade as them, private keys will permit an attacker to masquerade as them,
potentially generating false ACs or revocation status. Existence of potentially generating false ACs or revocation status. Existence of
bogus ACs and revocation status will undermine confidence in the bogus ACs and revocation status will undermine confidence in the
system. If the compromise is detected, all ACs issued to the AC system. If the compromise is detected, all ACs issued by the AC
issuer MUST be revoked. Rebuilding after such a compromise will be issuer MUST be revoked. Rebuilding after such a compromise will be
problematic, so AC issuers are advised to implement a combination of problematic, so AC issuers are advised to implement a combination of
strong technical measures (e.g., tamper-resistant cryptographic strong technical measures (e.g., tamper-resistant cryptographic
modules) and appropriate management procedures (e.g., separation of modules) and appropriate management procedures (e.g., separation of
duties) to avoid such an incident. duties) to avoid such an incident.
Loss of a AC issuer's private signing key may also be problematic. Loss of an AC issuer's private signing key may also be problematic.
The AC issuer would not be able to produce revocation status or The AC issuer would not be able to produce revocation status or
perform AC renewal. AC issuer's are advised to maintain secure perform AC renewal. AC issuers are advised to maintain secure backup
backup for signing keys. The security of the key backup procedures for signing keys. The security of the key backup procedures is a
is a critical factor in avoiding key compromise. critical factor in avoiding key compromise.
The availability and freshness of revocation status will affect the The availability and freshness of revocation status will affect the
degree of assurance that should be placed in a long-lived AC. While degree of assurance that should be placed in a long-lived AC. While
long-lived ACs expire naturally, events may occur during its natural long-lived ACs expire naturally, events may occur during its natural
lifetime which negate the binding between the AC holder and the lifetime which negate the binding between the AC holder and the
attributes. If revocation status is untimely or unavailable, the attributes. If revocation status is untimely or unavailable, the
assurance associated with the binding is clearly reduced. assurance associated with the binding is clearly reduced.
The binding between an AC holder and attributes cannot be stronger The binding between an AC holder and attributes cannot be stronger
than the cryptographic module implementation and algorithms used to than the cryptographic module implementation and algorithms used to
generate the signature. Short key lengths or weak hash algorithms generate the signature. Short key lengths or weak hash algorithms
will limit the utility of an AC. AC issuers are encouraged to note will limit the utility of an AC. AC issuers are encouraged to note
advances in cryptology so they can employ strong cryptographic advances in cryptology so they can employ strong cryptographic
techniques. techniques.
Inconsistent application of name comparison rules may result in Inconsistent application of name comparison rules may result in
acceptance of invalid targeted or proxied AC, or rejection of valid acceptance of invalid targeted or proxied ACs, or rejection of valid
ones. The X.500 series of specifications defines rules for ones. The X.500 series of specifications defines rules for
comparing distinguished names. These rules require comparison of comparing distinguished names. These rules require comparison of
strings without regard to case, character set, multi-character white strings without regard to case, character set, multi-character white
space substrings, or leading and trailing white space. This space substrings, or leading and trailing white space. This
specification and [PKIXPROF] relaxes these requirements, requiring specification and [PKIXPROF] relaxes these requirements, requiring
support for binary comparison at a minimum. support for binary comparison at a minimum.
AC issuers MUST encode the distinguished name in the AC AC issuers MUST encode the distinguished name in the AC
holder.entityName field identically to the distinguished name in the holder.entityName field identically to the distinguished name in the
holder's PKC. If different encodings are used, implementations of holder's PKC. If different encodings are used, implementations of
this specification may fail to recognize that the AC and PKC belong this specification may fail to recognize that the AC and PKC belong
to the same entity. 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, AC verifiers MUST be provided with this information by implement, AC verifiers MUST be provided with this information by
other means. Configuration information is a likely alternative other means. Configuration information is a likely alternative
means. This becomes very important if an AC verified trusts more means. This becomes very important if an AC verifier trusts more
than one AC 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 security protocol (e.g. TLS, S/MIME) and supplied by a particular security protocol (e.g. TLS, S/MIME) and
the AC holder's identity. If the authentication uses PKCs, then this the AC holder's identity. If the authentication uses PKCs, then this
mapping is straightforward. However, it is envisaged that ACs will mapping is straightforward. However, it is envisaged that ACs will
also be used in environments where the holder may be authenticated also be used in environments where the holder may be authenticated
using other means. Implementers SHOULD be very careful in mapping using other means. Implementers SHOULD be very careful in mapping
the 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", RFC2797.
[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.
[ECDSA] D. Johnson, W. Polk, "Internet X.509 Public Key
Infrastructure Representation of Elliptic Curve Digital
Signature Algorithm (ECDSA) Keys and Signatures in
Internet X.509 Public Key Infrastructure Certificates"
draft-ietf-pkix-ipki-ecdsa-02.txt, October 1999.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC2634. 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 [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol
(v3)", RFC 2251. (v3)", RFC 2251.
[OCSP] Myers, M., et al., " X.509 Internet Public Key [OCSP] Myers, M., et al., " X.509 Internet Public Key
Infrastructure - Online Certificate Status Protocol - Infrastructure - Online Certificate Status Protocol -
OCSP", RFC 2560. 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-11.txt, work-in-progress.
[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.
[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.
[URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform
Resource Locators (URL)", RFC 1738. Resource Locators (URL)", RFC 1738.
[X.208-88] CCITT Recommendation X.208: Specification of Abstract [X.208-88] CCITT Recommendation X.208: Specification of Abstract
skipping to change at page 31, line 53 skipping to change at page 31, line 48
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 - [X.501-93] ITU-T Recommendation X.501 : Information Technology -
Open Systems Interconnection - The Directory: Models, Open Systems Interconnection - The Directory: Models,
1993. 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-2000]ITU-T Recommendation X.509: The Directory - Public-Key
Interconnection - The Directory: Authentication and Attribute Certificate Frameworks. 2000
Framework - Draft Amendment 1: Certificate Extensions,
October 1999.
Author's Addresses Author's Addresses
Stephen Farrell Stephen Farrell
Baltimore Technologies Baltimore Technologies
61/62 Fitzwilliam Lane 61/62 Fitzwilliam Lane
Dublin 2 Dublin 2
IRELAND IRELAND
tel: +353-1-647-3000 tel: +353-1-647-3000
skipping to change at page 33, line 38 skipping to change at page 33, line 38
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 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-proxying OBJECT IDENTIFIER ::= { id-pe 7 } id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 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 }
skipping to change at page 34, line 34 skipping to change at page 34, line 34
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, id-ce 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-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 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 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 }
skipping to change at page 38, line 4 skipping to change at line 1780
ACClearAttrs ::= SEQUENCE { ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName, acIssuer GeneralName,
acSerial INTEGER, acSerial INTEGER,
attrs SEQUENCE OF Attribute attrs SEQUENCE OF Attribute
} }
ProxyInfo ::= SEQUENCE OF Targets ProxyInfo ::= SEQUENCE OF Targets
END END
Appendix C: Change History
<<This Appendix to be deleted after last call>>
This appendix lists major changes since the previous 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
1. Re-Synchronized with X.509 DAM
2. Deleted AC chains concept
3. Moved AAControls to "optional features" section
4. Samples will be a separate draft
5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459
mechanisms only
6. Deleted the special wildcard target "ALL"
Changes from -00 to -01
1. Re-structured conformance to profile + options as per Oslo
consensus
2. Moved acquisition protocol (LAAP)_to separate I-D
3. Removed restrictions entirely
4. Added new AC revocation options
5. Added optional support for use of objectDigestInfo for keys
6. Added optional support for chains of ACs
7. Changed some syntax:
Added UTF8String to IetfAttrSyntax value choice
Split target & proxy extensions, removed owner from proxyInfo
8. Allocated PKIX OIDs (note: check with repository before using
these, the PKIX arc is currently available at
http://www.imc.org/ietf-pkix/pkix-oid.asn)
9. Added compiled ASN.1 module
 End of changes. 74 change blocks. 
181 lines changed or deleted 193 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/