Attribute Certificate (AC) Policies Extension
Extracted elements (25)
ASN.1 definitions are presented in the 1988 ASN.1 syntax rather than the 1997 syntax used in recent ISO/IEC/ITU-T standards, to maintain consistency with the existing PKIX module conventions.
The AC policies extension is designed to allow relying parties to perform an additional validation test — assessing whether an AC's attributes can be accepted under one or more specific ACPs — analogous to the certificate policies extension in PKCs, without defining the content of the ACPs themselves.
The explicitText field in AC User Notice has a maximum size of 200 characters, and messages MAY be multilingual to allow software to select the appropriate language for its environment.
AAs SHALL ensure that the ACP applies to all attributes included in the ACs they issue, and attributes included in a given AC MUST be compliant with all the ACPs from that AC.
An application that recognizes the AC policies extension and its content SHALL process the extension regardless of the value of the criticality flag.
For each AC delivered, the Attribute Authority (AA) SHALL make sure that the AC policy applies to all the attributes contained in it.
If an AA's private key is compromised and the compromise is detected, the certificate of the AA MUST be revoked.
If both noticeRef and explicitText are present in a qualifier and the application can locate the text indicated by noticeRef, that text SHOULD be displayed; otherwise the explicitText string SHOULD be displayed.
If the AC policies extension is non-critical and not recognized by the AC-using application, the application MAY ignore it.
If the extension is marked critical or recognized by the AC-using application, attributes in the AC SHALL only be used in accordance with one of the indicated AC policies. If none of the ACP identifiers is adequate, the AC MUST be rejected.
Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present, MUST be ignored.
The application software SHOULD display the AC User Notice when an attribute certificate is used.
The duplicate-CA-name attack SHOULD be avoided by properly managing and configuring the PKI so that no two CAs share the same name, or alternatively by tying ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field.
To promote interoperability, policy information terms SHOULD consist of only an OID. When multiple policies are used, their requirements must be non-conflicting.
When the extension is critical or recognized, the AC-using application MUST use the list of AC policies to determine appropriateness for a transaction; when no appropriate policy is found, the AC SHALL be rejected.
When verifying an AC, a relying party MUST determine that the AC was issued by a trusted AA and that it has the appropriate policy.
The AC policies extension is identified by OID id-pe-acPolicies, assigned as { id-pe 15 } within the PKIX arc. It explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate.
Two policy qualifier types are defined: the ACPS Pointer (id-qt-acps), which carries a URI pointing to an Attribute Certification Practice Statement, and the AC User Notice (id-qt-acunotice), which carries a UserNotice for display to relying parties.
The OID for the AC policies extension (id-pe-acPolicies = { id-pe 15 }) was assigned from an arc delegated by IANA to the PKIX Working Group. No further IANA action is required.
Failure of AAs to protect their private keys permits an attacker to generate false ACs or revocation status, undermining confidence in the system. AAs are advised to use tamper-resistant cryptographic modules and separation of duties.
If an AC is tied to the holder's PKC using the baseCertificateID component and a rogue CA shares the same issuer name, a malicious party could use a fraudulently issued PKC together with the AC. Proper PKI name management or use of ObjectDigestInfo mitigates this.
Short key lengths or weak hash algorithms limit the utility of an AC. AAs are encouraged to employ strong cryptographic techniques and monitor advances in cryptology.
The availability and freshness of revocation status affects assurance in long-lived ACs. If revocation status is untimely or unavailable, the assurance associated with attribute bindings is reduced.
AcPoliciesSyntax is a SEQUENCE SIZE (1..MAX) OF PolicyInformation. Each PolicyInformation contains a mandatory policyIdentifier (AcPolicyId, an OID) and an optional policyQualifiers field (SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo).
PolicyQualifierInfo is a SEQUENCE containing a policyQualifierId (constrained to id-qt-acps or id-qt-acunotice) and a qualifier field typed ANY DEFINED BY policyQualifierId. ACPSuri is an IA5String; ACUserNotice reuses the UserNotice type from RFC 3280.