RFC 5755
An Internet Attribute Certificate Profile for Authorization
Internet Engineering Task Force (IETF) 🎀
- Request for Comments: 5755
- Title: An Internet Attribute Certificate Profile for Authorization ✨
- Authors: S. Farrell (Trinity College Dublin), R. Housley (Vigil Security), S. Turner (IECA)
- Category: Standards Track
- ISSN: 2070-1721
- Date: January 2010
- Obsoletes: 3281 (RFC 3281)
- Updates: none listed
Abstract 🌸
okay bestie, so this spec is a profile for X.509 Attribute Certificates when they're used in Internet protocols 💖 ACs can show up in a whole bunch of apps with all kinds of interoperability goals and a even bigger range of operational and assurance needs. The main goal is a common baseline for generic apps that need broad interoperability, plus room for special-purpose requirements. It puts extra focus on AC support for Internet electronic mail, IPsec, and WWW security apps 📧🔐 And yes, 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). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc5755 🔗
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) as they're in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💀
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person(s) who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from the person(s) controlling the copyright in those 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. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
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
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 ................................481. Introduction 💖
okay so 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 a lot like a PKC, with one big difference: the AC has no public key in it. What an AC can hold is attributes saying things like group membership, role, security clearance, or other authorization info about the AC holder 🎀
The syntax for the AC is defined in Recommendation X.509, which makes the term "X.509 certificate" kinda ambiguous 🙈
Some people constantly mix up PKCs and ACs, so let's do an analogy 🛂 A PKC is like a passport: it identifies you, it lasts a long time, and it shouldn't be easy to get. An AC is more like an entry visa: a different authority usually issues it, and it doesn't last as long. Since getting a visa usually means showing a passport first, getting a visa can be the simpler process 🧳
Authorization info can go in a PKC extension or in a separate attribute certificate (AC). Putting authorization info in PKCs is usually a no-go, for two reasons 🙅♀️ First, authorization info often doesn't have the same lifetime as the identity-to-public-key binding. If you stuff authorization info into a PKC extension, the PKC's useful lifetime generally gets shorter. Second, the PKC issuer usually isn't the authority on the authorization info. So the PKC issuer ends up doing extra steps to grab that info from the authoritative source 😩
That's why it's often better to keep authorization info separate from the PKC. But authorization info still needs to be tied to an identity, and an AC is exactly what provides that binding. 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, identity isn't what decides access. What matters is the accessor's role or group membership. Access control schemes like that are called role-based access control 👑
When an access control decision is made based on an AC, the access control 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 put 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 be used with a data origin authentication service and a non-repudiation service 📝 In those contexts, the attributes in the AC give extra info about the signing entity. That info can help make sure the entity is authorized to sign the data. This kind of checking depends either on the context the data gets exchanged in, or on the data that was digitally signed 💜
This document obsoletes [RFC3281]. The 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]. Those are the big-deal words that tell you how strict each rule is, so keep an eye out for them 👀
1.2. AC Path Delegation ✨
okay so the X.509 standard [X.509-2000] describes 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 the authenticity of a privilege asserter's privilege. So chains or paths of ACs could be used to delegate authorization 🔗
Okay, the big tea: AC chains are complex to administer and process, and ACs aren't that widespread on the Internet right now, so it is RECOMMENDED that implementations of this specification not use AC chains 🙈 Other (future) specifications may address the use of AC chains. This specification covers the simple cases, where one authority issues all of the ACs for a particular set of attributes. BUT this simplification does not stop you from using several different authorities, each managing a different set of attributes 💖 For example, group membership could be in one AC from one authority, and security clearance could be in another AC from a different authority. Iconic, honestly 👑
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.3. Attribute Certificate Distribution ("Push" vs. "Pull") 🌸
As we already covered, ACs give you a way to securely provide authorization info to things like access control decision functions. However, there are a bunch of different communication paths for ACs 🧚
In some environments, it's suitable for a client to "push" an AC to a server. That means no new connections between the client and server are required 🫶 It also means no search burden is put on servers, which improves performance, and the AC verifier only gets shown 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's more suitable for a client to just 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 📚
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 Exchanges1.4. Document Structure 🗺️
Okay so, Section 2 defines some terminology. Section 3 specifies the requirements 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 📧
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. Let's go, bestie 🚀
Time/Validity requirements:
- 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 ⏰
Attribute Types:
- Issuers of ACs should be able to define their own attribute types for use within closed domains 🏷️
- 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" 🥰
- 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. Main character energy in the naming department 💅
Targeting of ACs:
- 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
- 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 🧠
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 ✨
okay so X.509 already has the full AC definition, bestie 🧚 all the types that aren't defined in this doc live in [PKIXPROF], so go look there if you need them 💅
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
}Even though the Attribute syntax lives in [PKIXPROF], we're copying it down here so you don't have to hunt for it 🦋
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeTypengl this part is a little bit of a trap 🙈 implementers need to know that the DER encoding (see [X.509-1988], [X.690]) of a SET OF values needs the encodings sorted. Distinguished names have the same issue and [PKIXPROF] implementations already deal with it, but it matters way more here because ACs are much more likely to carry multiple values 🔥
4.2. Profile of Standard Fields 💜
GeneralName is super flexible, which is iconic but also kinda chaotic. So to keep everyone interoperating, this profile puts some limits on how GeneralName gets used 🎀
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.6). Implementations SHOULD also support the SRVName, as defined in [X509-SRV].
Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options. Absolutely not, bestie 🙅
Conforming implementations MAY use the otherName option to carry name forms that are defined in Internet Standards. For example, Kerberos [KRB] format names can go inside otherName, using a Kerberos 5 principal name OID plus a SEQUENCE of the Realm and the PrincipalName 🌸
4.2.1. Version 🍓
The version field MUST have the value of v2. Basically, the version field is there in the DER encoding.
Note: this version (v2) is NOT backwards compatible with the older attribute certificate definition (v1) from the 1997 X.509 standard [X.509-1997]. It IS compatible with the v2 definition from X.509 (2000) [X.509-2000]. Don't mix them up 😭
4.2.2. Holder 🦋
The Holder field is a SEQUENCE with three different optional syntaxes: baseCertificateID, entityName, and objectDigestInfo. If only one option shows up, it's super clear what Holder means ✨
When more than one option is used, though, it gets confusing fast. Which one is "normative"? Which one is just a "hint"? Since [X.509-2000] doesn't make that clear, this specification RECOMMENDS that only one of the options be used in any given AC 💅
For any environment where the AC gets passed in an authenticated message or session, and the authentication is based on 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, and that name is the single value that goes into the directoryName field of holder.baseCertificateID.issuer. The AC holder.baseCertificateID.issuerUID field MUST only be used if the holder's PKC has an issuerUniqueID field. If both the AC holder.baseCertificateID.issuerUID and the PKC issuerUniqueID fields are present, the same value MUST be in both. So yeah, baseCertificateID only works with PKC profiles (like [PKIXPROF]) that require the PKC issuer field to hold a non-empty distinguished name 👑
Note: an empty distinguished name is one where the SEQUENCE OF relative distinguished names has zero length. In DER, that's the value '3000'H.
If the Holder field uses the entityName option and the underlying authentication is PKC-based, the entityName MUST be the same as the PKC subject field, or one of the values in the PKC subjectAltName extension (if it's there). Heads up that [PKIXPROF] requires the subjectAltName extension to be present whenever the PKC subject is an empty distinguished name. See the Security Considerations section for some name collision problems that can show up when you use the entityName option 😬
In any other case where the Holder field uses the entityName option, only one name SHOULD be present.
Implementations that conform to this profile don't have to support the objectDigest field. Section 7.3 explains how this optional feature MAY be used 🧚
Any protocol that conforms to this profile SHOULD say which AC holder option it uses, and how that fits with the authentication schemes that protocol supports 🌈
4.2.3. Issuer 👑
ACs that conform to this profile MUST use the v2Form choice. That choice MUST contain one and only one GeneralName in issuerName, and that GeneralName MUST contain a non-empty distinguished name in its directoryName field. In other words, every AC issuer MUST have a non-empty distinguished name. ACs that conform to this profile MUST also leave out the baseCertificateID and objectDigestInfo fields 🙅♀️
Part of the reason v2Form only holds an issuerName is so the AC issuer doesn't have to know which PKC the AC verifier is going to use for it. If the AC issuer were referenced with baseCertificateID, the AC verifier would have to trust whatever PKC the issuer picked for itself back when the AC got created. Nobody wants that drama 💀
4.2.4. Signature ✍️
This field holds the algorithm identifier used to validate the AC signature.
It MUST be one of the signing algorithms defined in [PKIXALGS], or one defined in any IETF-approved update to [PKIXALGS]. Conforming implementations MUST honor all MUST/SHOULD/MAY signing algorithm statements in [PKIXALGS] or in IETF-approved updates to [PKIXALGS] 🔐
4.2.5. Serial Number 🔢
For any conforming AC, the issuer/serialNumber pair MUST be a unique combination, even when ACs are very short-lived ⏳
AC issuers MUST force the serialNumber to be a positive integer. In other words, the sign bit in the DER encoding of the INTEGER value MUST be zero. If you need to, you can do this by adding a leading (leftmost) '00'H octet. This clears up a possible ambiguity when mapping between a string of octets and an integer value 🧩
Because of those uniqueness and timing requirements, serial numbers are expected to be pretty 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 📏
Serial numbers DON'T have to follow any particular ordering. They don't need to go up over time either. Each AC issuer MUST make sure that every AC it issues has a unique serial number 🌟
4.2.6. Validity Period ⏰
The attrCertValidityPeriod field (a.k.a. validity) says how long the AC issuer is certifying that the binding between the holder and the attributes will be valid 🦋
GeneralizedTime is the standard ASN.1 type for representing time with variable precision. A GeneralizedTime value can optionally include the time difference between the local time zone and Greenwich Mean Time 🌍
For this profile, GeneralizedTime values MUST be expressed in Coordinated Universal Time (UTC), which is also known as Greenwich Mean Time or Zulu)). They MUST include seconds, so the format is YYYYMMDDHHMMSSZ, even when the seconds are zero. GeneralizedTime values MUST NOT include fractional seconds 🕐
(Note: this is the same as what [PKIXPROF] specifies in Section 4.1.2.5.2.)
AC users MUST be able to handle an AC whose validity period, or part of it, is in the past or in the future when it gets processed. That's a post-dated AC, and it's valid for some applications, like backup 📦
4.2.7. Attributes 🎀
The attributes field tells you about the AC holder. When the AC is used for authorization, this usually holds a set of privileges 🔑
The attributes field is a SEQUENCE OF Attribute. Each Attribute has an attribute type plus a SET OF values. For a given AC, every AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. So each attribute can only appear once in a single AC, but that one instance can hold multiple values 💖
AC users MUST be able to handle multiple values for all attribute types 🙌
An AC MUST contain at least one attribute. The SEQUENCE OF Attributes MUST NOT be zero length 🫧
Some standard attribute types are defined in Section 4.4 ✨
4.2.8. Issuer Unique Identifier ✨
okay so this one is a strict bestie 🙈 issuerUniqueID MUST NOT be used unless the AC issuer's PKC also uses it, and if the PKC does use it, then it MUST be used here too 💅 Fun fact: [PKIXPROF] says conforming certification authorities (CAs) SHOULD NOT use this field, but applications SHOULD be able to parse PKCs that contain it 🦋
4.2.9. Extensions 🎀
the extensions field is all about the AC itself, not the AC holder 💜
an AC with no extensions still conforms to the profile 🫶 Section 4.3 lists the extensions that MAY be used with this profile, plus whether they're allowed to be marked critical. If an AC uses any other critical extension, it does NOT conform to this profile (the no-cap rule, periodt). But if it uses any other non-critical extension, it still conforms ✨
the extensions are how ACs attach extra attributes to holders, and this profile also lets communities make private extensions for their own info 🌈 Every extension can be critical or non-critical. An AC-using system MUST reject an AC if it runs into a critical extension it doesn't recognize 😭 A non-critical extension, though, may be ignored if it isn't recognized. Section 4.3 has the recommended extensions for Internet ACs and where info should live. Communities can add more extensions too, but be careful about making any critical ones in ACs, since that could stop the AC from working in a general context 👑
4.3. Extensions 🧚
4.3.1. Audit Identity 🔥
sometimes the law (like data protection and privacy rules) says audit trails can't have records that directly identify people 🙈 That makes the AC Holder field a no-go for audit trails.
so for those cases, 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 AC issuer's cooperation 🔐
the audit identity, plus the AC issuer/serial, SHOULD then be used for audit and logging. If the audit identity is picked well, a server/service administrator can use audit trails to track what an AC holder does without being able to figure out who they are 🕵️♀️
the server/service administrator together with the AC issuer MUST be able to identify the AC holder when misbehavior is detected. Which means the AC issuer MUST be able to find the actual identity of the AC holder from the audit identity 💖
Auditing could be based on the AC issuer/serial pair, but that doesn't let you track the same AC holder across multiple ACs 💀 So an audit identity only really helps if it lasts longer than a typical AC lifetime. Auditing could also use the AC holder's PKC issuer/serial, but that will often let the server/service administrator identify the holder, so it's not the move.
because 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 often show the AC holder's identity in the bits on the wire. In those cases, an opaque audit identity doesn't make the AC anonymous 🙈 It just makes sure the audit trails don't have identifying info in them.
the value of an audit identity MUST be longer than zero octets, and it 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, you can use the target information extension (imported from [X.509-2000]) to name a bunch of servers/services 💅 The vibe is that the AC SHOULD only be usable at those named servers/services. An (honest) AC verifier that isn't one of the named servers/services MUST reject the AC 😤
if this extension isn't there, the AC isn't targeted, so any server can accept it 🌸
in this profile, the targeting info is just a list of named targets or groups ✨
here's the syntax for the targeting info:
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 inside the Target structure is only there so it stays future-compatible with [X.509-2000], and it MUST NOT be used 🙅♀️
the targets check passes if the current server (the 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 that case, the current server is said to "match" the targeting extension 🦋
how a target figures out it's in a targetGroup isn't defined here. It's assumed that any target "knows" the targetGroups it belongs to, or can otherwise work out its membership 🧠 For example, if the targetGroup is a DNS domain, the AC verifier knows which DNS domain it belongs to. Or if the targetGroup is "PRINTERS", the AC verifier knows whether it's a printer or a 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 TRUE4.3.3. Authority Key Identifier 🔑
the authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY be used to help the AC verifier check the AC's signature 💜 Read the [PKIXPROF] description as if "CA" meant "AC issuer". Just like with PKCs, this extension SHOULD be included in ACs ✨
Note: An AC whose issuer field used the baseCertificateID CHOICE wouldn't need an authorityKeyIdentifier extension, since it's explicitly linked to the key in the referred certificate. But because this profile says (in Section 4.2.3) that ACs MUST use the v2Form with issuerName CHOICE, that duplication never happens 🙌
name id-ce-authorityKeyIdentifier
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE4.3.4. Authority Information Access 🌐
the authorityInfoAccess extension, as defined in [PKIXPROF], MAY be used to help the AC verifier check the AC's revocation status 🔍 Support for the id-ad-caIssuers accessMethod is OPTIONAL by this profile, since AC chains aren't expected 🤷♀️
the following accessMethod says 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 that URI MUST contain an HTTP URL [HTTP-URL] that points to 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 help the AC verifier check the revocation status of the AC 🌸 See Section 6 for the 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. And 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 FALSE4.3.6. No Revocation Available 🙅♀️
the noRevAvail extension, defined in [X.509-2000], lets an AC issuer say that no revocation information will be made available for this AC 💀
this extension MUST be non-critical. An AC verifier that doesn't understand this extension might still be able to find a revocation list from the AC issuer, but that revocation list will never include an entry for the AC 😭
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e., '0500'H is the DER encoding)
criticality MUST be FALSE4.4. Attribute Types 🌟
some of the attribute types below use the IetfAttrSyntax type, which is also defined below. The reasons for using it are:
- It separates the AC issuer from the attribute policy authority 🧩 That's useful when one policy authority (like an organization) hands out attribute values, but there are several AC issuers deployed for performance or other reasons.
- The value syntaxes are limited to OCTET STRING, OBJECT IDENTIFIER, and UTF8String, which hugely cuts down on the complexity of matching more general syntaxes 💖 All multi-valued attributes using this syntax 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 tagged either "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 🔐
okay so the SvceAuthInfo attribute tells the server/service who the AC holder is by a name, and the attribute MAY include optional service specific authentication info ✨. Usually that's a username/password pair for a "legacy" app 🙈
This attribute gives the AC verifier something it can present, so a separate application inside the target system can interpret it and authenticate with it 💖. Heads up: this is a different use from the accessIdentity attribute in 4.4.2 below 🦋
This attribute type will typically be encrypted when the authInfo field holds sensitive stuff, like 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 one is for info about the AC holder that the AC verifier (or a bigger system the AC verifier is part of) can use to authorize what the holder does inside the AC verifier's system 👑. Again, this is a different use from the svceAuthInfo attribute 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 is different from the holder's other identities. For example, the holder's company might be the one that gets charged for the 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 this attribute is:
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}The roleAuthority field MAY be used to name the issuing authority for the role specification certificate 📜. There's no requirement that a role specification certificate actually exists for the roleAuthority, and that's the twist 🙃. 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 info (tied to security labeling) about the AC holder 💜
The policyId field identifies the security policy the clearance relates to 🍓. The policyId shows what the classList and securityCategories fields mean ✨
This spec includes the classList field exactly as it's specified in [X.501-1993] 💅. Extra security classification values, and where they sit in the classification hierarchy, can be defined by a security policy as a local matter or by bilateral agreement 🤝. The basic security classification hierarchy goes, in ascending order: unmarked, unclassified, restricted, confidential, secret, and top-secret 📶
An organization can build its own security policy that defines classification values and what they mean 🏗️. However, the BIT STRING positions 0 through 5 are reserved for the basic security classification hierarchy ⭐
If it's present, the SecurityCategory field gives further authorization info 🌟. The security policy named in the policyId field says which syntaxes are allowed in the securityCategories SET 📋. Each allowed syntax is identified by an OBJECT IDENTIFIER, and when one of those syntaxes shows up in the securityCategories SET, its OBJECT IDENTIFIER goes 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) }The associated syntax was originally (and wrongly) 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 fixed (to get back in line 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)
}
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 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 🙅♀️. That is, an AC issuer can't 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 🎯. There are also 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 causes 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 that 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 revocation is the part where we talk about killing an AC 💀 and bestie, the timing here is lowkey iconic. In a lot of environments an AC's validity period is 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 environments where ACs unlock high value transactions, MAY require revocation support ✨
There are two revocation schemes defined here, and the AC issuer is best off picking 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 is going to be available 🙈 The noRevAvail extension is defined in Section 4.3.6, and the noRevAvail extension MUST be present in the AC to show this scheme is being used.
If there's no noRevAvail, the AC issuer is implicitly saying revocation status checks are supported 👑 which means some revocation method MUST be provided so AC verifiers can figure out the revocation status of the AC.
"Pointer in AC" scheme:
ACs can "point" to sources of revocation status info, using either an authorityInfoAccess extension or a crlDistributionPoints extension inside the AC 🦋
Here's the vibe check for AC users 🎀 The "never revoke" scheme MUST be supported, and the "pointer in AC" scheme SHOULD be supported. If only "never revoke" is supported, then all ACs that do not contain a noRevAvail extension, MUST be rejected. Harsh but fair 😭
For AC issuers, the "never revoke" scheme MUST be supported. If every AC that will ever be issued by that issuer contains a noRevAvail extension, the "pointer in AC" scheme need not be supported 🍓 But if any AC can be issued without a noRevAvail extension, the "pointer in AC" scheme MUST be supported.
An AC MUST NOT contain both a noRevAvail extension and a "pointer in AC" 🙅♀️ that's a no from me, bestie.
An AC verifier MAY use any source for AC revocation status information 💜
7. Optional Features 🧚
This section is all about features that MAY be implemented 🌈 Conformance to this profile does NOT require support for these features, but if you do offer them, they MUST be offered exactly as described below. Like, no freestyling 😤
7.1. Attribute Encryption
AC attributes MAY need to be encrypted if the AC is carried in the clear inside an application protocol, or if the AC has sensitive info in it (think username/password 😬).
When a set of attributes is going to be encrypted inside an AC, we use the Cryptographic Message Syntax, EnvelopedData structure [CMS] to carry the ciphertext and the per-recipient keying info 🔐
This type of attribute encryption is targeted ✨ Before the AC gets signed, the attributes are encrypted for a set of predetermined recipients.
Inside EnvelopedData, the encapsulatedContentInfo tells you what content type is in the ciphertext. In this case, the contentType field of encapsulatedContentInfo MUST contain id-ct-attrCertEncAttrs, which looks like this:
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 goes into the AC as the value of an encAttrs attribute 🎁 Only one encAttrs attribute can be present in an AC, but the encAttrs attribute MAY be multi-valued, and each of its values will hold an independent EnvelopedData.
Each value can hold a set of attributes (each of which might be multi-valued) that's 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 what the plaintext is). Iconic defense, honestly 👑
Here's the procedure for an AC issuer encrypting attributes (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 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.
- Add the encAttrs (with its multiple values) to the AC.
Heads up: there can be more than one attribute of the same type (same OBJECT IDENTIFIER) after decryption 🙈 So an AC MAY contain the same attribute type both in clear and in encrypted form (and even several times, if different recipients are tied to more than one EnvelopedData). For example, an AC could have a cleartext clearance attribute saying the holder is cleared to SECRET, and also an encrypted clearance attribute whose value is some higher clearance that's not supposed to be known everywhere. One approach implementers may pick is to merge the attribute values after decryption, so the "once only" constraint gets re-established 🧩
name id-aca-encAttrs
OID { id-aca 6}
syntax ContentInfo
values Multiple AllowedIf an AC contains attributes that look 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 🦋 That proxying MAY have to happen under the AC issuer's control, so not every AC is proxiable, and a given proxiable AC can be proxied in a targeted way. Support for chains of proxies (with more than one intermediate server) MAY also be required. And note, this does NOT mean a chain of ACs, so don't mix those up 🙅♀️
To meet this need, we define another extension called ProxyInfo, which is kind of like the targeting extension 💖
When this extension is present, the AC verifier MUST check that the entity the AC came from was allowed to send it, and that the AC is allowed to be used by this verifier 🔍
The proxying info is a list where each item is a list of targeting info. If the verifier and the sender of the AC are both named in the same proxy list, the AC can be accepted (the exact rule is below 👀).
The effect? The AC holder can send the AC to any valid target, and that target can only proxy to targets that are in one of the same proxy lists as itself. Very secure girlie behavior 💅
The following data structure represents the targeting/proxying info:
ProxyInfo ::= SEQUENCE OF TargetsTargets is explained in Section 4.3.2. Just like with 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 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 gets proxied more than once, there will be a bunch of targets on the path from the original client, which is normally (but not always) the AC holder 🛤️ In that case, stopping AC "stealing" requires that the AC verifier MUST check that all targets on the path are members of the same proxy set. It's on 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 is NOT allowed to be linked to an identity (via entityName) or to a PKC (via baseCertificateID) 🙈 The objectDigestInfo CHOICE in the Holder field makes that 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. For example, this lets you make ACs linked to public keys instead of names. It also lets you make ACs with 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. So 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, the one that would be 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 pulled out of a PKC, the SubjectPublicKeyInfo from that PKC might not be the value that should be hashed 🤔 This can happen 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, so it 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] 💖
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 bestie, so during AC validation the relying party has to ask 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 for 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 IDENTIFIERhere's how the AAControls extension works 🦋
the pathLenConstraint, if present, is read the same way 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 is 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 🙅♀️
the excludedAttrs field is a list of attribute types that no 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 disallowed.
the permitUnSpecified field tells you what to do with attribute types that show up in neither permittedAttrs nor excludedAttrs. TRUE (the default) means any unspecified attribute type is allowed in ACs, and FALSE means no unspecified attribute type is allowed 🌸
⚠️ when AAControls are used, the following extra checks on an AA's PKC chain MUST all succeed for the AC to be valid. no skipping, bestie!
- some CA on the AC's certificate path MUST be directly trusted to issue PKCs that precede the AC issuer in the certification path. this CA is called the "AA CA" 👑
- all PKCs on the path from the AA CA, down to and including the AC issuer's PKC, MUST contain an AAControls extension. the PKC of the AA CA doesn't need this extension, though (need not, so chill 😌).
- only the 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 after 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 TRUE8. Security Considerations 🔐
okay this section is serious but make it cute 🥺 the protection for private keys is a critical factor in keeping things secure. if AC issuers fail to protect their private keys, an attacker can masquerade as them and potentially generate false ACs or revocation status 😱 bogus ACs and revocation status will wreck confidence in the whole system. if the compromise is detected, all ACs issued by the AC issuer MUST be revoked. rebuilding after a compromise is going to be a total mess, so AC issuers are advised to combine strong technical measures (e.g., tamper-resistant cryptographic modules) with solid management procedures (e.g., separation of duties) to avoid this entirely 🛡️
losing an AC issuer's private signing key is also a big problem 💀 the AC issuer wouldn't be able to produce revocation status or do AC renewal. AC issuers are advised to keep secure backups of their signing keys. how secure the key backup procedures are is a critical factor in avoiding key compromise.
the availability and freshness of revocation status affect how much assurance you should put in a long-lived AC 🕰️ long-lived ACs do expire naturally, but events can happen during their lifetime that break the binding between the AC holder and the attributes. if revocation status is late or unavailable, the assurance in that binding is clearly reduced.
the binding between an AC holder and attributes can't be any stronger than the cryptographic module implementation and the algorithms used to generate the signature. short key lengths or weak hash algorithms will limit how useful an AC is. AC issuers are encouraged to keep up with advances in cryptology so they can use strong cryptographic techniques 💪
inconsistent use of name comparison rules can lead to accepting invalid targeted or proxied ACs, or rejecting valid ones 😵 the X.500 series of specifications defines rules for comparing distinguished names. those rules call for comparing strings without regard to case, character set, multi-character white space substrings, or leading and trailing white space. this specification and [PKIXPROF] relax those 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 as the baseCertificateID component, that 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 that PKC together with the AC 😈 this scenario SHOULD be avoided by properly managing and configuring the PKI so there can't be two CAs with the same name. another option is to tie ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field. failing that, AC verifiers have to establish (using other means) that the potential collisions can't actually happen. 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 the issuer is trusted to issue are used in authorization decisions. other attributes, which MAY be present, MUST be ignored 🧹 since 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. this becomes very important if an AC verifier trusts more than one AC issuer 🚨
there's often a need 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, this mapping is straightforward. however, ACs are also expected to be used in environments where the holder may be authenticated using other means. implementers SHOULD be very careful when mapping the authenticated identity to the AC holder, especially when the authenticated identity doesn't come from a public key certificate, since the 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 needed for this document or any anticipated updates 💖
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.
- [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 📚
okay so these are the informative refs, aka the bonus reading list that helps you understand the spec but doesn't set the rules 🤓 here's the whole list, every detail intact:
[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.
[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 bestie, this appendix is NORMATIVE 🫶 so it's where we list all the brand-new object identifiers this spec defines. some of them are only needed for optional features, so you don't need them for conformance to this profile 💅
here's the vibe: support is mandated for OIDs whose arc elements are less than 2^32, which means they MUST be between 0 and 4,294,967,295 inclusive 🔥 and they SHOULD be less than 2^31 (i.e., less than or equal to 2,147,483,647). this keeps every arc element squeezed into a single 32-bit word, so it's giving efficiency 🧚
also, implementations MUST support OIDs where the dotted decimal string (see [LDAP], Section 4.1.2) can be up to 100 bytes inclusive 💜 and implementations MUST be able to handle OIDs with up to 20 elements inclusive 🍓 AAs SHOULD NOT issue ACs that contain OIDs which 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 }
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) }and lowkey the last bit is a plot twist 👀 as noted in Section 4.4.6, there are two OIDs for id-at-clearance 😭
Appendix B. ASN.1 Module ✨
okay bestie, this appendix is the blueprint 🧚 It lists all the data objects that PKI components use, written in an "ASN.1-like" syntax [X.680]. Think of it as a hybrid, because it mixes the 1988 ASN.1 syntax with the 1993 UNIVERSAL types UniversalString, BMPString, and UTF8String 💅
ngl the module doesn't fully fit either version. The ASN.1 syntax doesn't allow type statements in the module, and the 1993 standard doesn't allow the new UNIVERSAL types in modules written in the 1988 syntax. So this module isn't a clean match for either one 🙈
If you need 1988 ASN.1, you can convert it by swapping the UNIVERSAL type definitions for 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) }
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) }
-- 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 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
}
-- 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
ENDAppendix C. Errata Report Submitted to RFC 3281 🎀
this part is a bug report 🐛 it's the errata filed against RFC 3281, which is posted online as [Err302]
Status: Verified
Type: Technical
Reported By: Stephen Farrell
Date Reported: 2003-03-07
the report says Section 4.4.6 has this:
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}but it should actually say this:
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}Notes:
the tagging difference happened because an unnoticed technical corrigendum (TC-2) got applied to the X.501 document while RFC 3281 was being prepared 🙃 The X.501 format is the correct one, and it'll show up in a future update of RFC 3281. Implementers SHOULD update their decoding functions so they accept either format. Even if they're claiming RFC 3281 conformance, they SHOULD output the (correct) X.501 format until a corrected RFC comes out, and then the incorrect RFC 3281 format won't be specified anymore 💅
Appendix D. Changes since RFC 3281 ✨
Okay so bestie, this is the changelog 🧚 It's basically the receipts of everything that got tweaked between RFC 3281 and this version. Let's go through it together 💅
- Okay so a brand new Section 1.1 "Terminology" showed up 🌸 Sections 1.1-1.3 got bumped to 1.2-1.4, and the first paragraph of Section 1 moved down into Section 1.1. Iconic reshuffle 🎀
- In Section 1.2, the first sentence of the third paragraph got rephrased 💖
- In Section 2, S/MIME v3 became S/MIME v3.2 ✨
- In Section 4.1, a little comma hopped from the right side of the ASN.1 comment to the left side, on the line describing version in the AttributeCertificateInfo structure 🦋 Also the reference to X.208 got swapped out for X.690 🫶
- In Section 4.2, the pointer to 4.2.1.7 of RFC 3280 got updated to point at 4.2.1.6 of RFC 5280 😭 And a new requirement showed up: implementations need to support the subject alternative name choice SRVName 🔥
- In Section 4.3.2, "Confirming" got fixed to "Conforming" 💅 (the typo is gone, periodt)
- In Section 4.3.4, the reference to RFC 1738, URL, got replaced with references to [HTTP-URL] 🌈 "authorityInformationAccess" became "authorityInfoAccess" 🍓 and "NOT REQUIRED" became "OPTIONAL." 💜
- In Section 4.3.5, "HTTP or an LDAP" became "HTTP [HTTP-URL] or an LDAP [LDAP-URL]" 🧚 And "CRLDistPointsSyntax" got renamed to "CRLDistributionPoints" ✨
- In Section 4.4.6, text got added to deal with two OIDs for the same syntax and two syntaxes for one OID 🦋
- In Section 5, "When the extension value SHOULD cause" became "When the extension value causes" 👑 (the SHOULD is gone from that sentence, so no more wiggle room there 🙈)
- In Section 7.1, the text describing encapsulating an encrypted attribute got replaced with corrected text 🎀 It's now clarified that attributes can show up more than once if they apply to different recipients 💖 And the last paragraph got reworded so the failure case is way clearer 🫶
- In Section 7.3, the references got updated to point to RFC 3279 🌸
- In Section 8, the last paragraph got a glow-up to better explain why implementers need to be careful when mapping authenticated identities to the AC holder 🔥 Main character energy for security 💀
- Updated References 🌈 a) The references got split into informative and normative references ✨ b) A reference to RFC 3281 got added 🦋 c) The reference to X.501:1993 became X.501:1997 🍓 d) The reference to RFC 1510 became RFC 4120 💜 e) The reference to RFC 1738 became RFC 4516 and 2585 🧚 f) The reference to RFC 2251 became RFC 4511 🫶 g) The reference to RFC 2459 became RFC 5280 👑 h) The reference to RFC 2630 became RFC 5652 ✨ i) The reference to X.208-1988 became X.690 😭 j) A reference to X.680 got added 🌸 k) A reference to RFC 4985 got added 💖 l) The reference to RFC 3279 got expanded by adding RFC 5480 and RFC 4055, which update RFC 3279 🎀 m) A spurious reference to CMC, CMP, ESS, RFC 2026, X.209-88, and X.501:1988 got deleted 🙈
- In Appendix A, a second clearance attribute object identifier got added 🔥
- Appendix B's ASN.1 got updated with changes 3, 8, 9, and 11 💅 a) New OID for the ASN.1 module 🦋 b) Updated module OIDs for PKIX1Explicit88 and PKIX1Implicit88 🌈 c) Added imports from PKIX1Implicit88 for AuthorityKeyIdentifier, AuthorityInfoAccessSyntax, and CRLDistributionPoint 🧚 d) Added imports from CryptographicMessageSyntax2004 for ContentInfo ✨ e) Added comments and commented out the ASN.1 for the old clearance attribute syntax 💜 f) Added a preamble to the ASN.1, taken from Appendix A of RFC 5280 🫶
- Appendix C got added 👑
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
📦 where this page comes from
- ietf: rfc5755 2010-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms