An Internet Attribute Certificate Profile for Authorization
obsoletes
- rfc-3281 — An Internet Attribute Certificate Profile for Authorization
Extracted elements (33)
AC chains (delegated authorization paths) are deliberately not required by this profile due to their administrative and processing complexity and limited deployment. Only single AC processing is required; future specifications may address chain processing.
Authorization information is intentionally separated from PKCs into attribute certificates because authorization data typically has a shorter lifetime than the identity-key binding, and the PKC issuer is not usually authoritative for authorization information. Placing authorization in PKC extensions shortens PKC useful lifetimes.
The IetfAttrSyntax type was designed to separate the AC issuer from the attribute policy authority (useful when multiple ACs issuers serve one policy authority) and to restrict value syntaxes to OCTET STRING, OID, and UTF8String, reducing matching complexity.
The v2Form issuerName-only choice for AttCertIssuer was selected so the AC issuer does not need to know in advance which PKC the AC verifier will use for the issuer. Using baseCertificateID would force the verifier to trust whichever PKC the issuer chose at AC creation time.
The clearance attribute Clearance SEQUENCE in RFC 3281 erroneously used implicit tag [0] on policyId and [1] on classList and [2] on securityCategories. This document corrects it to use untagged fields, restoring conformance with X.509-1997. Implementations MUST NOT output the RFC 3281 version but SHOULD be able to decode it.
There are two distinct OIDs for the id-at-clearance attribute: one from X.509-1997 ({ joint-iso-ccitt(2) ds(5) attributeType(4) clearance(55) }) and one from RFC 3281 ({ joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) clearance(55) }). Both are defined in this specification's ASN.1 module to support interoperability with existing implementations.
ACs conforming to this profile MUST use the v2Form AttCertIssuer choice, which MUST contain exactly one GeneralName in issuerName as a non-empty directoryName. The baseCertificateID and objectDigestInfo fields MUST be omitted.
All multi-valued IetfAttrSyntax attributes MUST use the same choice of value syntax (octets, oid, or string) across all values in a single attribute; mixing syntax choices within one attribute is prohibited.
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.
An AC-using system MUST reject an AC if it encounters a critical extension it does not recognize. Non-critical unrecognized extensions MAY be ignored. If any critical extension outside the defined profile set is present, the AC does not conform to this profile.
Conforming implementations MUST support dNSName, directoryName, uniformResourceIdentifier, and iPAddress in GeneralName. Implementations MUST NOT use x400Address, ediPartyName, or registeredID options.
For a given AC, each AttributeType OID in the attributes SEQUENCE MUST be unique (only one instance per 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 (noRevAvail extension) MUST be supported and the 'pointer in AC' scheme SHOULD be supported. If only the 'never revoke' scheme is supported, ACs without noRevAvail MUST be rejected.
GeneralizedTime values in the attrCertValidityPeriod MUST be expressed in UTC (Zulu), MUST include seconds (format YYYYMMDDHHMMSSZ even when seconds are zero), and MUST NOT include fractional seconds.
Implementations MUST support the clearance attribute syntax from [X.501-1997] with untagged policyId. Implementations SHOULD support decoding the RFC3281 syntax, but MUST NOT output the clearance attribute as defined in RFC3281 (which used erroneous implicit tagging in the original definition).
The issuer/serialNumber pair MUST form a unique combination for every conforming AC. The serialNumber MUST be a positive integer (sign bit zero in DER); AC users MUST handle serial numbers longer than 4 octets, and conformant ACs MUST NOT contain serialNumber values longer than 20 octets.
The version field MUST have the value v2 (integer 1 in DER encoding). This version is compatible with the X.509 (2000) v2 definition but not backwards compatible with the 1997 X.509 v1 attribute certificate definition.
To be valid, an AC must satisfy seven checks: (1) holder's PKC certification path verified per RFC 5280; (2) AC signature cryptographically valid and AC issuer's PKC path verified; (3) AC issuer's PKC conforms to Section 4.5; (4) AC issuer directly trusted by configuration; (5) evaluation time within AC validity; (6) targeting check passes; (7) no unsupported critical extensions.
Attribute encryption uses CMS EnvelopedData (encAttrs attribute, id-aca-encAttrs { id-aca 6 }) to encrypt sets of attributes for predetermined recipients before signing. The cleartext ACClearAttrs structure includes acIssuer and acSerial fields to prevent ciphertext stealing; the AC verifier MUST verify these match after decryption.
The AAControls extension (id-pe-aaControls, { id-pe 6 }) is placed in CA or AC issuer PKCs to constrain which attribute types a downstream AC issuer may assert. It contains pathLenConstraint, permittedAttrs, excludedAttrs, and permitUnSpecified (default TRUE). When used, all PKCs from the AA CA to the AC issuer MUST contain this extension.
The AC Targeting extension (id-ce-targetInformation, { id-ce 55 }) is a SEQUENCE OF Targets that restricts AC use to named servers or groups. An honest AC verifier not among the named targets MUST reject the AC. This extension MUST be marked critical. The targetCert CHOICE MUST NOT be used.
The Audit Identity extension (id-pe-ac-auditIdentity, { id-pe 4 }) carries an OCTET STRING of 1 to 20 octets that allows audit logging without directly identifying the AC holder. It MUST be marked critical so that verifiers that do not understand it cannot use the AC holder field for auditing instead.
The noRevAvail extension (id-ce-noRevAvail, { id-ce 56 }) signals that no revocation information will be made available for the AC. Its DER encoding is NULL ('0500'H) and it MUST be non-critical. An AC MUST NOT contain both noRevAvail and a pointer-in-AC revocation extension.
The Proxying extension (id-pe-ac-proxying, { id-pe 10 }) uses a ProxyInfo (SEQUENCE OF Targets) structure to control which servers may forward an AC on behalf of a holder. This extension MUST be marked critical. A proxy check succeeds if the sender matches the Holder field and the current server matches a proxy set, or if both sender and current server match the same proxy set.
The Role attribute (id-at-role, { id-at 72 }) uses RoleSyntax, a SEQUENCE with optional roleAuthority ([0] GeneralNames) and mandatory roleName ([1] GeneralName). The roleName MUST use the uniformResourceIdentifier CHOICE to allow domain-qualified role names that distinguish, e.g., 'administrator' as defined by different organizations.
This document defines OIDs under the id-aca arc ({ id-pkix 10 }) for standard AC attribute types: id-aca-authenticationInfo (1), id-aca-accessIdentity (2), id-aca-chargingIdentity (3), id-aca-group (4), and id-aca-encAttrs (6). It also defines AC extension OIDs id-pe-ac-auditIdentity ({ id-pe 4 }), id-pe-aaControls ({ id-pe 6 }), id-pe-ac-proxying ({ id-pe 10 }), and id-ce-targetInformation ({ id-ce 55 }). No new IANA action is required; OIDs are from arcs delegated to the PKIX working group.
AC issuers MUST encode the distinguished name in the AC holder.entityName field identically to the PKC subject distinguished name. Inconsistent name encoding or comparison rules may result in acceptance of invalid targeted or proxied ACs, or rejection of valid ones.
If an AC issuer's private key is compromised, all ACs it issued MUST be revoked. AC issuers are advised to use tamper-resistant cryptographic modules and management procedures such as separation of duties to prevent compromise, and to maintain secure backups of signing keys.
Implementers MUST ensure that after AC validation, only attributes the issuer is trusted to issue are used in authorization decisions; all other attributes MUST be ignored. Since AAControls is optional to implement, verifiers MUST be provided trusted attribute lists by other means such as configuration.
When an AC is tied to a holder's PKC via baseCertificateID, a rogue CA with the same issuer name could issue a fraudulent PKC with the same serial number, enabling AC misuse. This SHOULD be avoided by ensuring no two CAs share the same name, or by using the publicKeyCert ObjectDigestInfo binding instead.
AttCertIssuer MUST use the v2Form CHOICE, which is a V2Form SEQUENCE containing an optional issuerName (GeneralNames), baseCertificateID ([0] IssuerSerial), and objectDigestInfo ([1] ObjectDigestInfo). In this profile, only issuerName may be present; baseCertificateID and objectDigestInfo MUST NOT be present.
The AttributeCertificate is a SEQUENCE of acinfo (AttributeCertificateInfo), signatureAlgorithm (AlgorithmIdentifier), and signatureValue (BIT STRING). The AttributeCertificateInfo contains version, holder, issuer, signature, serialNumber, attrCertValidityPeriod, attributes, and optional issuerUniqueID and extensions fields.
The Holder field is a SEQUENCE with three optional alternatives: baseCertificateID ([0] IssuerSerial) referencing the holder's PKC by issuer and serial, entityName ([1] GeneralNames) naming the holder directly, and objectDigestInfo ([2] ObjectDigestInfo) linking the AC to a hash of an object such as a public key.