summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5755.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5755.txt')
-rw-r--r--doc/rfc/rfc5755.txt2803
1 files changed, 2803 insertions, 0 deletions
diff --git a/doc/rfc/rfc5755.txt b/doc/rfc/rfc5755.txt
new file mode 100644
index 0000000..54087b0
--- /dev/null
+++ b/doc/rfc/rfc5755.txt
@@ -0,0 +1,2803 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Farrell
+Request for Comments: 5755 Trinity College Dublin
+Obsoletes: 3281 R. Housley
+Category: Standards Track Vigil Security
+ISSN: 2070-1721 S. Turner
+ IECA
+ January 2010
+
+
+ An Internet Attribute Certificate Profile for Authorization
+
+Abstract
+
+ This specification defines a profile for the use of X.509 Attribute
+ Certificates in Internet Protocols. Attribute certificates may be
+ used in a wide range of applications and environments covering a
+ broad spectrum of interoperability goals and a broader spectrum of
+ operational and assurance requirements. The goal of this document is
+ to establish a common baseline for generic applications requiring
+ broad interoperability as well as limited special purpose
+ requirements. The profile places emphasis on attribute certificate
+ support for Internet electronic mail, IPsec, and WWW security
+ applications. This document obsoletes RFC 3281.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further
+ information on Internet Standards is available in Section 2 of
+ RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5755.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 1]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 2]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Requirements Terminology ...................................5
+ 1.2. AC Path Delegation .........................................5
+ 1.3. Attribute Certificate Distribution ("Push" vs. "Pull") .....6
+ 1.4. Document Structure .........................................7
+ 2. Terminology .....................................................7
+ 3. Requirements ....................................................8
+ 4. Attribute Certificate Profile ...................................9
+ 4.1. X.509 Attribute Certificate Definition ....................10
+ 4.2. Profile of Standard Fields ................................12
+ 4.2.1. Version ............................................13
+ 4.2.2. Holder .............................................13
+ 4.2.3. Issuer .............................................14
+ 4.2.4. Signature ..........................................14
+ 4.2.5. Serial Number ......................................14
+ 4.2.6. Validity Period ....................................15
+ 4.2.7. Attributes .........................................15
+ 4.2.8. Issuer Unique Identifier ...........................16
+ 4.2.9. Extensions .........................................16
+ 4.3. Extensions ................................................17
+ 4.3.1. Audit Identity .....................................17
+ 4.3.2. AC Targeting .......................................18
+ 4.3.3. Authority Key Identifier ...........................19
+ 4.3.4. Authority Information Access .......................19
+ 4.3.5. CRL Distribution Points ............................20
+ 4.3.6. No Revocation Available ............................20
+ 4.4. Attribute Types ...........................................21
+ 4.4.1. Service Authentication Information .................21
+ 4.4.2. Access Identity ....................................22
+ 4.4.3. Charging Identity ..................................23
+ 4.4.4. Group ..............................................23
+ 4.4.5. Role ...............................................23
+ 4.4.6. Clearance ..........................................24
+ 4.5. Profile of AC Issuer's PKC ................................26
+ 5. Attribute Certificate Validation ...............................27
+ 6. Revocation .....................................................28
+ 7. Optional Features ..............................................29
+ 7.1. Attribute Encryption ......................................29
+ 7.2. Proxying ..................................................31
+ 7.3. Use of ObjectDigestInfo ...................................32
+ 7.4. AA Controls ...............................................33
+ 8. Security Considerations ........................................35
+ 9. IANA Considerations ............................................36
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 3]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ 10. References ....................................................37
+ 10.1. Reference Conventions ....................................37
+ 10.2. Normative References .....................................37
+ 10.3. Informative References ...................................38
+ Appendix A. Object Identifiers ....................................40
+ Appendix B. ASN.1 Module ..........................................41
+ Appendix C. Errata Report Submitted to RFC 3281 ...................47
+ Appendix D. Changes since RFC 3281 ................................48
+
+1. Introduction
+
+ X.509 public key certificates (PKCs) [X.509-1997] [X.509-2000]
+ [PKIXPROF] bind an identity and a public key. An attribute
+ certificate (AC) is a structure similar to a PKC; the main difference
+ being that the AC contains no public key. An AC may contain
+ attributes that specify group membership, role, security clearance,
+ or other authorization information associated with the AC holder.
+
+ The syntax for the AC is defined in Recommendation X.509, making the
+ term "X.509 certificate" ambiguous.
+
+ Some people constantly confuse PKCs and ACs. An analogy may make the
+ distinction clear. A PKC can be considered to be like a passport: it
+ identifies the holder, tends to last for a long time, and should not
+ be trivial to obtain. An AC is more like an entry visa: it is
+ typically issued by a different authority and does not last for as
+ long a time. As acquiring an entry visa typically requires
+ presenting a passport, getting a visa can be a simpler process.
+
+ Authorization information may be placed in a PKC extension or placed
+ in a separate attribute certificate (AC). The placement of
+ authorization information in PKCs is usually undesirable for two
+ reasons. First, authorization information often does not have the
+ same lifetime as the binding of the identity and the public key.
+ When authorization information is placed in a PKC extension, the
+ general result is the shortening of the PKC useful 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 authorization
+ information from the PKC. Yet, authorization information also needs
+ to be bound to an identity. An AC provides this binding; it is
+ simply a digitally signed (or certified) identity and set of
+ attributes.
+
+ An AC may be used with various security services, including access
+ control, data origin authentication, and non-repudiation.
+
+
+
+Farrell, et al. Standards Track [Page 4]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ PKCs can provide an identity to access control decision functions.
+ However, in many contexts, the identity is not the criterion that is
+ used for access control decisions; rather, the role or group-
+ membership of the accessor is the criterion used. Such access
+ control schemes are called role-based access control.
+
+ When making an access control decision based on an AC, an access
+ control decision function may need to ensure that the appropriate AC
+ holder is the entity that has requested access. One way in which the
+ linkage between the request or identity and the AC can be achieved is
+ the inclusion of a reference to a PKC within the AC and the use of
+ the private key corresponding to the PKC for authentication within
+ the access request.
+
+ ACs may also be used in the context of a data origin authentication
+ service and a non-repudiation service. In these contexts, the
+ attributes contained in the AC provide additional information about
+ the signing entity. This information can be used to make sure that
+ the entity is authorized to sign the data. This kind of checking
+ depends either on the context in which the data is exchanged or on
+ the data that has been digitally signed.
+
+ This document obsoletes [RFC3281]. Changes since [RFC3281] are
+ listed in Appendix D.
+
+1.1. Requirements Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+1.2. AC Path Delegation
+
+ The X.509 standard [X.509-2000] defines authorization as the
+ "conveyance of privilege from one entity that holds such privilege,
+ to another entity". An AC is one authorization mechanism.
+
+ 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
+ ACs could be employed to delegate authorization.
+
+ Since the administration and processing associated with such AC
+ chains is complex and the use of ACs in the Internet today is quite
+ limited, it is RECOMMENDED that implementations of this specification
+ not use AC chains. Other (future) specifications may address the use
+ of AC chains. This 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
+
+
+
+Farrell, et al. Standards Track [Page 5]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ 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
+ able to process a single AC at a time. Processing of more than one
+ 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].
+
+1.3. Attribute Certificate Distribution ("Push" vs. "Pull")
+
+ As discussed above, ACs provide a mechanism to securely provide
+ authorization information to, for example, access control decision
+ 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
+ a server. This means that no new connections between the client and
+ server are required. It also means that no search burden is imposed
+ on servers, which improves performance and that the AC verifier is
+ only presented with what it "needs to know". The "push" model is
+ especially suitable in inter-domain cases where the client's rights
+ should be assigned within the client's "home" domain.
+
+ In other cases, it is more suitable for a client to simply
+ 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
+ of the "pull" model is that it can be implemented without changes to
+ the client or to the client-server protocol. The "pull" model is
+ especially suitable for inter-domain cases where the client's rights
+ should be assigned within the server's domain, rather than within the
+ client's domain.
+
+ There are a number of possible exchanges involving three entities:
+ the client, the server, and the AC issuer. In addition, a directory
+ service or other repository for AC retrieval MAY be supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 6]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ Figure 1 shows an abstract view of the exchanges that may involve
+ ACs. This profile does not specify a protocol for these exchanges.
+
+ +--------------+
+ | | Server Acquisition
+ | AC issuer +<---------------------------+
+ | | |
+ +--+-----------+ |
+ ^ |
+ | Client |
+ | Acquisition |
+ v v
+ +--+-----------+ +--+------------+
+ | | AC "push" | |
+ | Client +<------------------------| Server |
+ | | (part of app. protocol) | |
+ +--+-----------+ +--+------------+
+ ^ ^
+ | Client | Server
+ | Lookup +--------------+ | Lookup
+ | | | |
+ +-------------->+ Repository +<--------+
+ | |
+ +--------------+
+
+ Figure 1: AC Exchanges
+
+1.4. Document Structure
+
+ Section 2 defines some terminology. Section 3 specifies the
+ requirements that this profile is intended to meet. Section 4
+ contains the profile of the X.509 AC. Section 5 specifies rules for
+ AC validation. Section 6 specifies rules for AC revocation checks.
+ Section 7 specifies optional features that MAY be supported; however,
+ support for these features is not required for conformance to this
+ profile. Finally, the appendices contain the list of object
+ identifiers (OIDs) required to support this specification and an
+ ASN.1 module.
+
+2. Terminology
+
+ For simplicity, we use the terms client and server in this
+ specification. This is not intended to indicate that ACs are only to
+ be used in client-server environments. For example, ACs may be used
+ in the Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2
+ context, where the mail user agent would be both a "client" and a
+ "server" in the sense the terms are used here.
+
+
+
+
+Farrell, et al. Standards Track [Page 7]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ Term Meaning
+
+ AA Attribute Authority, the entity that issues the AC,
+ synonymous in this specification with "AC issuer".
+
+ AC Attribute Certificate.
+
+ AC user Any entity that parses or processes an AC.
+
+ AC verifier Any entity that checks the validity of an AC and then
+ makes use of the result.
+
+ AC issuer The entity that signs the AC: synonymous in this
+ specification with "AA".
+
+ AC holder The entity indicated (perhaps indirectly) in the Holder
+ field of the AC.
+
+ Client The entity that is requesting the action for which
+ authorization checks are to be made.
+
+ Proxying In this specification, Proxying is used to mean the
+ situation where an application server acts as an
+ application client on behalf of a user. Proxying here
+ does not mean granting of authority.
+
+ PKC Public Key Certificate - uses the ASN.1 type
+ Certificate defined in X.509 and profiled in RFC 5280.
+ This (non-standard) acronym is used in order to avoid
+ confusion about the term "X.509 certificate".
+
+ Server The entity that requires that the authorization checks
+ are made.
+
+3. Requirements
+
+ This AC profile meets the following requirements.
+
+ Time/Validity requirements:
+
+ 1. Support for short-lived as well as long-lived ACs. Typical short-
+ lived validity periods might be measured in hours, as opposed to
+ months for PKCs. Short validity periods allow ACs to be useful
+ without a revocation mechanism.
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 8]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ Attribute Types:
+
+ 2. Issuers of ACs should be able to define their own attribute types
+ for use within closed domains.
+
+ 3. Some standard attribute types, which can be contained within ACs,
+ should be defined. Examples include "access identity", "group",
+ "role", "clearance", "audit identity", and "charging identity".
+
+ 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 "SPYRUS" should be easily distinguished.
+
+ Targeting of ACs:
+
+ 5. It should be possible to "target" an AC at one, or a small number
+ of, servers. This means that a trustworthy non-target server will
+ reject the AC for authorization decisions.
+
+ Push vs. Pull
+
+ 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 repository
+ or other network service, including an online AC issuer.
+
+4. Attribute Certificate Profile
+
+ ACs may be used in a wide range of applications and environments
+ covering a broad spectrum of interoperability goals and a broader
+ spectrum of operational and assurance requirements. The goal of this
+ document is to establish a common baseline for generic applications
+ requiring broad interoperability and limited special purpose
+ requirements. In particular, the emphasis will be on supporting the
+ use of attribute certificates for informal Internet electronic mail,
+ IPsec, and WWW applications.
+
+ This section presents a profile for ACs that will foster
+ interoperability. This section also defines some private extensions
+ for the Internet community.
+
+ While the ISO/IEC/ITU documents use the 1993 (or later) version of
+ ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for
+ PKCs [PKIXPROF]. The encoded certificates and extensions from either
+ ASN.1 version are bit-wise identical.
+
+
+
+
+
+Farrell, et al. Standards Track [Page 9]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ Where maximum lengths for fields are specified, these lengths refer
+ to the DER encoding and do not include the ASN.1 tag or length
+ fields.
+
+ Conforming implementations MUST support the profile specified in this
+ section.
+
+4.1. X.509 Attribute Certificate Definition
+
+ X.509 contains the definition of an AC given below. All types that
+ are not defined in this document can be found in [PKIXPROF].
+
+ AttributeCertificate ::= SEQUENCE {
+ acinfo AttributeCertificateInfo,
+ signatureAlgorithm AlgorithmIdentifier,
+ signatureValue BIT STRING
+ }
+
+ AttributeCertificateInfo ::= SEQUENCE {
+ version AttCertVersion, -- version is v2
+ holder Holder,
+ issuer AttCertIssuer,
+ signature AlgorithmIdentifier,
+ serialNumber CertificateSerialNumber,
+ attrCertValidityPeriod AttCertValidityPeriod,
+ attributes SEQUENCE OF Attribute,
+ issuerUniqueID UniqueIdentifier OPTIONAL,
+ extensions Extensions OPTIONAL
+ }
+
+ AttCertVersion ::= INTEGER { v2(1) }
+
+ Holder ::= SEQUENCE {
+ baseCertificateID [0] IssuerSerial OPTIONAL,
+ -- the issuer and serial number of
+ -- the holder's Public Key Certificate
+ entityName [1] GeneralNames OPTIONAL,
+ -- the name of the claimant or role
+ objectDigestInfo [2] ObjectDigestInfo OPTIONAL
+ -- used to directly authenticate the holder,
+ -- for example, an executable
+ }
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 10]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ ObjectDigestInfo ::= SEQUENCE {
+ digestedObjectType ENUMERATED {
+ publicKey (0),
+ publicKeyCert (1),
+ otherObjectTypes (2) },
+ -- otherObjectTypes MUST NOT
+ -- be used in this profile
+ otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
+ digestAlgorithm AlgorithmIdentifier,
+ objectDigest BIT STRING
+ }
+
+ AttCertIssuer ::= CHOICE {
+ v1Form GeneralNames, -- MUST NOT be used in this
+ -- profile
+ v2Form [0] V2Form -- v2 only
+ }
+
+ V2Form ::= SEQUENCE {
+ issuerName GeneralNames OPTIONAL,
+ baseCertificateID [0] IssuerSerial OPTIONAL,
+ objectDigestInfo [1] ObjectDigestInfo OPTIONAL
+ -- issuerName MUST be present in this profile
+ -- baseCertificateID and objectDigestInfo MUST NOT
+ -- be present in this profile
+ }
+
+ IssuerSerial ::= SEQUENCE {
+ issuer GeneralNames,
+ serial CertificateSerialNumber,
+ issuerUID UniqueIdentifier OPTIONAL
+ }
+
+ AttCertValidityPeriod ::= SEQUENCE {
+ notBeforeTime GeneralizedTime,
+ notAfterTime GeneralizedTime
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 11]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ Although the Attribute syntax is defined in [PKIXPROF], we repeat the
+ definition here for convenience.
+
+ Attribute ::= SEQUENCE {
+ type AttributeType,
+ values SET OF AttributeValue
+ -- at least one value is required
+ }
+
+ AttributeType ::= OBJECT IDENTIFIER
+
+ AttributeValue ::= ANY DEFINED BY AttributeType
+
+ Implementers should note that the DER encoding (see [X.509-1988],
+ [X.690]) of the SET OF values requires ordering of the encodings of
+ the values. Though this issue arises with respect to distinguished
+ names, and has to be handled by [PKIXPROF] implementations, it is
+ much more significant in this context, since the inclusion of
+ multiple values is much more common in ACs.
+
+4.2. Profile of Standard Fields
+
+ GeneralName offers great flexibility. To achieve interoperability,
+ in spite of this flexibility, this profile imposes constraints on the
+ use of GeneralName.
+
+ Conforming implementations MUST be able to support the dNSName,
+ directoryName, uniformResourceIdentifier, and iPAddress options.
+ This is compatible with the GeneralName requirements in [PKIXPROF]
+ (mainly in Section 4.2.1.6). Implementations SHOULD also support the
+ SRVName, as defined in [X509-SRV].
+
+ Conforming implementations MUST NOT use the x400Address,
+ ediPartyName, or registeredID options.
+
+ Conforming implementations MAY use the otherName option to convey
+ name forms defined in Internet Standards. For example, Kerberos
+ [KRB] format names can be encoded into the otherName, using a
+ Kerberos 5 principal name OID and a SEQUENCE of the Realm and the
+ PrincipalName.
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 12]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+4.2.1. Version
+
+ The version field MUST have the value of v2. That is, the version
+ field is present in the DER encoding.
+
+ Note: This version (v2) is not backwards compatible with the previous
+ attribute certificate definition (v1) from the 1997 X.509 standard
+ [X.509-1997], but is compatible with the v2 definition from X.509
+ (2000) [X.509-2000].
+
+4.2.2. Holder
+
+ The Holder field is a SEQUENCE allowing three different (optional)
+ syntaxes: baseCertificateID, entityName, and objectDigestInfo. Where
+ only one option is present, the meaning of the Holder field is clear.
+
+ However, where more than one option is used, there is a potential for
+ confusion as to which option is "normative", which is a "hint", etc.
+ Since the correct position is not clear from [X.509-2000], this
+ specification RECOMMENDS that only one of the options be used in any
+ given AC.
+
+ For any environment where the AC is passed in an authenticated
+ message or session and where the authentication is based on the use
+ of an X.509 PKC, the Holder field SHOULD use the baseCertificateID.
+
+ With the baseCertificateID option, the holder's PKC serialNumber and
+ issuer MUST be identical to the AC Holder field. The PKC issuer MUST
+ have a non-empty distinguished name that is to be present as the
+ single value of the holder.baseCertificateID.issuer construct in the
+ directoryName field. The AC holder.baseCertificateID.issuerUID field
+ MUST only be used if the holder's PKC contains an issuerUniqueID
+ field. If both the AC holder.baseCertificateID.issuerUID and the PKC
+ issuerUniqueID fields are present, the same value MUST be present in
+ both fields. Thus, the baseCertificateID is only usable with PKC
+ profiles (like [PKIXPROF]) that mandate that the PKC issuer field
+ contain a non-empty distinguished name value.
+
+ Note: An empty distinguished name is a distinguished name where the
+ SEQUENCE OF relative distinguished names is of zero length. In a DER
+ encoding, this has the value '3000'H.
+
+ If the Holder field uses the entityName option and the underlying
+ authentication is based on a PKC, the entityName MUST be the same as
+ the PKC subject field or one of the values of the PKC subjectAltName
+ field extension (if present). Note that [PKIXPROF] mandates that the
+ subjectAltName extension be present if the PKC subject is an empty
+
+
+
+
+Farrell, et al. Standards Track [Page 13]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ distinguished name. See the Security Considerations 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,
+ only one name SHOULD be present.
+
+ Implementations conforming to this profile are not required to
+ support the use of the objectDigest field. However, Section 7.3
+ specifies how this optional feature MAY be used.
+
+ Any protocol conforming to this profile SHOULD specify which AC
+ holder option is to be used and how this fits with the supported
+ authentication schemes defined in that protocol.
+
+4.2.3. Issuer
+
+ ACs conforming to this profile MUST use the v2Form choice, which MUST
+ contain one and only one GeneralName in the issuerName, which MUST
+ contain a non-empty distinguished name in the directoryName field.
+ This means that all AC issuers MUST have non-empty distinguished
+ names. ACs conforming to this profile MUST omit the
+ baseCertificateID and objectDigestInfo fields.
+
+ Part of the reason for the use of the v2Form containing only an
+ issuerName is that it means that the AC issuer does not have to know
+ which PKC the AC verifier will use for it (the AC issuer). Using the
+ baseCertificateID field to reference the AC issuer would mean that
+ the AC verifier would have to trust the PKC that the AC issuer chose
+ (for itself) at AC creation time.
+
+4.2.4. Signature
+
+ Contains the algorithm identifier used to validate the AC signature.
+
+ This MUST be one of the signing algorithms defined in [PKIXALGS] or
+ defined in any IETF-approved update to [PKIXALGS]. Conforming
+ implementations MUST honor all MUST/SHOULD/MAY signing algorithm
+ statements specified in [PKIXALGS] or IETF-approved updates to
+ [PKIXALGS].
+
+4.2.5. Serial Number
+
+ For any conforming AC, the issuer/serialNumber pair MUST form a
+ unique combination, even if ACs are very short-lived.
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 14]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ 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 be
+ zero -- this can be done by adding a leading (leftmost) '00'H octet
+ if necessary. This removes a potential ambiguity in mapping between
+ a string of octets and an integer value.
+
+ Given the uniqueness and timing requirements above, serial numbers
+ can be expected to contain long integers. AC users MUST be able to
+ handle serialNumber values longer than 4 octets. Conformant ACs MUST
+ NOT contain serialNumber values longer than 20 octets.
+
+ There is no requirement that the serial numbers used by any AC issuer
+ follow any particular ordering. In particular, they need not be
+ monotonically increasing with time. Each AC issuer MUST ensure that
+ each AC that it issues contains a unique serial number.
+
+4.2.6. Validity Period
+
+ The attrCertValidityPeriod (a.k.a. validity) field specifies the
+ period for which the AC issuer certifies that the binding between the
+ holder and the attributes fields will be valid.
+
+ The generalized time type, GeneralizedTime, is a standard ASN.1 type
+ for variable precision representation of time. The GeneralizedTime
+ field can optionally include a representation of the time
+ differential between the local time zone and Greenwich Mean Time.
+
+ For the purposes of this profile, GeneralizedTime values MUST be
+ expressed in Coordinated universal time (UTC) (also known as
+ Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times
+ 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
+ 4.1.2.5.2.)
+
+ AC users MUST be able to handle an AC which, at the time of
+ processing, has parts of its validity period or all its validity
+ 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
+
+ The attributes field gives information about the AC holder. When the
+ AC is used for authorization, this will often contain a set of
+ privileges.
+
+
+
+
+
+Farrell, et al. Standards Track [Page 15]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ The attributes field contains a SEQUENCE OF Attribute. Each
+ Attribute contains the type of the attribute and a SET OF values.
+ For a given AC, each AttributeType OBJECT IDENTIFIER in the sequence
+ MUST be unique. That is, only one instance of each attribute can
+ occur in a single AC, but each instance can be multi-valued.
+
+ AC users MUST be able to handle multiple values for all attribute
+ types.
+
+ An AC MUST contain at least one attribute. That is, the SEQUENCE OF
+ Attributes MUST NOT be of zero length.
+
+ Some standard attribute types are defined in Section 4.4.
+
+4.2.8. Issuer Unique Identifier
+
+ This field MUST NOT be used unless it is also used in the AC issuer's
+ PKC, in which case it MUST be used. Note that [PKIXPROF] states that
+ this field SHOULD NOT be used by conforming certification authorities
+ (CAs), but that applications SHOULD be able to parse PKCs containing
+ the field.
+
+4.2.9. Extensions
+
+ The extensions field generally gives information about the AC as
+ opposed to information about the AC holder.
+
+ An AC that has no extensions conforms to the profile; however,
+ Section 4.3 defines the extensions that MAY be used with this
+ profile, and whether or not they may be marked critical. If any
+ other critical extension is used, the AC does not conform to this
+ profile. However, if any other non-critical extension is used, the
+ AC does conform to this profile.
+
+ The extensions defined for ACs provide methods for associating
+ additional attributes with holders. This profile also allows
+ communities to define private extensions to carry information unique
+ to those communities. Each extension in an AC may be designated as
+ critical or non-critical. An AC-using system MUST reject an AC if it
+ encounters a critical extension it does not recognize; however, a
+ non-critical extension may be ignored if it is not recognized.
+ Section 4.3 presents recommended extensions used within Internet ACs
+ and standard locations for information. Communities may elect to use
+ additional extensions; however, caution should be exercised in
+ adopting any critical extensions in ACs that might prevent use in a
+ general context.
+
+
+
+
+
+Farrell, et al. Standards Track [Page 16]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+4.3. Extensions
+
+4.3.1. Audit Identity
+
+ In some circumstances, it is required (e.g., by data protection/data
+ privacy legislation) that audit trails not contain records that
+ directly identify individuals. This circumstance may make the use of
+ the AC Holder field unsuitable for use in audit trails.
+
+ To allow for such cases, an AC MAY contain an audit identity
+ extension. Ideally, it SHOULD be infeasible to derive the AC
+ holder's identity from the audit identity value without the
+ cooperation of the AC issuer.
+
+ The value of the audit identity, along with the AC issuer/serial,
+ SHOULD then be used for audit/logging purposes. If the value of the
+ audit identity is suitably chosen, a server/service administrator can
+ use audit trails to track the behavior of an AC holder without being
+ able to identify the AC holder.
+
+ The server/service administrator in combination with the AC issuer
+ 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
+ the actual identity of the AC holder from the audit identity.
+
+ Of course, auditing could be based on the AC issuer/serial pair;
+ however, this method does not allow tracking of the same AC holder
+ with 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 the AC holder's PKC issuer/serial; however, this will
+ often allow the server/service administrator to identify the AC
+ holder.
+
+ As the AC verifier might otherwise use the AC holder or some other
+ identifying value for audit purposes, this extension MUST be critical
+ when used.
+
+ 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
+ identity does not make use of the AC anonymous; it simply ensures
+ that the ensuing audit trails do not contain identifying information.
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 17]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ 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
+ OID { id-pe 4 }
+ syntax OCTET STRING
+ criticality MUST be TRUE
+
+4.3.2. AC Targeting
+
+ To target an AC, the target information extension, imported from
+ [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
+ servers/services. An (honest) AC verifier who is not amongst the
+ named servers/services MUST reject the AC.
+
+ If this extension is not present, the AC is not targeted and may be
+ accepted by any server.
+
+ In this profile, the targeting information simply consists of a list
+ of named targets or groups.
+
+ The following syntax is used to represent the targeting information:
+
+ Targets ::= SEQUENCE OF Target
+
+ Target ::= CHOICE {
+ targetName [0] GeneralName,
+ targetGroup [1] GeneralName,
+ targetCert [2] TargetCert
+ }
+
+ TargetCert ::= SEQUENCE {
+ targetCertificate IssuerSerial,
+ targetName GeneralName OPTIONAL,
+ certDigestInfo ObjectDigestInfo OPTIONAL
+ }
+
+ The targetCert CHOICE within the Target structure is only present to
+ 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 targetName fields in the Targets SEQUENCE, or if the current
+ 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
+ targeting extension.
+
+
+
+
+
+Farrell, et al. Standards Track [Page 18]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ How the membership of a target within a targetGroup is determined is
+ not defined here. It is assumed that any given target "knows" the
+ names of the targetGroups to which it belongs or can otherwise
+ determine its membership. For example, the targetGroup specifies a
+ DNS domain, and the AC verifier knows the DNS domain to which it
+ belongs. For another example, the targetGroup specifies "PRINTERS",
+ and the AC verifier knows whether or not it is a printer or print
+ server.
+
+ Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
+ Targets". Conforming AC issuer implementations MUST only produce one
+ "Targets" element. Conforming AC users MUST be able to accept a
+ "SEQUENCE OF Targets". If more than one Targets element is found in
+ an AC, the extension MUST be treated as if all Target elements had
+ been found within one Targets element.
+
+ name id-ce-targetInformation
+ OID { id-ce 55 }
+ syntax SEQUENCE OF Targets
+ criticality MUST be TRUE
+
+4.3.3. Authority Key Identifier
+
+ The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY
+ 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
+ issuer". As with PKCs, this extension SHOULD be included in ACs.
+
+ Note: An AC, where the issuer field used the baseCertificateID
+ CHOICE, would not need an authorityKeyIdentifier extension, as it is
+ explicitly linked to the key in the referred certificate. However,
+ as this profile states (in Section 4.2.3), ACs MUST use the v2Form
+ with issuerName CHOICE, this duplication does not arise.
+
+ name id-ce-authorityKeyIdentifier
+ OID { id-ce 35 }
+ syntax AuthorityKeyIdentifier
+ criticality MUST be FALSE
+
+4.3.4. Authority Information Access
+
+ The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be
+ used to assist the AC verifier in checking the revocation status of
+ the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by
+ this profile since AC chains are not expected.
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 19]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ The following accessMethod is used to indicate that revocation status
+ checking is provided for this AC, using the Online Certificate Status
+ Protocol (OCSP) defined in [OCSP]:
+
+ id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
+
+ The accessLocation MUST contain a URI, and the URI MUST contain an
+ HTTP URL [HTTP-URL] that specifies the location of an OCSP responder.
+ The AC issuer MUST, of course, maintain an OCSP responder at this
+ location.
+
+ name id-ce-authorityInfoAccess
+ OID { id-pe 1 }
+ syntax AuthorityInfoAccessSyntax
+ criticality MUST be FALSE
+
+4.3.5. CRL Distribution Points
+
+ The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY
+ be used to assist the AC verifier in checking the revocation status
+ of the AC. See Section 6 for details on revocation.
+
+ If the crlDistributionPoints extension is present, then exactly one
+ distribution point MUST be present. The crlDistributionPoints
+ extension MUST use the DistributionPointName option, which MUST
+ 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 [HTTP-URL] or a Lightweight Directory Access
+ Protocol (LDAP) URL [LDAP-URL].
+
+ name id-ce-cRLDistributionPoints
+ OID { id-ce 31 }
+ syntax CRLDistributionPoints
+ criticality MUST be FALSE
+
+4.3.6. No Revocation Available
+
+ The noRevAvail extension, defined in [X.509-2000], allows an AC
+ issuer to indicate that no revocation information will be made
+ available for this AC.
+
+ This extension MUST be non-critical. An AC verifier that does not
+ understand this extension might be able to find a revocation list
+ from the AC issuer, but the revocation list will never include an
+ entry for the AC.
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 20]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ name id-ce-noRevAvail
+ OID { id-ce 56 }
+ syntax NULL (i.e., '0500'H is the DER encoding)
+ criticality MUST be FALSE
+
+4.4. Attribute Types
+
+ Some of the attribute types defined below make use of the
+ IetfAttrSyntax type, also defined below. The reasons for using this
+ type are:
+
+ 1. It allows a separation between the AC issuer and the attribute
+ policy authority. This is useful for situations where a single
+ policy authority (e.g., an organization) allocates attribute
+ values, but where multiple AC issuers are deployed for performance
+ or other reasons.
+
+ 2. The syntaxes allowed for values are restricted to OCTET STRING,
+ OBJECT IDENTIFIER, and UTF8String, which significantly reduces the
+ complexity associated with matching more general syntaxes. All
+ multi-valued attributes using this syntax are restricted so that
+ each value MUST use the same choice of value syntax. For example,
+ AC issuers must not use one value with an oid and a second value
+ with a string.
+
+ IetfAttrSyntax ::= SEQUENCE {
+ policyAuthority [0] GeneralNames OPTIONAL,
+ values SEQUENCE OF CHOICE {
+ octets OCTET STRING,
+ oid OBJECT IDENTIFIER,
+ string UTF8String
+ }
+ }
+
+ In the descriptions below, each attribute type is either tagged
+ "Multiple Allowed" or "One Attribute value only; multiple values
+ within the IetfAttrSyntax". This refers to the SET OF
+ AttributeValues; the AttributeType still only occurs once, as
+ specified in Section 4.2.7.
+
+4.4.1. Service Authentication Information
+
+ The SvceAuthInfo attribute identifies the AC holder to the
+ server/service by a name, and the attribute MAY include optional
+ service specific authentication information. Typically, this will
+ contain a username/password pair for a "legacy" application.
+
+
+
+
+
+Farrell, et al. Standards Track [Page 21]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ This attribute provides 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
+ field contains sensitive information, such as a password (see Section
+ 7.1).
+
+ name id-aca-authenticationInfo
+ OID { id-aca 1 }
+ syntax SvceAuthInfo
+ values Multiple allowed
+
+ SvceAuthInfo ::= SEQUENCE {
+ service GeneralName,
+ ident GeneralName,
+ authInfo OCTET STRING OPTIONAL
+ }
+
+4.4.2. Access Identity
+
+ The accessIdentity attribute identifies the AC holder to the
+ server/service. For this attribute the authInfo field MUST NOT be
+ 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
+ OID { id-aca 2 }
+ syntax SvceAuthInfo
+ values Multiple allowed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 22]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+4.4.3. Charging Identity
+
+ The chargingIdentity attribute identifies the AC holder for charging
+ purposes. In general, the charging identity will be different from
+ other identities of the holder. For example, the holder's company
+ may be charged for service.
+
+ name id-aca-chargingIdentity
+ OID { id-aca 3 }
+ syntax IetfAttrSyntax
+ values One Attribute value only; multiple values within the
+ IetfAttrSyntax
+
+4.4.4. Group
+
+ The group attribute carries information about group memberships of
+ the AC holder.
+
+ name id-aca-group
+ OID { id-aca 4 }
+ syntax IetfAttrSyntax
+ values One Attribute value only; multiple values within the
+ IetfAttrSyntax
+
+4.4.5. Role
+
+ The role attribute, specified in [X.509-2000], carries information
+ about role allocations of the AC holder.
+
+ The syntax used for this attribute is:
+
+ RoleSyntax ::= SEQUENCE {
+ roleAuthority [0] GeneralNames OPTIONAL,
+ roleName [1] GeneralName
+ }
+
+ The roleAuthority field MAY be used to specify the issuing authority
+ for the role specification certificate. There is no requirement that
+ 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 "urn:administrator" in the roleName
+ field and the value "Baltimore" or "SPYRUS" in the roleAuthority
+ field.
+
+
+
+
+
+Farrell, et al. Standards Track [Page 23]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ The roleName field MUST be present, and roleName MUST use the
+ uniformResourceIdentifier CHOICE of the GeneralName.
+
+ name id-at-role
+ OID { id-at 72 }
+ syntax RoleSyntax
+ values Multiple allowed
+
+4.4.6. Clearance
+
+ The clearance attribute, specified in [X.501-1993], carries clearance
+ (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 it is
+ specified in [X.501-1993]. 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.
+
+ The object identifier for the clearance attribute from [RFC3281] is:
+
+ id-at-clearance OBJECT IDENTIFIER ::= {
+ joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
+ clearance (55) }
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 24]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ The associated syntax was originally (and erroneously) defined in
+ [RFC3281] as:
+
+ Clearance ::= SEQUENCE {
+ policyId [0] OBJECT IDENTIFIER,
+ classList [1] ClassList DEFAULT {unclassified},
+ securityCategories [2] SET OF SecurityCategory OPTIONAL
+ }
+
+ But, it was later corrected (to restore conformance with
+ [X.509-1997]) to:
+
+ Clearance ::= SEQUENCE {
+ policyId OBJECT IDENTIFIER,
+ classList ClassList DEFAULT {unclassified},
+ securityCategories SET OF SecurityCategory OPTIONAL
+ }
+
+ The object identifier for the clearance attribute from [X.509-1997]
+ is:
+
+ id-at-clearance OBJECT IDENTIFIER ::= {
+ joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
+
+ The associated syntax is as follows:
+
+ Clearance ::= SEQUENCE {
+ policyId OBJECT IDENTIFIER,
+ classList ClassList DEFAULT {unclassified},
+ securityCategories SET OF SecurityCategory OPTIONAL
+ }
+
+ Implementations MUST support the clearance attribute as defined in
+ [X.501-1997]. Implementations SHOULD support decoding the clearance
+ syntax from [RFC3281] and the errata report against it (see Appendix
+ C). Implementations MUST NOT output the clearance attribute as
+ defined in [RFC3281].
+
+ ClassList ::= BIT STRING {
+ unmarked (0),
+ unclassified (1),
+ restricted (2),
+ confidential (3),
+ secret (4),
+ topSecret (5)
+ }
+
+
+
+
+
+Farrell, et al. Standards Track [Page 25]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ SecurityCategory ::= SEQUENCE {
+ type [0] OBJECT IDENTIFIER,
+ value [1] EXPLICIT ANY DEFINED BY type
+ }
+
+ -- Note that in [RFC3281], the SecurityCategory syntax was as
+ -- follows:
+ --
+ -- SecurityCategory ::= SEQUENCE {
+ -- type [0] IMPLICIT OBJECT IDENTIFIER,
+ -- value [1] ANY DEFINED BY type
+ -- }
+ --
+ -- The removal of the IMPLICIT from the type line and the
+ -- addition of the EXPLICIT to the value line result in
+ -- no changes to the encodings.
+ -- This is the same as the original syntax, which was defined
+ -- using the MACRO construct, as follows:
+ -- SecurityCategory ::= SEQUENCE {
+ -- type [0] IMPLICIT SECURITY-CATEGORY,
+ -- value [1] ANY DEFINED BY type
+ -- }
+ --
+ -- SECURITY-CATEGORY MACRO ::=
+ -- BEGIN
+ -- TYPE NOTATION ::= type | empty
+ -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
+ -- END
+
+ name { id-at-clearance }
+ OID { joint-iso-ccitt(2) ds(5) attribute-type (4)
+ clearance (55) }
+ syntax Clearance -- imported from [X.501-1997]
+ values Multiple allowed
+
+4.5. Profile of AC Issuer's PKC
+
+ The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
+ extension in the PKC MUST NOT explicitly indicate that the AC
+ issuer's public key cannot be used to validate a digital signature.
+ In order to avoid confusion regarding serial numbers and revocations,
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 26]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ an AC issuer MUST NOT also be a PKC Issuer. That is, 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
+
+ This section describes a basic set of rules that all valid ACs MUST
+ satisfy. Some additional checks are also described, which AC
+ verifiers MAY choose to implement.
+
+ To be valid, an AC MUST satisfy all of the following:
+
+ 1. Where the holder uses a PKC to authenticate to the AC verifier,
+ the AC holder's PKC MUST be found, and the entire certification
+ path of that PKC MUST be verified in accordance with [PKIXPROF].
+ As noted in the Security Considerations section, if some other
+ authentication scheme is used, AC verifiers need to be very
+ careful mapping the identities (authenticated identity, holder
+ field) involved.
+
+ 2. The AC signature must be cryptographically correct, and the AC
+ issuer's entire PKC certification path MUST be verified in
+ accordance with [PKIXPROF].
+
+ 3. The AC issuer's PKC MUST also conform to the profile specified in
+ Section 4.5 above.
+
+ 4. The AC issuer MUST be directly trusted as an AC issuer (by
+ configuration or otherwise).
+
+ 5. The time for which the AC is being evaluated MUST be within the AC
+ validity. If the evaluation time is equal to either notBeforeTime
+ or notAfterTime, then the AC is timely and this check succeeds.
+ Note that in some applications, the evaluation time MAY not be the
+ same as the current time.
+
+ 6. The AC targeting check MUST pass as specified in Section 4.3.2.
+
+ 7. If the AC contains an unsupported critical extension, the AC MUST
+ be rejected.
+
+ Support for an extension in this context means:
+
+ 1. The AC verifier MUST be able to parse the extension value.
+
+ 2. Where the extension value causes the AC to be rejected, the AC
+ verifier MUST reject the AC.
+
+
+
+
+Farrell, et al. Standards Track [Page 27]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ Additional Checks:
+
+ 1. The AC MAY be rejected on the basis of further AC verifier
+ configuration. For example, an AC verifier may be configured to
+ reject ACs that contain or lack certain attributes.
+
+ 2. If the AC verifier provides an interface that allows applications
+ to query the contents of the AC, then the AC verifier MAY filter
+ the attributes from the AC on the basis of configured information.
+ For example, an AC verifier might be configured not to return
+ certain attributes to certain servers.
+
+6. Revocation
+
+ In many environments, the validity period of an AC is less than the
+ time required to issue and distribute revocation information.
+ Therefore, short-lived ACs typically do not require revocation
+ support. However, long-lived ACs and environments where ACs enable
+ high value transactions MAY require revocation support.
+
+ Two revocation schemes are defined, and the AC issuer should elect
+ 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 understands that no
+ revocation status information will be made available. The
+ noRevAvail extension is defined in Section 4.3.6, and the
+ noRevAvail extension MUST be present in the AC to indicate use of
+ this scheme.
+
+ Where no noRevAvail is present, the AC issuer is implicitly
+ stating that revocation status checks are supported, and some
+ revocation method MUST be provided to allow AC verifiers to
+ establish the revocation status of the AC.
+
+ "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
+ revoke" scheme is supported, then all ACs that do not contain a
+ noRevAvail extension, MUST be rejected.
+
+
+
+
+Farrell, et al. Standards Track [Page 28]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ For AC issuers, the "never revoke" scheme MUST be supported. If all
+ ACs that will ever be issued by that AC issuer contain a noRevAvail
+ extension, the "pointer in AC" scheme need not be supported. If any
+ AC can be issued that does not contain the noRevAvail extension, the
+ "pointer in AC" scheme MUST be supported.
+
+ An AC MUST NOT contain both a noRevAvail extension and a "pointer in
+ AC".
+
+ An AC verifier MAY use any source for AC revocation status
+ information.
+
+7. Optional Features
+
+ This section specifies features that MAY be implemented. Conformance
+ 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
+
+ AC attributes MAY need to be encrypted if the AC is carried in the
+ clear within an application protocol or the AC contains sensitive
+ information (e.g., username/password).
+
+ When a set of attributes is to be encrypted within an AC, the
+ Cryptographic Message Syntax, EnvelopedData structure [CMS] is used
+ to carry the ciphertext and associated per-recipient keying
+ information.
+
+ This type of attribute encryption is targeted. Before the AC is
+ signed, the attributes are encrypted for a set of predetermined
+ recipients.
+
+ Within EnvelopedData, the encapsulatedContentInfo identifies the
+ content type carried within the ciphertext. In this case, the
+ contentType field of encapsulatedContentInfo MUST contain id-ct-
+ attrCertEncAttrs, which has the following value:
+
+ attrCertEncAttrs OBJECT IDENTIFIER ::= {
+ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+ id-smime(16) id-ct(1) 14 }
+
+ The ciphertext is included in the AC as the value of an encAttrs
+ attribute. Only one encAttrs attribute can be present in an AC;
+ however, the encAttrs attribute MAY be multi-valued, and each of its
+ values will contain an independent EnvelopedData.
+
+
+
+
+Farrell, et al. Standards Track [Page 29]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ Each value can contain a set of attributes (each possibly a multi-
+ valued attribute) encrypted for a set of predetermined recipients.
+
+ The cleartext that is encrypted has the type:
+
+ ACClearAttrs ::= SEQUENCE {
+ acIssuer GeneralName,
+ acSerial INTEGER,
+ attrs SEQUENCE OF Attribute
+ }
+
+ The DER encoding of the ACClearAttrs structure is used as the
+ encryptedContent field of the EnvelopedData. The DER encoding MUST
+ be embedded in an OCTET STRING.
+
+ The acIssuer and acSerial fields are present to prevent ciphertext
+ stealing. When an AC verifier has successfully decrypted an
+ encrypted attribute, it MUST then check that the AC issuer and
+ serialNumber fields contain the same values. This prevents a
+ malicious AC issuer from copying ciphertext from another AC (without
+ knowing its corresponding plaintext).
+
+ The procedure for an AC issuer when encrypting attributes is
+ illustrated by the following (any other procedure that gives the same
+ result MAY be used):
+
+ 1. Identify the sets of attributes that are to be encrypted for each
+ set of recipients.
+
+ 2. For each attribute set that is to be encrypted:
+
+ 2.1. Create an EnvelopedData structure for the data for this set
+ of recipients.
+
+ 2.2. Encode the ContentInfo containing the EnvelopedData as a
+ value of the encAttrs attribute.
+
+ 2.3. Ensure the cleartext attributes are not present in the
+ to-be-signed AC.
+
+ 3. Add the encAttrs (with its multiple values) to the AC.
+
+ Note that there may be more than one attribute of the same type (the
+ same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain
+ the same attribute type both in clear and in encrypted form (and
+ indeed several times if the different recipients are associated with
+ more than one EnvelopedData). For example, an AC could contain a
+ cleartext clearance attribute saying the holder is cleared to SECRET,
+
+
+
+Farrell, et al. Standards Track [Page 30]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ and, in addition, an encrypted clearance attribute whose value is
+ some higher clearance that's not allowed to be known everywhere. One
+ approach implementers may choose, would be to merge attribute values
+ following decryption in order to re-establish the "once only"
+ constraint.
+
+ name id-aca-encAttrs
+ OID { id-aca 6}
+ syntax ContentInfo
+ values Multiple Allowed
+
+ If an AC contains attributes apparently encrypted for the AC
+ verifier, then the decryption process failure MUST cause the AC to be
+ rejected.
+
+7.2. Proxying
+
+ When a server acts as a client for another server on behalf of the AC
+ holder, the server MAY need to proxy an AC. Such proxying MAY have
+ to be done under the AC issuer's control, so that not every AC is
+ proxiable and so that a given proxiable AC can be proxied in a
+ targeted fashion. Support for chains of proxies (with more than one
+ intermediate server) MAY also be required. Note that this does not
+ involve a chain of ACs.
+
+ In order to meet this requirement, we define another extension,
+ ProxyInfo, similar to the targeting extension.
+
+ 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 that
+ the AC is allowed to be used by this verifier.
+
+ The proxying information is a list in which each item is a list of
+ targeting information. If the verifier and the sender of the AC are
+ both named in the same proxy list, the AC can then be accepted (the
+ exact rule is given below).
+
+ The effect is that the AC holder can send the AC to any valid target,
+ which can then only proxy to targets that are in one of the same
+ proxy lists as itself.
+
+ The following data structure is used to represent the
+ targeting/proxying information:
+
+ ProxyInfo ::= SEQUENCE OF Targets
+
+ Targets is explained in Section 4.3.2. As in the case of targeting,
+ the targetCert CHOICE MUST NOT be used.
+
+
+
+Farrell, et al. Standards Track [Page 31]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ A proxy check succeeds if either one of the conditions below is met:
+
+ 1. The identity of the sender, as established by the underlying
+ authentication service, matches the Holder field of the AC, and
+ the current server "matches" any one of the proxy sets. Recall
+ that "matches" is as defined Section 4.3.2.
+
+ 2. The identity of the sender, as established by the underlying
+ authentication service, "matches" one of the proxy sets (call it
+ set "A"), and the current server is one of the targetName fields
+ in the set "A", or the current server is a member of one of the
+ targetGroup fields in set "A".
+
+ 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 always,
+ the AC holder. In such cases, prevention of AC "stealing" requires
+ that the AC verifier MUST check that all targets on the path are
+ members of the same proxy set. It is the responsibility of the AC-
+ using protocol to ensure that a trustworthy list of targets on the
+ path is available to the AC verifier.
+
+ name id-pe-ac-proxying
+ OID { id-pe 10 }
+ syntax ProxyInfo
+ criticality MUST be TRUE
+
+7.3. Use of ObjectDigestInfo
+
+ In some environments, it may be required that the AC is not linked
+ either to an identity (via entityName) or to a PKC (via
+ baseCertificateID). The objectDigestInfo CHOICE in the Holder field
+ allows support for this requirement.
+
+ If the holder is identified with the objectDigestInfo field, then the
+ AC version field MUST contain v2 (the integer 1).
+
+ The idea is to link the AC to an object by placing a hash of that
+ object into the Holder field of the AC. For example, this allows
+ production of ACs that are linked to public keys rather than names.
+ It also allows production of ACs that contain privileges associated
+ 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.
+ That is, conformant ACs MUST NOT use the otherObjectTypes value for
+ the digestedObjectType.
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 32]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ 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,
+ specifically, the input for the hash algorithm MUST be the DER
+ encoding of a SubjectPublicKeyInfo representation of the key.
+
+ Note: this includes the AlgorithmIdentifier as well as the BIT
+ STRING. The rules given in [PKIXALGS] for encoding keys MUST be
+ followed. In this case, the digestedObjectType MUST be publicKey and
+ the otherObjectTypeID field MUST NOT be present.
+
+ Note that if the public key value used as input to the hash function
+ has been extracted from a PKC, it is possible that the
+ SubjectPublicKeyInfo from that PKC is NOT the value that should be
+ hashed. This can occur if Digital Signature Algorithm (DSA) Dss-
+ parms are inherited as described in Section 2.3.2 of [PKIXALGS]. The
+ correct input for hashing in this context will include the value of
+ the parameters inherited from the CA's PKC, and thus may differ from
+ the SubjectPublicKeyInfo present in the PKC.
+
+ Implementations that support this feature MUST be able to handle the
+ representations of public keys for the algorithms specified in
+ Section 2.3 of [PKIXALGS].
+
+ 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
+ signature value. In this case, the digestedObjectType MUST be
+ publicKeyCert and the otherObjectTypeID field MUST NOT be present.
+
+7.4. AA Controls
+
+ During AC validation, a relying party has to answer the question: is
+ this AC issuer trusted to issue ACs containing this attribute? The
+ AAControls PKC extension MAY be used to help answer the question.
+ The AAControls extension is intended to be used in CA and AC issuer
+ PKCs.
+
+ id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
+
+ AAControls ::= SEQUENCE {
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL,
+ permittedAttrs [0] AttrSpec OPTIONAL,
+ excludedAttrs [1] AttrSpec OPTIONAL,
+ permitUnSpecified BOOLEAN DEFAULT TRUE
+ }
+
+ AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+
+
+
+Farrell, et al. Standards Track [Page 33]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ The AAControls extension is used as follows:
+
+ The pathLenConstraint, if present, is interpreted as in [PKIXPROF].
+ It restricts the allowed distance between the AA CA (a CA directly
+ trusted to include AAControls in its PKCs), and the AC issuer.
+
+ The permittedAttrs field specifies a list of attribute types that any
+ AC issuer below this AA CA is allowed to include in ACs. If this
+ field is not present, it means that no attribute types are explicitly
+ allowed.
+
+ The excludedAttrs field specifies a list of attribute types that no
+ AC issuer below this AA CA is allowed to include in ACs. If this
+ field is not present, it means that no attribute types are explicitly
+ disallowed.
+
+ The permitUnSpecified field specifies how to handle attribute types
+ that are not present in either the permittedAttrs or excludedAttrs
+ fields. TRUE (the default) means that any unspecified attribute type
+ is allowed in ACs; FALSE means that no unspecified attribute type is
+ allowed.
+
+ When AAControls are used, the following additional checks on an AA's
+ PKC chain MUST all succeed for the AC to be valid:
+
+ 1. Some CA on the AC's certificate path MUST be directly trusted to
+ issue PKCs that precede the AC issuer in the certification path;
+ call this CA the "AA CA".
+
+ 2. All PKCs on the path from the AA CA, down to and including the AC
+ issuer's PKC, MUST contain an AAControls extension; however, the
+ PKC of the AA CA need not contain this extension.
+
+ 3. Only those attributes in the AC that are allowed, according to all
+ of the AAControls extension values in all of the PKCs from the AA
+ CA to the AC issuer, may be used for authorization decisions; all
+ other attributes MUST be ignored. This check MUST be applied to
+ the list of attributes following attribute decryption, and the id-
+ aca-encAttrs type MUST also be checked.
+
+ name id-pe-aaControls
+ OID { id-pe 6 }
+ syntax AAControls
+ criticality MAY be TRUE
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 34]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+8. Security Considerations
+
+ The protection afforded for 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 by 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 an 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 issuers 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 that 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 ACs, 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.
+
+
+
+Farrell, et al. Standards Track [Page 35]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ If an attribute certificate is tied to the holder's PKC using the
+ baseCertificateID component of the Holder field and the PKI in use
+ includes a rogue CA with the same issuer name specified in the
+ baseCertificateID component, this rogue CA could issue a PKC to a
+ malicious party, using the same issuer name and serial number as the
+ proper holder's PKC. Then the malicious party could use this PKC in
+ conjunction with the AC. This scenario SHOULD be avoided by properly
+ managing and configuring the PKI so that there cannot be two CAs with
+ the same name. Another alternative is to tie ACs to PKCs using the
+ publicKeyCert type in the ObjectDigestInfo field. Failing this, AC
+ verifiers have to establish (using other means) that the potential
+ collisions cannot actually occur, for example, the Certificate
+ Practice Statements (CPSs) of the CAs involved may make it clear that
+ no such name collisions can occur.
+
+ Implementers MUST ensure that following validation of an AC, only
+ attributes that the issuer is trusted to issue are used in
+ authorization decisions. Other attributes, which MAY be present MUST
+ be ignored. Given that the AAControls PKC extension is optional to
+ implement, AC verifiers MUST be provided with this information by
+ other means. Configuration information is a likely alternative
+ means. This becomes very important if an AC verifier trusts more
+ than one AC issuer.
+
+ There is often a requirement to map between the authentication
+ supplied by a particular security protocol (e.g., TLS, S/MIME) and
+ the AC holder's identity. If the authentication uses PKCs, then this
+ mapping is straightforward. However, it is envisaged that ACs will
+ also be used in environments where the holder may be authenticated
+ using other means. Implementers SHOULD be very careful in mapping
+ the authenticated identity to the AC holder, especially when the
+ authenticated identity does not come from a public key certificate as
+ link between identity and AC may not be as "strong".
+
+9. IANA Considerations
+
+ Attributes and attribute certificate extensions are identified by
+ object identifiers (OIDs). Many of the OIDs used in this document
+ are copied from X.509 [X.509-2000]. Other OIDs were assigned from an
+ arc delegated by the IANA to the PKIX working group. No further
+ action by the IANA is necessary for this document or any anticipated
+ updates.
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 36]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+10. References
+
+10.1. Reference Conventions
+
+ [PKIXALGS] refers to [RFC3279], [RFC4055], [RFC5480], and [RFC5756].
+
+10.2. Normative References
+
+ [Err302] RFC Errata, Errata ID 302, RFC 3281,
+ http://www.rfc-editor.org.
+
+ [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 5652, September 2009.
+
+ [HTTP-URL] Housley, R. and P. Hoffman, "Internet X.509 Public Key
+ Infrastructure Operational Protocols: FTP and HTTP",
+ RFC 2585, May 1999.
+
+ [LDAP-URL] Smith, M., Ed., and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 3279, April 2002.
+
+ [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
+ Algorithms and Identifiers for RSA Cryptography for
+ use in the Internet X.509 Public Key Infrastructure
+ Certificate and Certificate Revocation List (CRL)
+ Profile", RFC 4055, June 2005.
+
+ [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T.
+ Polk, "Elliptic Curve Cryptography Subject Public Key
+ Information", RFC 5480, March 2009.
+
+ [RFC5756] Turner, S. Brown, D., Yiu, K., Housley, R., and T.
+ Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm
+ Parameters", RFC 5756, January 2010.
+
+ [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 5280, May 2008.
+
+
+
+Farrell, et al. Standards Track [Page 37]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ [X509-SRV] Santesson, S., "Internet X.509 Public Key
+ Infrastructure Subject Alternative Name for Expression
+ of Service Name", RFC 4985, August 2007.
+
+ [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC
+ 8824-1:2002, Information technology - Abstract Syntax
+ Notation One (ASN.1): Specification of basic
+ notation.
+
+ [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC
+ 8825-1:2002, Information technology - ASN.1 encoding
+ rules: Specification of Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER) and Distinguished
+ Encoding Rules (DER).
+
+10.2. Informative References
+
+ [KRB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)", RFC
+ 4120, July 2005.
+
+ [LDAP] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
+ C. Adams, "X.509 Internet Public Key Infrastructure
+ Online Certificate Status Protocol - OCSP", RFC 2560,
+ June 1999.
+
+ [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
+ Certificate Profile for Authorization", RFC 3281,
+ April 2002.
+
+ [X.500-2000] ITU-T Recommendation X.500 (2000) | ISO/IEC
+ 9594-1:2000, Information technology - Open Systems
+ Interconnection - The Directory: Overview of concepts,
+ models and services.
+
+ [X.501-1993] ITU-T Recommendation X.501 (1993) | ISO/IEC
+ 9594-2:1993, Information technology - Open Systems
+ Interconnection - The Directory: Models.
+
+ [X.501-1997] ITU-T Recommendation X.501 (1997) | ISO/IEC
+ 9594-2:1997, Information technology - Open Systems
+ Interconnection - The Directory: Models.
+
+ [X.509-1988] CCITT Recommendation X.509: The Directory -
+ Authentication Framework, 1988.
+
+
+
+Farrell, et al. Standards Track [Page 38]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ [X.509-1997] ITU-T Recommendation X.509: The Directory -
+ Authentication Framework, 1997.
+
+ [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key
+ and Attribute Certificate Frameworks, 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 39]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+Appendix A. Object Identifiers
+
+ This (normative) appendix lists the new object identifiers that are
+ defined in this specification. Some of these are required only for
+ support of optional features and are not required for conformance to
+ this profile. This specification mandates support for OIDs that have
+ arc elements with values that are less than 2^32, (i.e., they MUST be
+ between 0 and 4,294,967,295 inclusive) and SHOULD be less than 2^31
+ (i.e., less than or equal to 2,147,483,647). This allows each arc
+ element to be represented within a single 32-bit word.
+ Implementations MUST also support OIDs where the length of the dotted
+ decimal (see [LDAP], Section 4.1.2) string representation can be up
+ to 100 bytes (inclusive). Implementations MUST be able to handle
+ OIDs with up to 20 elements (inclusive). AAs SHOULD NOT issue ACs
+ that contain OIDs that breach these requirements.
+
+ The following OIDs are imported from [PKIXPROF]:
+
+ id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+ id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
+ id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
+ id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+ 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:
+
+ id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
+
+ The following AC extension OIDs are defined:
+
+ id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
+ id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
+ id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
+
+ The following PKC extension OIDs are defined:
+
+ id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
+
+ The following attribute OIDs are defined:
+
+ id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
+ id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
+ id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
+ id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
+ id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
+ id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
+
+
+
+Farrell, et al. Standards Track [Page 40]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
+ id-at-clearance OBJECT IDENTIFIER ::= {
+ joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
+ id-at-clearance OBJECT IDENTIFIER ::= {
+ joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
+ clearance (55) }
+
+ As noted in Section 4.4.6, there are two OIDs for id-at-clearance.
+
+Appendix B. ASN.1 Module
+
+ This appendix describes data objects used by conforming PKI
+ components in an "ASN.1-like" syntax [X.680]. This syntax is a
+ hybrid of the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is
+ augmented with 1993 UNIVERSAL Types UniversalString, BMPString, and
+ UTF8String.
+
+ The ASN.1 syntax does not permit the inclusion of type statements in
+ the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
+ the new UNIVERSAL types in modules using the 1988 syntax. As a
+ result, this module does not conform to either version of the ASN.1
+ standard.
+
+ This appendix may be converted into 1988 ASN.1 by replacing the
+ definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
+
+ PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-mod-attribute-cert-v2(61) }
+
+ DEFINITIONS IMPLICIT TAGS ::=
+
+ BEGIN
+
+ -- EXPORTS ALL --
+
+ IMPORTS
+
+ -- IMPORTed module OIDs MAY change if [PKIXPROF] changes
+ -- PKIX Certificate Extensions
+
+ Attribute, AlgorithmIdentifier, CertificateSerialNumber,
+ Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
+ FROM PKIX1Explicit88
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-pkix1-explicit-88(18) }
+
+
+
+
+Farrell, et al. Standards Track [Page 41]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
+ AuthorityInfoAccessSyntax, CRLDistributionPoint
+ FROM PKIX1Implicit88
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-pkix1-implicit-88(19) }
+
+ ContentInfo
+ FROM CryptographicMessageSyntax2004
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+ smime(16) modules(0) cms-2004(24) }
+
+ ;
+
+ id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
+
+ id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
+
+ id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
+
+ id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
+
+ id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
+
+ id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
+
+ id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
+
+ id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
+
+ id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
+
+
+ -- { id-aca 5 } is reserved
+
+ 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) attributeType(4) clearance (55) }
+
+ -- Uncomment the following declaration and comment the above line if
+ -- using the id-at-clearance attribute as defined in [RFC3281]
+
+ -- id-at-clearance OBJECT IDENTIFIER ::= {
+ -- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
+ -- clearance (55) }
+
+
+
+Farrell, et al. Standards Track [Page 42]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ -- Uncomment this if using a 1988 level ASN.1 compiler
+
+ -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
+
+ AttributeCertificate ::= SEQUENCE {
+ acinfo AttributeCertificateInfo,
+ signatureAlgorithm AlgorithmIdentifier,
+ signatureValue BIT STRING
+ }
+
+ AttributeCertificateInfo ::= SEQUENCE {
+ version AttCertVersion, -- version is v2
+ holder Holder,
+ issuer AttCertIssuer,
+ signature AlgorithmIdentifier,
+ serialNumber CertificateSerialNumber,
+ attrCertValidityPeriod AttCertValidityPeriod,
+ attributes SEQUENCE OF Attribute,
+ issuerUniqueID UniqueIdentifier OPTIONAL,
+ extensions Extensions OPTIONAL
+ }
+
+ AttCertVersion ::= INTEGER { v2(1) }
+
+ Holder ::= SEQUENCE {
+ baseCertificateID [0] IssuerSerial OPTIONAL,
+ -- the issuer and serial number of
+ -- the holder's Public Key Certificate
+ entityName [1] GeneralNames OPTIONAL,
+ -- the name of the claimant or role
+ objectDigestInfo [2] ObjectDigestInfo OPTIONAL
+ -- used to directly authenticate the
+ -- holder, for example, an executable
+ }
+
+ ObjectDigestInfo ::= SEQUENCE {
+ digestedObjectType ENUMERATED {
+ publicKey (0),
+ publicKeyCert (1),
+ otherObjectTypes (2) },
+ -- otherObjectTypes MUST NOT
+ -- MUST NOT be used in this profile
+ otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
+ digestAlgorithm AlgorithmIdentifier,
+ objectDigest BIT STRING
+ }
+
+
+
+
+
+Farrell, et al. Standards Track [Page 43]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ AttCertIssuer ::= CHOICE {
+ v1Form GeneralNames, -- MUST NOT be used in this
+ -- profile
+ v2Form [0] V2Form -- v2 only
+ }
+
+ V2Form ::= SEQUENCE {
+ issuerName GeneralNames OPTIONAL,
+ baseCertificateID [0] IssuerSerial OPTIONAL,
+ objectDigestInfo [1] ObjectDigestInfo OPTIONAL
+ -- issuerName MUST be present in this profile
+ -- baseCertificateID and objectDigestInfo MUST
+ -- NOT be present in this profile
+ }
+
+ IssuerSerial ::= SEQUENCE {
+ issuer GeneralNames,
+ serial CertificateSerialNumber,
+ issuerUID UniqueIdentifier OPTIONAL
+ }
+
+ AttCertValidityPeriod ::= SEQUENCE {
+ notBeforeTime GeneralizedTime,
+ notAfterTime GeneralizedTime
+ }
+
+ Targets ::= SEQUENCE OF Target
+
+ Target ::= CHOICE {
+ targetName [0] GeneralName,
+ targetGroup [1] GeneralName,
+ targetCert [2] TargetCert
+ }
+
+ TargetCert ::= SEQUENCE {
+ targetCertificate IssuerSerial,
+ targetName GeneralName OPTIONAL,
+ certDigestInfo ObjectDigestInfo OPTIONAL
+ }
+
+ IetfAttrSyntax ::= SEQUENCE {
+ policyAuthority [0] GeneralNames OPTIONAL,
+ values SEQUENCE OF CHOICE {
+ octets OCTET STRING,
+ oid OBJECT IDENTIFIER,
+ string UTF8String
+ }
+ }
+
+
+
+Farrell, et al. Standards Track [Page 44]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ SvceAuthInfo ::= SEQUENCE {
+ service GeneralName,
+ ident GeneralName,
+ authInfo OCTET STRING OPTIONAL
+ }
+
+ RoleSyntax ::= SEQUENCE {
+ roleAuthority [0] GeneralNames OPTIONAL,
+ roleName [1] GeneralName
+ }
+
+ Clearance ::= SEQUENCE {
+ policyId OBJECT IDENTIFIER,
+ classList ClassList DEFAULT {unclassified},
+ securityCategories SET OF SecurityCategory OPTIONAL
+ }
+
+ -- Uncomment the following lines to support deprecated clearance
+ -- syntax and comment out previous Clearance.
+
+ -- Clearance ::= SEQUENCE {
+ -- policyId [0] OBJECT IDENTIFIER,
+ -- classList [1] ClassList DEFAULT {unclassified},
+ -- securityCategories [2] SET OF SecurityCategory OPTIONAL
+ -- }
+
+
+
+ ClassList ::= BIT STRING {
+ unmarked (0),
+ unclassified (1),
+ restricted (2),
+ confidential (3),
+ secret (4),
+ topSecret (5)
+ }
+
+ SecurityCategory ::= SEQUENCE {
+ type [0] OBJECT IDENTIFIER,
+ value [1] EXPLICIT ANY DEFINED BY type
+ }
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 45]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ -- Note that in [RFC3281] the syntax for SecurityCategory was
+ -- as follows:
+ --
+ -- SecurityCategory ::= SEQUENCE {
+ -- type [0] IMPLICIT OBJECT IDENTIFIER,
+ -- value [1] ANY DEFINED BY type
+ -- }
+ --
+ -- The removal of the IMPLICIT from the type line and the
+ -- addition of the EXPLICIT to the value line result in
+ -- no changes to the encoding.
+
+ AAControls ::= SEQUENCE {
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL,
+ permittedAttrs [0] AttrSpec OPTIONAL,
+ excludedAttrs [1] AttrSpec OPTIONAL,
+ permitUnSpecified BOOLEAN DEFAULT TRUE
+ }
+
+ AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER
+
+ ACClearAttrs ::= SEQUENCE {
+ acIssuer GeneralName,
+ acSerial INTEGER,
+ attrs SEQUENCE OF Attribute
+ }
+
+ ProxyInfo ::= SEQUENCE OF Targets
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 46]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+Appendix C. Errata Report Submitted to RFC 3281
+
+ The following is the errata report submitted against RFC 3281, posted
+ online as [Err302].
+
+ Status: Verified
+
+ Type: Technical
+
+ Reported By: Stephen Farrell
+
+ Date Reported: 2003-03-07
+
+ Section 4.4.6 says:
+
+ Clearance ::= SEQUENCE {
+ policyId [0] OBJECT IDENTIFIER,
+ classList [1] ClassList DEFAULT {unclassified},
+ securityCategories [2] SET OF SecurityCategory OPTIONAL
+ }
+
+ It should say:
+
+ Clearance ::= SEQUENCE {
+ policyId OBJECT IDENTIFIER,
+ classList ClassList DEFAULT {unclassified},
+ securityCategories SET OF SecurityCategory OPTIONAL
+ }
+
+ Notes:
+
+ The differences in tagging arose due to an unnoticed technical
+ corrigendum (TC-2) being applied to the X.501 document during
+ preparation of RFC 3281. The X.501 format is the correct form and
+ will be included in a future update of RFC 3281. Implementers SHOULD
+ modify their decoding functions to accept either format and, even if
+ claiming RFC 3281 conformance, SHOULD output the (correct) X.501
+ format pending the issuing of a corrected RFC at which point the
+ incorrect RFC 3281 format will no longer be specified.
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 47]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+Appendix D. Changes since RFC 3281
+
+ 1. Created a new Section 1.1 "Terminology", renumbered Sections
+ 1.1-1.3 to 1.2-1.4, and moved first paragraph of Section 1 to
+ Section 1.1.
+
+ 2. In Section 1.2, rephrased first sentence in third paragraph.
+
+ 3. In Section 2, replaced S/MIME v3 with S/MIME v3.2.
+
+ 4. In Section 4.1, moved "," from the right of the ASN.1 comment to
+ the left of the ASN.1 comment on the line describing version in
+ the AttributeCertificateInfo structure. Replaced reference to
+ X.208 with X.690.
+
+ 5. In Section 4.2, replaced pointer to 4.2.1.7 of RFC 3280 with
+ pointer to 4.2.1.6 of RFC 5280. Added requirement to support
+ subject alternative name choice SRVName.
+
+ 6. In Section 4.3.2, replaced "Confirming" with "Conforming".
+
+ 7. In Section 4.3.4, replaced reference to RFC 1738, URL, with
+ references to [HTTP-URL], "authorityInformationAccess" with
+ "authorityInfoAccess", and "NOT REQUIRED" with "OPTIONAL."
+
+ 8. In Section 4.3.5, replaced "HTTP or an LDAP" with "HTTP [HTTP-URL]
+ or an LDAP [LDAP-URL]". Also, replaced "CRLDistPointsSyntax" with
+ "CRLDistributionPoints".
+
+ 9. In Section 4.4.6, added text to address having two OIDs for the
+ same syntax and two syntaxes for one OID.
+
+ 10. In Section 5, replaced "When the extension value SHOULD cause"
+ with "When the extension value causes".
+
+ 11. In Section 7.1, replaced text that described encapsulating
+ encrypted attribute with corrected text. Clarified that
+ attributes can appear more than once if they apply to different
+ recipients. Reworded last paragraph to more clearly describe the
+ failure case.
+
+ 12. In Section 7.3, updated references to point to RFC 3279.
+
+ 13. In Section 8, updated last paragraph to better explain why
+ implementers need to be careful when mapping authenticated
+ identities to the AC holder.
+
+
+
+
+
+Farrell, et al. Standards Track [Page 48]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+ 14. Updated References:
+ a) split references into informative/normative references
+ b) added reference to RFC 3281
+ c) replaced reference to X.501:1993 with X.501:1997
+ d) replaced reference to RFC 1510 with RFC 4120
+ e) replaced reference to RFC 1738 with RFC 4516 and 2585
+ f) replaced reference to RFC 2251 with RFC 4511
+ g) replaced reference to RFC 2459 with RFC 5280
+ h) replaced reference to RFC 2630 with RFC 5652
+ i) replaced reference to X.208-1988 with X.690
+ j) added reference to X.680
+ k) added reference to RFC 4985
+ l) expanded reference to RFC 3279 by adding RFC 5480 and RFC
+ 4055, which update RFC 3279
+ m) deleted spurious reference to CMC, CMP, ESS, RFC 2026,
+ X.209-88, and X.501:1988.
+
+ 15. In Appendix A, added second clearance attribute object
+ identifier.
+
+ 16. Appendix B, updated ASN.1 with changes 3, 8, 9, and 11:
+ a) New OID for ASN.1 module.
+ b) Updated module OIDs for PKIX1Explicit88 and PKIX1Implicit88.
+ c) Added imports from PKIX1Implicit88 for AuthorityKeyIdentifier,
+ AuthorityInfoAccessSyntax, CRLDistributionPoint.
+ d) Added imports from CryptographicMessageSyntax2004 for
+ ContentInfo.
+ e) Added comments and commented out ASN.1 for old clearance
+ attribute syntax.
+ f) Added preamble to ASN.1, which is taken from Appendix A of RFC
+ 5280.
+
+ 17. Added Appendix C.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 49]
+
+RFC 5755 AC Profile for Authorization January 2010
+
+
+Authors' Addresses
+
+ Sean Turner
+ IECA, Inc.
+ 3057 Nutley Street, Suite 106
+ Fairfax, VA 22031
+ USA
+ EMail: turners@ieca.com
+
+ Russ Housley
+ Vigil Security, LLC
+ 918 Spring Knoll Drive
+ Herndon, VA 20170
+ USA
+ EMail: housley@vigilsec.com
+
+ Stephen Farrell
+ Distributed Systems Group
+ Computer Science Department
+ Trinity College Dublin
+ Ireland
+ EMail: stephen.farrell@cs.tcd.ie
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Standards Track [Page 50]
+