Internet X.509 Public Key Infrastructure Permanent Identifier
Extracted elements (20)
The permanent identifier is designed as an optional otherName within subjectAltName rather than a separate extension, reusing the existing GeneralName extensibility point from RFC 3280 and X.509 rather than introducing new certificate structure.
The permanent identifier was introduced because subject names change (due to organizational moves, legal name changes, or relocation), while entities need a stable identifier across multiple certificates. The permanent identifier enables linking certificates to the same entity even across DN or subjectAltName changes.
The use of an OID as the assigner field allows any organization (government, corporation, etc.) to be an Assigner Authority by obtaining an OID through standard registration mechanisms (IANA Private Enterprise Numbers, ISO member bodies, or ICD from BSI), enabling global uniqueness without centralized CA coordination.
The certification of different CAs with the same DN by different CAs has negative consequences throughout the PKI, notably rendering the IssuerAndSerialNumber structure in RFC 3852 section 10.2.4 ambiguous, which further complicates permanent identifier matching.
Two ASN.1 modules are provided: a 1988 ASN.1 module (normative) and a 1993 ASN.1 module. In case of discrepancies, the 1988 module governs. The 1988 module can be parsed by replacing UTF8String with ANY for older parsers.
An Assigner Authority MUST have a unique identifier to distinguish it from any other such authority, and that identifier MUST be an object identifier.
Since the use of permanent identifiers may conflict with privacy, CAs SHOULD advertise to purchasers of certificates the use of permanent identifiers in certificates.
The subject DN MUST be unique for each subject entity certified by a single CA as defined by the issuer name field, and where non-empty it MUST contain an X.500 distinguished name.
When identifierValue is absent, the value of the serialNumber attribute from the deepest RDN of the subject DN is used as the identifierValue. In such a case, there MUST be at least one serialNumber attribute in the subject DN; otherwise the PermanentIdentifier SHALL NOT be used.
The permanent identifier allows organizations to create links between different certificates associated with an entity across overlapping or non-overlapping validity periods. This ability to link certificates conflicts with privacy, and CAs must clearly disclose plans to issue such certificates to potential subjects.
The PermanentIdentifier is defined as an otherName form within the GeneralName structure of the subjectAltName extension. It is an ASN.1 SEQUENCE with two optional fields: identifierValue (UTF8String) and assigner (OBJECT IDENTIFIER). The OID is id-on-permanentIdentifier ::= { id-on 3 }.
When assigner is absent and identifierValue is present, the Assigner Authority is the issuing CA and the identifier is only local to that CA. Two such identifiers match if and only if the issuer DNs match using distinguishedNameMatch and the identifierValue fields consist of the same Unicode code points in the same order.
When assigner is present and identifierValue is absent, the serialNumber from the deepest relevant RDN is used as identifierValue and the identifier is globally unique. Two such identifiers match if their assigner fields match and the serialNumber attributes match using caseIgnoreMatch.
When both assigner and identifierValue are absent, the serialNumber attribute from the deepest relevant RDN is used as identifierValue and the identifier is local to the CA. Two such identifiers match if the issuer DNs match and the serialNumber attributes match using caseIgnoreMatch.
When both assigner and identifierValue are present, the permanent identifier is globally unique among all CAs. Two such identifiers match if and only if their assigner fields match and the identifierValue fields consist of the same Unicode code points in the same order.
No new IANA registry is created. The document notes that organizations may use IANA Private Enterprise Numbers (prefix 1.3.6.1.4.1) to construct OIDs for the assigner field. No IANA actions are necessary for the permanent identifier itself.
It is the responsibility of the CA to verify that the permanent identifier being included in the certificate refers to the subject being certified. When the assigner field is present, this allows cross-CA comparison of certificates for the same entity.
Two certificates issued under the same issuer DN containing the same permanent identifier without an assigner field do not necessarily refer to the same entity, because the issuer DN may not be globally unique. Additional checks (e.g., comparing CA public keys or certification path sequences) are required, and CA key rollover further complicates matching.
When a public key certificate contains attribute extensions, the permanent identifier should not be used for access control but only for audit purposes, because certificate attributes may change and access could be granted on attributes no longer present in the current certificate.
PermanentIdentifier ASN.1 encoding: SEQUENCE { identifierValue UTF8String OPTIONAL, assigner OBJECT IDENTIFIER OPTIONAL }. The identifierValue carries the identifier as UTF-8 encoded Unicode; the assigner field carries the OID identifying both the Assigner Authority and the type of identifier.