Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
Extracted elements (25)
SIM encodes a privacy-sensitive identifier (e.g., Social Security Number) in the subjectAltName extension as an otherName rather than in plaintext, because direct inclusion would disclose the identifier to anyone who views the certificate. The double-hash construction with a user-chosen password and RA-generated random value protects the SII even if the certificate is posted in a public directory.
SIM leverages the existing otherName field in subjectAltName rather than defining a new certificate field, because otherName is widely supported (e.g., smart card logon) and implementations that do not process sensitive identifiers are unaffected. An alternative format would increase implementation cost without enhancing security.
SIM MUST be used only with protocols that employ digital signatures generated using the subject's private key. Without this constraint, a relying party who learns P and SII could impersonate the subject, since knowledge of those values alone is insufficient to authenticate without proof of private key possession.
The third use case—where a subject proves knowledge of an SII without disclosing it—uses the intermediate PEPSI value H(P || R || SIItype || SII) rather than P or SII directly. This allows a relying party to verify the subject's knowledge without learning the actual SII, preserving privacy while still providing identity assurance.
The SIM is placed in the subjectAltName extension as an otherName, so implementations that do not process SIM values can ignore it without affecting other certificate processing. Implementations must handle both SHA-1 and SHA-256 for PEPSI generation and verification.
A new random value R MUST be generated for each SIM, and the length of R MUST equal the output length of the hash algorithm H (e.g., 160 bits for SHA-1).
A secure communication channel MUST be used to pass P and SII from the end entity to the RA, to protect them from disclosure or modification.
Before calculating a PEPSI, conforming implementations MUST process the userPassword with the six-step LDAPBIS stringprep algorithm, with the mapping step extended to include characters mapped to nothing (RFC 3454 Appendix B.1) and step 6 (Insignificant Character Removal) omitted.
Implementations MUST permit a user to select passwords of up to 28 characters. RAs SHOULD implement password filter rules to prevent selection of trivial passwords.
RAs MUST calculate the SIM value as R || PEPSI where PEPSI = H(H(P || R || SIItype || SII)). Both SHA-1 and SHA-256 MUST be supported for generation and verification of PEPSI values.
SHA-1 or SHA-256 SHOULD be used wherever interoperability is a concern; other one-way hash functions are not precluded.
The RA SHOULD encrypt SIItype, SII, and SIM and send the result to the CA via a secure channel when the CA needs to verify SII before issuing a certificate. The user SHOULD also encrypt the same values in the certificate request.
The SIM feature MUST be used only in conjunction with protocols that make use of digital signatures generated using the subject's private key.
When a PKCS#10 certificate request is used, the SIM alternative name MUST be placed in the subjectAltName extension. If the CA verifies SII before issuance, the SIM value in the request MUST be conveyed in EPEPSI form.
Whenever a certificate is updated, a new R SHOULD be generated and the SIM SHOULD be recomputed, because reusing a prior SIM value allows an attacker to correlate certificates associated with the same individual.
Reusing the same SIM across certificate renewals enables linkability: an attacker can correlate successive certificates to the same individual. Generating a fresh R and recomputing the SIM at each renewal prevents this correlation.
SIItype is an Object Identifier that defines the format and scope of the Sensitive Identification Information. For closed communities the CA may assign the OID, but registration is recommended. An example Korean SIItype OID hierarchy is provided under id-KISA { iso(1) member-body(2) 410 200004 }.
SIM is defined as R || PEPSI, where PEPSI = H(H(P || R || SIItype || SII)). It is encoded as an otherName in the subjectAltName extension using the OID id-on-SIM { id-pkix 8 6 }.
IANA may be asked in the future to establish a registry of object identifiers for SII types to promote interoperability. No registry is created by this document at publication time.
Because SIIs (e.g., Social Security Numbers) are short and partially predictable from demographic data, a weak user password significantly lowers the attacker's work factor. Users must select strong passwords to prevent guessing attacks on SIMs.
Confidentiality of SIM relies on iterated hashing with the RA-supplied random R. Known SHA-1 collision attacks (Wang et al., Crypto 2005) are not applicable because the RA provides R and the end entity does not control all hashed inputs.
The protocol trusts the relying party (Bob) not to reuse Alice's P and SII to impersonate her. If the relying party is untrusted, combining P and SII knowledge with a certificate could enable impersonation; hence the MUST requirement for digital-signature-based protocols.
EncryptedPEPSI (EPEPSI) is an ASN.1 SEQUENCE with fields: identifierType (OID), identifier (UTF8String for SII), and sIM (SIM SEQUENCE). When used in a certificate request it appears in regInfo with OID id-regEPEPSI ::= { id-pkip 3 }.
HashContent is an ASN.1 SEQUENCE with four fields: userPassword (UTF8String), authorityRandom (OCTET STRING), identifierType (OBJECT IDENTIFIER for SIItype), and identifier (UTF8String for SII). PEPSI is computed as H(H(HashContent encoding)).
The SIM ASN.1 SEQUENCE contains three fields: hashAlg (AlgorithmIdentifier identifying H), authorityRandom (OCTET STRING, length equal to H output size, RA-chosen), and pEPSI (OCTET STRING, the double-hash result). OID is id-on-SIM ::= { id-pkix 8 6 }.