An Internet Attribute Certificate Profile for Authorization
obsoleted by
- rfc-5755 — An Internet Attribute Certificate Profile for Authorization
Extracted elements (31)
AC chains are NOT RECOMMENDED due to the complexity of their administration and processing, and because Internet use of ACs is limited. Conformant implementations are only required to process a single AC at a time; delegation via chaining is left to future specifications.
Authorization information is separated from PKCs into dedicated ACs because authorization info typically has a different (shorter) lifetime than the identity/key binding, and the PKC issuer is usually not the authoritative source for authorization information, requiring extra steps if embedded in PKCs.
IetfAttrSyntax was defined to allow separation between the AC issuer and the attribute policy authority (a single policy authority can allocate values while multiple AC issuers deploy them), and to restrict value syntaxes to OCTET STRING, OID, and UTF8String to reduce matching complexity.
The AC issuer field uses v2Form with only an issuerName (rather than baseCertificateID) so the AC issuer need not know which PKC the AC verifier will use to validate the AC issuer's signature at AC creation time, avoiding forcing the verifier to trust a specific issuer PKC chosen at issuance.
X.509 (2000) defines targetInformation as 'SEQUENCE OF Targets'. Conforming AC issuers MUST produce only one Targets element, but AC users MUST accept a SEQUENCE OF Targets and treat multiple Targets elements as if all Target elements were collapsed into a single Targets element.
AC validation requires: the holder's PKC certification path MUST be verified per PKIXPROF; the AC signature MUST be cryptographically correct and the issuer's PKC path verified; the AC issuer MUST be directly trusted; evaluation time MUST be within validity period; the targeting check MUST pass; and any unsupported critical extension MUST cause rejection.
ACs conforming to this profile MUST use the v2Form choice for the issuer, which MUST contain exactly one GeneralName in the issuerName with a non-empty distinguished name in the directoryName field. The baseCertificateID and objectDigestInfo fields MUST be omitted from V2Form.
An AC issuer MUST NOT also be a PKC issuer (CA). The AC issuer's PKC MUST NOT have a basicConstraints extension with the cA BOOLEAN set to TRUE, to avoid confusion regarding serial numbers and revocations.
Conforming implementations MUST support the dNSName, directoryName, uniformResourceIdentifier, and iPAddress GeneralName options. Implementations MUST NOT use the x400Address, ediPartyName, or registeredID options.
For a given AC, each AttributeType OID MUST be unique within the attributes SEQUENCE (only one instance per attribute type, though each may be multi-valued). An AC MUST contain at least one attribute; the SEQUENCE OF Attributes MUST NOT be of zero length.
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, all ACs lacking a noRevAvail extension MUST be rejected. An AC MUST NOT contain both noRevAvail and a revocation pointer.
For any conforming AC, the issuer/serialNumber pair MUST be unique. The serialNumber MUST be a positive integer (sign bit zero in DER). AC users MUST handle serialNumbers longer than 4 octets; conformant ACs MUST NOT contain serialNumbers longer than 20 octets.
GeneralizedTime values MUST be expressed in UTC and MUST include seconds (YYYYMMDDHHMMSSZ), even when seconds are zero. GeneralizedTime values MUST NOT include fractional seconds.
If the crlDistributionPoints extension is present, exactly one distribution point MUST be present using DistributionPointName with fullName containing a single name form (distinguished name or HTTP/LDAP URI). The extension MUST be non-critical.
OID arc elements MUST be in the range 0–4,294,967,295 and SHOULD be less than 2^31. Implementations MUST support OID dotted-decimal string representations up to 100 bytes and OIDs with up to 20 elements. AAs SHOULD NOT issue ACs containing OIDs that breach these constraints.
The version field MUST have the value v2 (integer 1 in DER encoding). This version is not backwards compatible with the v1 definition from the 1997 X.509 standard.
When PKC-based authentication is used, the holder field SHOULD use baseCertificateID, where the PKC issuer MUST have a non-empty distinguished name and the holder's PKC serialNumber and issuer MUST be identical to the AC holder field. Only one of baseCertificateID, entityName, or objectDigestInfo SHOULD be present in any given AC.
Attribute encryption uses CMS EnvelopedData stored as the encAttrs attribute (id-aca-encAttrs, { id-aca 6 }). The plaintext ACClearAttrs structure (containing acIssuer, acSerial, and attrs) is DER-encoded and wrapped in an OCTET STRING; after decryption, the verifier MUST confirm the acIssuer and acSerial match the containing AC to prevent ciphertext stealing.
The AAControls PKC extension (id-pe-aaControls, { id-pe 6 }) constrains which attribute types an AC issuer below a given AA CA may include in ACs, using pathLenConstraint, permittedAttrs, excludedAttrs, and permitUnSpecified (default TRUE). When AAControls are used, all PKCs from the AA CA down to the AC issuer MUST contain an AAControls extension.
The AC Targeting extension (id-ce-targetInformation, { id-ce 55 }) restricts AC use to named servers/services via a SEQUENCE OF Targets containing targetName or targetGroup GeneralNames. An honest AC verifier not among the named targets MUST reject the AC; the extension MUST be critical.
The Audit Identity extension (id-pe-ac-auditIdentity, { id-pe 4 }) carries an opaque 1-to-20 octet OCTET STRING for audit/logging that does not directly reveal holder identity. This extension MUST be critical when present, allowing tracking without identification unless the AC issuer cooperates.
The Clearance attribute (id-at-clearance) carries a policyId OID, a classList BIT STRING with values unmarked(0)/unclassified(1)/restricted(2)/confidential(3)/secret(4)/topSecret(5), and an optional SET OF SecurityCategory. BIT STRING positions 0-5 are reserved for this basic hierarchy.
The No Revocation Available extension (id-ce-noRevAvail, { id-ce 56 }) signals that no revocation information will be issued for the AC. Its syntax is NULL ('0500'H in DER) and it MUST be non-critical. Where no noRevAvail is present, the AC issuer implicitly commits to supporting revocation status checks.
The ProxyInfo extension (id-pe-ac-proxying, { id-pe 10 }) enables controlled AC proxying via a SEQUENCE OF Targets. The extension MUST be critical. A proxy check passes if the sender's authenticated identity matches the holder field or a proxy set, and the current server is a valid target in that same proxy set.
The Role attribute (id-at-role, { id-at 72 }) uses RoleSyntax: a SEQUENCE with optional roleAuthority (GeneralNames) and required roleName (GeneralName). The roleName MUST use the uniformResourceIdentifier CHOICE to allow domain-scoped role disambiguation (e.g., 'urn:administrator' under 'Baltimore' vs 'SPYRUS').
A rogue CA sharing the same issuer name as that in an AC's baseCertificateID could issue a fraudulent PKC with the same issuer/serial, allowing misuse of a legitimate AC. This SHOULD be avoided by ensuring no two CAs share a name; alternatively, bind ACs to PKCs via the publicKeyCert ObjectDigestInfo to avoid the collision entirely.
If an AC issuer's private key is compromised, all ACs it issued MUST be revoked. AC issuers should use tamper-resistant cryptographic modules and separation of duties. The freshness of revocation status directly affects the assurance of long-lived ACs; untimely or unavailable revocation information reduces binding assurance.
Implementers MUST ensure only attributes that the issuer is trusted to issue are used in authorization decisions; other attributes MUST be ignored. Since AAControls is optional, AC verifiers MUST receive trusted-issuer information by other means (e.g., configuration), especially when trusting more than one AC issuer.
Implementers SHOULD be very careful when mapping authenticated identities (from TLS, S/MIME, etc.) to the AC holder field when non-PKC authentication is used. AC issuers MUST encode distinguished names in holder.entityName identically to the holder's PKC to prevent recognition failures.
AttributeCertificate is a SEQUENCE of AttributeCertificateInfo (acinfo), AlgorithmIdentifier (signatureAlgorithm), and BIT STRING (signatureValue). AttributeCertificateInfo contains version, holder, issuer, signature, serialNumber, attrCertValidityPeriod, a SEQUENCE OF Attribute, optional issuerUniqueID, and optional extensions.
IetfAttrSyntax is a SEQUENCE with optional policyAuthority (GeneralNames) and a SEQUENCE OF values where each value is a CHOICE of OCTET STRING, OBJECT IDENTIFIER, or UTF8String. All values in a multi-valued attribute MUST use the same choice of value syntax.