RFC 3281
An Internet Attribute Certificate Profile for Authorization
RFC 3281: An Internet Attribute Certificate Profile for Authorization 🎀
Okay bestie, this one is from April 2002 and it's a Standards Track doc, so it's an actual spec people build on, not just vibes. 💅 Written by S. Farrell (Baltimore Technologies) and R. Housley (RSA Laboratories). It's part of the Network Working Group, and it doesn't obsolete or update anything listed in its header. Let's get into it ✨
Status of This Memo 📜
This is an Internet standards track protocol for the Internet community, and it's asking everyone to talk about it and suggest improvements 🫶 If you want the official standardization state of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed freely, no limits 🦋
Copyright Notice 🌸
Copyright (C) The Internet Society (2002). All Rights Reserved. Mine, yours, nobody's, it's all protected 💜
Abstract 🧚
So this spec defines how to use X.509 Attribute Certificates in Internet protocols. Attribute certificates can show up in a ton of different apps and environments, with all kinds of interop goals and some seriously varied operational and assurance needs 😭 The big goal here is a shared baseline for generic apps that need broad interop, plus room for narrow special-purpose stuff. The profile puts extra focus on attribute certificates for Internet email, IPSec, and WWW security apps 🔥
Table of Contents 🍓
1. Introduction................................................. 2
1.1 Delegation and AC chains............................... 4
1.2 Attribute Certificate Distribution ("push" vs. "pull"). 4
1.3 Document Structure..................................... 6
2. Terminology.................................................. 6
3. Requirements................................................. 7
4. Attribute Certificate Profile................................ 7
4.1 X.509 Attribute Certificate Definition................. 8
4.2 Profile of Standard Fields............................. 10
4.2.1 Version.......................................... 10
4.2.2 Holder........................................... 11
4.2.3 Issuer........................................... 12
4.2.4 Signature........................................ 12
4.2.5 Serial Number.................................... 12
4.2.6 Validity Period.................................. 13
4.2.7 Attributes....................................... 13
4.2.8 Issuer Unique Identifier......................... 14
4.2.9 Extensions....................................... 14
4.3 Extensions............................................. 14
4.3.1 Audit Identity................................... 14
4.3.2 AC Targeting..................................... 15
4.3.3 Authority Key Identifier......................... 17
4.3.4 Authority Information Access..................... 17
4.3.5 CRL Distribution Points.......................... 17
4.3.6 No Revocation Available.......................... 18
4.4 Attribute Types........................................ 18
4.4.1 Service Authentication Information............... 19
4.4.2 Access Identity.................................. 19
4.4.3 Charging Identity................................ 20
4.4.4 Group............................................ 20
4.4.5 Role............................................. 20
4.4.6 Clearance........................................ 21
4.5 Profile of AC issuer's PKC............................. 22
5. Attribute Certificate Validation............................. 23
6. Revocation................................................... 24
7. Optional Features............................................ 25
7.1 Attribute Encryption................................... 25
7.2 Proxying............................................... 27
7.3 Use of ObjectDigestInfo................................ 28
7.4 AA Controls............................................ 29
8. Security Considerations...................................... 30
9. IANA Considerations.......................................... 32
10. References.................................................. 32
Appendix A: Object Identifiers.................................. 34
Appendix B: ASN.1 Module........................................ 35
Author's Addresses.............................................. 39
Acknowledgements................................................ 39
Full Copyright Statement........................................ 401. Introduction ✨
Okay so first things first: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way BCP 14, RFC 2119 says 🎀
Now, X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, PKIXPROF] bind an identity to a public key 🔑 An attribute certificate (AC) is kind of a cousin of a PKC, with one big difference: the AC has no public key in it 💅 An AC can hold attributes like group membership, role, security clearance, or other authorization info tied to the AC holder. The syntax for the AC lives in Recommendation X.509, which is why just saying "X.509 certificate" is ambiguous, bestie 🙈
Some people constantly mix up PKCs and ACs, so here's an analogy that clicks 🦋 A PKC is like a passport: it identifies you, it lasts a long time, and it shouldn't be trivial to get. An AC is more like an entry visa: a different authority usually issues it, and it doesn't last as long. And since you usually need a passport to get a visa, getting the visa can be the easier process 🛂
So where does authorization info go? It can sit in a PKC extension or in its own separate attribute certificate (AC). Putting it in PKCs is usually a bad idea, and there are two reasons 😭 First, authorization info often doesn't have the same lifetime as the identity-to-key binding. Stuffing it in a PKC extension generally shortens how long that PKC is actually useful. Second, the PKC issuer usually isn't the authoritative source for the authorization info, so the PKC issuer has to take extra steps to go grab it from the authoritative source. Major main character energy for the wrong party 💀
That's why it's often better to split authorization info away from the PKC. But the authorization info still needs to be bound to an identity, and that's exactly what an AC does 🫶 It's basically a digitally signed (or certified) identity plus a set of attributes.
An AC can be used with various security services, including access control, data origin authentication, and non-repudiation 👑
PKCs can give an identity to access control decision functions. But in lots of contexts, the identity isn't what decides access. Instead, the role or group membership of the accessor is the thing that matters, and those access control schemes are called role-based access control 🌈
When an access control decision is made based on an AC, the decision function may need to make sure the right AC holder is the one asking for access. One way to link the request or identity to the AC is to include a reference to a PKC inside the AC, and then use the private key that matches that PKC to authenticate within the access request 🔐
ACs can also show up in data origin authentication and non-repudiation services. In those cases, the attributes in the AC give extra info about the signing entity, and that info can be used to check that the entity is authorized to sign the data. That checking depends either on the context the data is exchanged in, or on the data that got digitally signed ✍️
1.1 Delegation and AC chains 🔗
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, bestie 🌸
An ordered sequence of ACs could be used to verify that a privilege asserter really has the privilege they claim. So chains or paths of ACs could be used to delegate authorization 🧚
BUT the admin and processing for these AC chains is pretty complex, and ACs aren't widely used on the Internet yet, so this specification does NOT RECOMMEND the use of AC chains. Future specs might cover AC chains, so stay tuned 👀 This spec focuses on the simple cases, where one authority issues all of the ACs for a particular set of attributes. That simplification doesn't rule out using several different authorities, though, with each one managing a different set of attributes. For example, group membership could be in one AC from one authority, and security clearance could be in a different AC from another authority 💖
So conformant implementations are only REQUIRED to be able to process a single AC at a time. Processing 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.2 Attribute Certificate Distribution ("push" vs. "pull") ✨
okay so we already know ACs are a secure way to hand authorization info to things like access control decision functions 🔐. but there are a bunch of different routes an AC can take to get where it's going 🛣️
first up is the push model 💌. here the client just sends its AC straight to the server. no new connections between client and server are needed, the server doesn't have to go hunting for anything (performance ✨), and the AC verifier only gets what it "needs to know." push is especially giving for inter-domain cases where the client's rights get assigned inside the client's own "home" domain 🏠.
then there's the pull model 🧲. here the client just authenticates to the server, and the server goes and grabs the client's AC from an AC issuer or a repository. the big perk is that pull works without changing the client or the client-server protocol. it's especially good for inter-domain cases where the rights get assigned inside the server's domain instead of the client's 💅.
there are a bunch of possible exchanges between three players: the client, the server, and the AC issuer. a directory service or other repository for AC retrieval MAY be supported 📂. Figure 1 is the big-picture view of all the AC exchanges. this profile does not specify a protocol for any of them, so no spoilers 🙈
+--------------+
| | Server Acquisition
| AC issuer +----------------------------+
| | |
+--+-----------+ |
| |
| Client |
| Acquisition |
| |
+--+-----------+ +--+------------+
| | AC "push" | |
| Client +-------------------------+ Server |
| | (part of app. protocol) | |
+--+-----------+ +--+------------+
| |
| Client | Server
| Lookup +--------------+ | Lookup
| | | |
+---------------+ Repository +---------+
| |
+--------------+
Figure 1: AC Exchanges1.3 Document Structure 🗺️
here's the tour. Section 2 defines some terminology. Section 3 lays out the requirements this profile is meant to meet. Section 4 has the profile of the X.509 AC. Section 5 covers the rules for AC validation, and Section 6 covers the rules for AC revocation checks. Section 7 is the optional stuff: features that MAY be supported, but support for them is not required for conformance to this profile 🎀. last but not least, the appendices hold the list of OIDs needed to support this spec, plus an ASN.1 module 🧚
2. Terminology 📖
okay so in this spec we just say "client" and "server" to keep things simple. that does NOT mean ACs only live in client-server setups 🙅♀️. for example, ACs can show up in the S/MIME v3 context, where the mail user agent is both a "client" and a "server" in the sense these terms are used here 💜
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 which 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 which 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 type ASN.1
Certificate defined in X.509 and profiled in RFC
2459. This (non-standard) acronym is used in order
to avoid confusion about the term "X.509
certificate".
Server the entity which requires that the authorization
checks are made3. Requirements 🎯
this AC profile has to hit the following requirements, bestie 💅
Time/Validity requirements:
- support for short-lived AND long-lived ACs. short ones might last hours, while PKCs are more like months. short validity periods let ACs work without a revocation mechanism ⏳
Attribute Types:
- issuers of ACs should be able to define their own attribute types for use inside closed domains 🔒
- some standard attribute types that can go inside ACs should be defined. examples are "access identity," "group," "role," "clearance," "audit identity," and "charging identity" 📋
- standard attribute types should be defined in a way that lets an AC verifier tell apart uses of the same attribute in different domains. like, the "Administrators group" from Baltimore and the "Administrators group" from SPYRUS should be easy to tell apart 👀
Targeting of ACs:
- it should be possible to "target" an AC at one server, or a small number of them. that means a trustworthy non-target server will reject the AC for authorization decisions 🚫
Push vs. Pull:
- ACs should be defined so they can 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 can be used in a huge range of apps and environments, with all kinds of interoperability goals and even bigger spreads of operational and assurance needs 🌈. the aim of this doc is to set a common baseline for generic apps that need broad interoperability plus a few special-purpose extras. specifically, the focus is on supporting attribute certificates for informal Internet electronic mail, IPSec, and WWW applications 💌
this section gives a profile for ACs that helps everyone interoperate. it also defines some private extensions for the Internet community 🧚
so the ISO/IEC/ITU docs use the 1993 (or later) version of ASN.1, but this doc uses the 1988 ASN.1 syntax, same as what was done for PKCs [PKIXPROF]. the encoded certificates and extensions from either ASN.1 version come out bit-wise identical, so no drama 🤍
when a maximum length is specified for a field, that length refers to the DER encoding and does 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 has the definition of an AC shown below. any types that aren't 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
}
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
}the Attribute syntax is actually defined in [PKIXPROF], but we copy it here so it's handy 🫶
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeTypeimplementers, pay attention to this one 🔥. the DER encoding (see [X.509-1988],[X.208-1988]) of the SET OF values needs the encodings of the values to be ordered. this comes up with distinguished names too, and [PKIXPROF] implementations have to handle it there. but it matters way more here, because ACs very commonly include multiple values 💀
4.2. Profile of Standard Fields 💅
Okay bestie, GeneralName is giving main character energy with how flexible it is ✨ But if everyone picks different options, nothing talks to anything else 💀 So this profile adds some constraints to keep things interoperable 🫶
Conforming implementations MUST be able to support the dNSName, directoryName, uniformResourceIdentifier, and iPAddress options 🌸 This lines up with the GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7).
Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options 🚫 No exceptions, periodt.
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 🦋
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 ✨ When only one option is present, the meaning of the Holder field is crystal clear. But when more than one option is used, it gets messy, because nobody knows which option is "normative", which one is just 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 which 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]) which 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 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 💅 Also, ACs conforming to this profile MUST omit the baseCertificateID and objectDigestInfo fields 🙈
Part of the reason for using the v2Form containing only an issuerName is 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]. Conforming implementations MUST honor all MUST/SHOULD/MAY signing algorithm statements specified in [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 ⏳
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 🔑
The attributes field contains a SEQUENCE OF Attribute. Each Attribute MAY contain 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 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 which might prevent use in a general context 🥹✨
4.3 Extensions
4.3.1 Audit Identity 🙈
Okay so sometimes the law (data protection and privacy stuff) says audit trails can't have records that directly identify individuals 😭. That means the AC holder field might be a no-go for audit logs. Not it, bestie.
So to handle that, an AC MAY contain an audit identity extension. Ideally it SHOULD be infeasible to work out the AC holder's identity from the audit identity value without the cooperation of the AC issuer 🔐.
The audit identity value, along with the AC issuer/serial, SHOULD then be used for audit and logging. If the audit identity is chosen well, a server/service administrator can track what an AC holder is doing in the logs without being able to tell who they are. main character privacy 💅
BUT the server/service administrator together with the AC issuer MUST be able to identify the AC holder when misbehavior is detected. That means the AC issuer MUST be able to determine the actual identity of the AC holder from the audit identity. Accountability is still the vibe 🙃.
Of course, auditing could be based on the AC issuer/serial pair. The catch is that this doesn't let you track the same AC holder across multiple ACs. So an audit identity is only useful if it lasts longer than the typical AC lifetime ⏳. Auditing could also be based on the AC holder's PKC issuer/serial, but that will often let the server/service administrator 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 those cases, an opaque audit identity does not make the AC anonymous. It just makes sure the audit trails don't contain identifying information 🧚 not the same thing, bestie.
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 TRUE4.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. Not cute 🙅♀️.
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 there to allow future compatibility with [X.509-2000], and it 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 ✨.
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 it belongs to, or can otherwise determine its membership. For example, the targetGroup specifies a DNS domain, and the AC verifier knows the DNS domain it belongs to. 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. Confirming 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 TRUE4.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, since 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, so this duplication does not come up 🙌.
name id-ce-authorityKeyIdentifier
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE4.3.4 Authority Information Access 🧭
The authorityInformationAccess 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 NOT REQUIRED by this profile, since AC chains are not expected 🙅.
The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the OCSP protocol 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 [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 FALSE4.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 or an LDAP URL [URL]. So many MUSTs, the rules are strict 😤.
name id-ce-cRLDistributionPoints
OID { id-ce 31 }
syntax CRLDistPointsSyntax
criticality MUST be FALSE4.3.6 No Revocation Available 🫥
The noRevAvail extension, defined in [X.509-2000], lets an AC issuer 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. Ngl, that's a little sad 💀.
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e. '0500'H is the DER encoding)
criticality MUST be FALSE4.4. Attribute Types 💖
Okay so some of the attribute types down below use the IetfAttrSyntax type, which is also defined right here 🎀. Why bother? Two big reasons, bestie:
- It lets the AC issuer and the attribute policy authority be different things 🫶. This is clutch when one policy authority (like an org) allocates the attribute values, but there are multiple AC issuers deployed for performance or other reasons.
- The allowed value syntaxes are limited to OCTET STRING, OBJECT IDENTIFIER, and UTF8String, which seriously cuts down the complexity of matching 💅. All multi-valued attributes using this syntax are restricted so that each value MUST use the same choice of value syntax. Like, 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
}
}Down below, each attribute type is tagged either Multiple Allowed or One Attribute value only; multiple values within the IetfAttrSyntax 🏷️. That tag is about the SET OF AttributeValues, not the AttributeType, which still only shows up once, just like section 4.2.7 says.
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 is a username/password pair for a "legacy" application 🦖.
This attribute gives the AC verifier something it can present, so a separate application inside the target system can interpret and authenticate it. Note that this is a different use from the one 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. 😭
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 meant to carry info about the AC holder, which the AC verifier (or a bigger system the AC verifier is part of) can use to authorize the holder's actions inside the AC verifier's system ✨. Note that this is a different use from the svceAuthInfo attribute described in 4.4.1 above.
name id-aca-accessIdentity
OID { id-aca 2 }
syntax SvceAuthInfo
values: Multiple allowed4.4.3. Charging Identity 💸
The chargingIdentity attribute identifies the AC holder for charging purposes. Generally, the charging identity will be different from the holder's other identities. 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
IetfAttrSyntax4.4.4. Group 👯
The group attribute carries info about the AC holder's group memberships 🌸.
name id-aca-group
OID { id-aca 4 }
syntax IetfAttrSyntax
values: One Attribute value only; multiple values within the
IetfAttrSyntax4.4.5. Role 👑
The role attribute, specified in [X.509-2000], carries info about the AC holder's role allocations. The syntax used for it 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 is different from [X.500-2000], where the roleAuthority field is assumed to name the issuer of a role specification certificate 🧠. For example, to tell apart the administrator role as defined by "Baltimore" from the one defined by "SPYRUS", you could put the value "urn:administrator" in the roleName field and the value "Baltimore" or "SPYRUS" in the roleAuthority field 🦋.
The roleName field MUST be present, and roleName MUST use the uniformResourceIdentifier CHOICE of the GeneralName 📌.
name id-at-role
OID { id-at 72 }
syntax RoleSyntax
values: Multiple allowed4.4.6. Clearance 🕶️
The clearance attribute, specified in [X.501-1993], carries clearance information (associated with security labeling) about the AC holder.
The policyId field identifies the security policy the clearance relates to. 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 🧩.
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] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
-- 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) module(1)
selected-attribute-types(5) clearance (55) }
syntax Clearance - imported from [X.501-1993]
values Multiple allowed4.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 🔑. To avoid confusion about serial numbers and revocations, an AC issuer MUST NOT also be a PKC Issuer. In other words, 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 lays out a basic set of rules that all valid ACs MUST satisfy 📋. It also describes some additional checks that AC verifiers MAY choose to implement 🛠️.
To be valid, an AC MUST satisfy all of the following:
- 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 😱.
- The AC signature must be cryptographically correct, and the AC issuer's entire PKC certification path MUST be verified in accordance with [PKIXPROF].
- The AC issuer's PKC MUST also conform to the profile specified in section 4.5 above.
- The AC issuer MUST be directly trusted as an AC issuer (by configuration or otherwise).
- 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 ⏰.
- The AC targeting check MUST pass as specified in section 4.3.2.
- If the AC contains an unsupported critical extension, the AC MUST be rejected 🚫.
Support for an extension in this context means:
- The AC verifier MUST be able to parse the extension value.
- Where the extension value SHOULD cause the AC to be rejected, the AC verifier MUST reject the AC.
Additional Checks:
- The AC MAY be rejected on the basis of further AC verifier configuration. For example, an AC verifier may be configured to reject ACs which contain or lack certain attributes 🧹.
- 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 💅
okay so in lots of environments an AC only lives for a tiny window, shorter than the time it takes to issue and distribute revocation info 😭 so short-lived ACs usually don't need revocation support. BUT long-lived ACs and places where ACs power high value transactions MAY require revocation support 🔥
there are two revocation schemes, and the AC issuer should pick whichever one fits the environment the AC is going to live in ✨
"Never revoke" scheme:
ACs can be marked so the relying party knows no revocation status info will be 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.
If there's no noRevAvail, the AC issuer is implicitly saying revocation status checks are supported, so some revocation method MUST be provided to let AC verifiers establish the revocation status of the AC 🫶
"Pointer in AC" scheme:
ACs may "point" to sources of revocation status info, 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. 💀
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 and a "pointer in AC". 🙅♀️
An AC verifier MAY use any source for AC revocation status information. 🌈
7. Optional Features 🎀
this section covers 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 🔐
where an AC will be carried in clear within an application protocol, or where an AC contains some sensitive info like a legacy application username/password, then encryption of AC attributes MAY be needed 😬
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 the 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 🎯
the AC then contains the ciphertext inside its signed data. The EnvelopedData (id-envelopedData) ContentType is used, and the content field will contain the EnvelopedData type 💜
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 🍓
each value can contain a set of attributes (each possibly a multi-valued attribute) encrypted for a set of predetermined recipients 🫶
the cleartext that gets encrypted has this 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 there 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 stops a sketchy AC issuer from copying ciphertext from another AC (without knowing its plaintext) 🙅♀️
the procedure for an AC issuer when encrypting attributes is shown below. Any other procedure that gives the same result MAY be used 💅
- Identify the sets of attributes that are to be encrypted for each set of recipients.
- For each attribute set which 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.
- 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 means an AC MAY contain the same attribute type both in clear and in encrypted form (and even several times if the same recipient is tied to more than one EnvelopedData) 🌀 One approach implementers may choose is to merge attribute values after decryption, to re-establish the "once only" constraint ✨
name id-aca-encAttrs
OID { id-aca 6}
Syntax ContentInfo
values Multiple AllowedIf an AC contains attributes apparently encrypted for the AC verifier, the decryption process MUST not fail. If decryption does fail, the AC MUST 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 not every AC is proxiable, and 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 🔗
to meet this requirement we define another extension, ProxyInfo, which is similar to the targeting extension 💖
when this extension is present, the AC verifier must check that the entity the AC was received from was allowed to send it, and that the AC is allowed to be used by this verifier 🔍
the proxying info is a set of proxy info, and each one is a set of targeting info. If the verifier and the sender of the AC are both named in the same proxy set, the AC can then be accepted (the exact rule is 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 sets as itself 🦋
the following data structure represents the targeting/proxying info:
ProxyInfo ::= SEQUENCE OF TargetsAs in the case of targeting, the targetCert CHOICE MUST NOT be used. 🙈
a proxy check succeeds if either one of the conditions below is met:
- The identity of the sender, as established by the underlying authentication service, matches the holder field of the AC, and the current server "matches" any one of the proxy sets. Recall that "matches" is as defined in section 4.3.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, preventing 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 make sure 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 TRUE7.3 Use of ObjectDigestInfo 🧁
in some environments, the AC may be required to not be linked either to an identity (via entityName) or to a PKC (via baseCertificateID) 🙅♀️ The objectDigestInfo CHOICE in the holder field makes this possible 💜
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 putting a hash of that object into the holder field of the AC ✨ For example, this allows ACs to be linked to public keys instead of names. It also allows ACs that contain privileges tied to an executable object, like a Java class 🍵 However, this profile only specifies how to use a hash over a public key or PKC. That means conformant ACs MUST NOT use the otherObjectTypes value for the digestedObjectType. 🙅♀️
to link an AC to a public key, the hash must be calculated over the representation of that public key that 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 [PKIXPROF] 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 happen if DSA Dss-parms are inherited as described in section 7.3.3 of [PKIXPROF]. The correct input for hashing in this context will include the value of the parameters inherited from the CA's PKC, so it may differ from the SubjectPublicKeyInfo present in the PKC 🧩
implementations which support this feature MUST be able to handle the representations of public keys for the algorithms specified in section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present. 💅
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 🎀
Okay so bestie, during AC validation a relying party has to ask itself one big question: is this AC issuer actually trusted to issue ACs containing this attribute? 🤔 The AAControls PKC extension MAY be used to help answer that. It's meant to go in CA and AC issuer PKCs, and it's giving exactly that vibe. 💅
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 IDENTIFIERSo here's how AAControls works, periodt 🧚
pathLenConstraint, if it's there, gets read the same way [PKIXPROF] reads it. It limits how far apart the AA CA (the CA directly trusted to includeAAControlsin its PKCs) and the AC issuer can be. 📏permittedAttrsis a list of attribute types that any AC issuer below this AA CA is allowed to include in ACs. If this field isn't there, it means no attribute types are explicitly allowed. Not me saying nothing is allowed, just that nothing is explicitly allowed 🙈excludedAttrsis a list of attribute types that no AC issuer is allowed to include. If it's missing, nothing is explicitly disallowed. ✨permitUnSpecifieddecides what happens to attribute types that aren't in eitherpermittedAttrsorexcludedAttrs. TRUE (the default) means any unspecified attribute type is allowed in ACs. FALSE means no unspecified attribute type is allowed. 🍓
Now the big rule, bestie 😤 When AAControls are used, these extra checks on an AA's PKC chain MUST all succeed for the AC to be valid:
- Some CA on the ACs certificate path MUST be directly trusted to issue PKCs which precede the AC issuer in the certification path; call this CA the "AA CA". 👑
- All PKCs on the path from the AA CA, down to and including the AC issuer's PKC, MUST contain an
AAControlsextension. However, the AA CA's PKC need not contain this extension. 🫶 - Only those attributes in the AC which are allowed, according to all of the
AAControlsextension 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 set of attributes following attribute decryption, and theid-aca-encAttrstype MUST also be checked. 🔥
name id-pe-aaControls
OID { id-pe 6 }
syntax AAControls
criticality MAY be TRUE8. Security Considerations ✨
Okay this part is SERIOUS bestie 😭 Private keys are everything. The protection for them is a critical factor in keeping things secure. If AC issuers don't protect their private keys, an attacker can masquerade as them and generate false ACs or false revocation status 💀. Bogus ACs and bogus revocation status will undermine confidence in the whole system. If a compromise is detected, all ACs issued by the AC issuer MUST be revoked. Rebuilding after a compromise is going to 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 can also be a nightmare. The AC issuer wouldn't 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 how much assurance you should place in a long-lived AC. Long-lived ACs expire naturally, but events can happen during their 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 the 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 keep up with 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. 🙈
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. It would use 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 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 AA controls 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. 👀
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. No further action by the IANA is necessary for this document or any anticipated updates. 🌸
10. References 📚
- [CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
- [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure - Certificate Management Protocols", RFC 2510, March 1999.
- [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
- [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
- [KRB] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
- [LDAP] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
- [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.
- [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation Lists CRL Profile", RFC 3279, April 2002.
- [PKIXPROF] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [URL] Berners-Lee, T., Masinter L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
- [X.208-1988] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
- [X.209-88] CCITT Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
- [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1988.
- [X.501-1993] ITU-T Recommendation X.501 : Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
- [X.509-1988] CCITT Recommendation X.509: The Directory - Authentication Framework. 1988.
- [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
Appendix A: Object Identifiers 🦋
okay so this appendix is the list of all the brand new object identifiers 🆔 defined in this spec. Some of them are only needed if you're using optional features, so you don't need them to be conformant with this profile 💅. The spec also sets some size rules for OIDs. Implementations MUST support OIDs where every arc element is less than 2^32, which means they MUST be between 0 and 4,294,967,295 inclusive ✨. Ideally the arcs SHOULD be less than 2^31 (so less than or equal to 2,147,483,647), so each arc fits in a single 32 bit word 💖. Implementations MUST also support OIDs whose dotted decimal string (see [LDAP], section 4.1.2) is up to 100 bytes long, inclusive 📏. And implementations MUST be able to handle OIDs with up to 20 elements, inclusive 🧚. AA's SHOULD NOT issue ACs with OIDs that break these rules 🙅♀️.
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 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::=
{ joint-iso-ccitt(2) ds(5) module(1)
selected-attribute-types(5) clearance (55) }Appendix B: ASN.1 Module 🎀
this is the whole ASN.1 module, so grab a snack 🍓, it's a long one but it's all the definitions you need to actually build these things 💅.
PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert(12)}
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(1)}
GeneralName, GeneralNames, id-ce
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
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) module(1)
selected-attribute-types(5) clearance (55) }
-- Uncomment this if using a 1988 level ASN.1 compiler
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
AttributeCertificate ::= SEQUENCE {
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
}
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
}
}
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
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] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ProxyInfo ::= SEQUENCE OF Targets
ENDAuthor's Addresses 💌
the authors, with their contact details exactly as they're listed in the document 🫶:
Stephen Farrell
Baltimore Technologies
39/41 Parkgate Street
Dublin 8
IRELAND
EMail: stephen.farrell@baltimore.ie
Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: rhousley@rsasecurity.comAcknowledgements 🌸
Russ Housley wants to give a big thank you 🙏 to the management at SPYRUS, who kept supporting this spec while he was working there 💜. He also thanks the management at RSA Laboratories, who helped him finish the spec after he changed jobs 🌈.
Full Copyright Statement ✨
okay bestie, this part is the legal bit 🫶 but it's still important. The Internet Society owns the copyright here: Copyright (C) The Internet Society (2002). All Rights Reserved. 💜
You're allowed to copy this document and hand it to other people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, whole or in part, with no real restrictions 🦋. The one catch: the copyright notice and this paragraph have to stay on every copy and every derivative work.
You can't modify the document itself. That means no removing the copyright notice, and no removing references to the Internet Society or other Internet organizations 🙅♀️. There are two exceptions. One is developing Internet standards, where the procedures for copyrights in the Internet Standards process must be followed. The other is translating it into languages other than English 🌍.
These permissions are perpetual, which means the Internet Society and its successors or assigns won't revoke them 💖.
Now the disclaimer, and it's giving serious energy 😭. The document and everything in it is provided "AS IS". THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE 💀.
Acknowledgement 🌸
Last but definitely not least, the RFC Editor function is currently funded by the Internet Society. So a big thank you to them for keeping the lights on 🧚💜
📦 where this page comes from
- ietf: rfc3281 2002-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms