RFC 4683
Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
RFC 4683 💖 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) 🎀
okay bestie, let's start with the basics ✨ This RFC is by J. Park, J. Lee, H. Lee (KISA), S. Park (BCQRE), and T. Polk (NIST), published in October 2006 in the Network Working Group. It's on the Standards Track, so it's an actual Internet standard and not just an idea someone floated. 💅 The title block doesn't list any documents it obsoletes or updates, so nothing gets replaced or patched here. 🌸
Status of This Memo ✨
so this is the official status part 🧚 It specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. 🫶 If you want the current standardization state of this protocol, check the "Internet Official Protocol Standards" (STD 1) document. Distribution of this memo is unlimited, so anyone can share it. 🦋
Copyright Notice 💖
Copyright (C) The Internet Society (2006).the copyright is held by The Internet Society, and it's from 2006 🌈
Abstract 🦋
this is the tea in one paragraph ✨ The document defines the Subject Identification Method (SIM), which lets you put a privacy-sensitive identifier into the subjectAltName extension of a certificate. 🔥
The SIM is an optional feature. Relying parties can use it to check whether the subject of a particular certificate is also the person tied to a particular sensitive identifier. 👑 it's giving privacy with receipts 💅
Table of Contents 🌸
1. Introduction ....................................................2
1.1. Key Words ..................................................5
2. Symbols .........................................................6
3. Requirements ....................................................6
3.1. Security Requirements ......................................6
3.2. Usability Requirements .....................................7
3.3. Solution ...................................................7
4. Procedures ......................................................8
4.1. SII and SIItype ............................................8
4.2. User Chosen Password .......................................9
4.3. Random Number Generation ...................................9
4.4. Generation of SIM ..........................................9
4.5. Encryption of PEPSI .......................................10
4.6. Certification Request .....................................10
4.7. Certification .............................................11
5. Definition .....................................................11
5.1. SIM Syntax ................................................11
5.2. PEPSI .....................................................12
5.3. Encrypted PEPSI ...........................................12
6. Example Usage of SIM ...........................................13
7. Name Constraints ...............................................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................15
10. IANA Considerations ...........................................15
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax ...............18that's the whole map, bestie 🧚💜
1. Introduction ✨
Okay so a Certification Authority (CA) issues X.509 public key certificates to bind a public key to a subject 🔑. The subject gets identified through one or more subject names in the subject or subjectAltName fields. The subject field holds a hierarchically structured distinguished name, and the subjectAltName field can hold an electronic mail address, IP address, or other name forms that match the subject 💖.
For each CA, a subject name points to one unique person, device, group, or role. The CA will not knowingly issue certificates to multiple entities under the same subject name 🙅♀️. So for a particular certificate issuer, every currently valid certificate asserting the same subject name(s) is bound to the same entity. Bestie, that's the whole promise 🫶.
When the subject is a person, the name in the subject field might reflect their name and affiliations, like their corporate affiliation 🎀. But ngl, real life is messy, because there are individuals and corporations with the same or similar names 😭. It can be hard for a relying party (like a person or an application) to link a certificate to a specific person or organization using only the subject name. That ambiguity is a real problem for a lot of applications 💀.
Some apps need to make sure the subjects of certificates from different CAs are actually the same entity 👯♀️. One way to handle this is a "permanent identifier" included in every certificate issued to the same subject, unique across multiple CAs. By comparing that permanent identifier, a relying party can spot certificates from different CAs that belong to the same subject 🦋. This solution is defined in [RFC 4043].
Now here's the tricky part. A person's or corporation's identifier (like a Social Security Number) is often treated as sensitive, private, or personal data 🙈. You can't just drop that identifier into the subject field, because disclosing it may lead to misuse. So privacy-sensitive identifiers of this sort should not be included in certificates in plaintext form 🔒.
BUT (and this is the plot twist) that identifier isn't actually a secret 🤷♀️. People choose to share these identifiers for certain kinds of transactions. For example, someone might give their Social Security Number to open a bank account or get a loan 🏦. This is usually backed up by showing physical credentials (like a driver's license) that confirm the person's name or address 🪪.
To make this work online, relying parties need to figure out whether the subject of a particular certificate is also the person tied to a particular sensitive identifier 👀. Ideally, applications would use the applicant's electronic credential (like the X.509 public key certificate) to back up that identifier. But the subject field often doesn't carry enough info for that 😤.
So this specification defines the Subject Identification Method (SIM) and the Privacy-Enhanced Protected Subject Information (PEPSI) format for including a privacy-sensitive identifier in a certificate ✨. Other solutions for binding privacy-sensitive identifiers to a certificate could be developed, but the method in this document has especially attractive properties 👑. It extends common PKI practices and mechanisms so privacy-sensitive identifiers can go in the certificate too. The SIM mechanism also lets the subject control how exposed the sensitive identifier is. When the subject chooses to expose it, relying parties can verify the binding 🌈. Specifically:
(1) A Public Key Infrastructure (PKI) depends on a trusted third party, the CA, to bind one or more identities to a public key 🧚. Traditional PKI implementations bind X.501 distinguished names to the public key, but identity can also be specified with RFC 822 addresses or DNS names. The SIM specification lets that same trusted third party (the CA that binds a name to the public key) include a privacy-sensitive identifier in the certificate as well. Since the relying party (RP) already trusts the CA to issue certificates, covering verification and binding of a sensitive identifier is a simple extension 💅. This binding could be set up separately by another trusted third party, but that would complicate the infrastructure 😵💫.
(2) This specification uses standard PKI extensions to hit new functional goals with minimal new code 🧠. It encodes the sensitive identifier in the otherName field of the alternative subject name extension. Since the otherName field is widely used, this solution takes advantage of a certificate field that's often filled in and processed 🎀. (For example, smart card logon implementations generally rely on names encoded in this field.) Implementations of this specification will need some SIM-specific code, but an alternative format would add cost without improving security 💸. Also, this has no impact on implementations that don't process sensitive identifiers 🙌.
(3) By explicitly binding the public key to the identifier, this specification lets the relying party confirm the claimant's identifier and confirm that the claimant is the subject of that identifier 🔐. Basically, proof of possession of the private key confirms that the claimant is the same person whose identity was confirmed by the PKI (CA or RA, depending on the architecture) 🥹.
To get the same goal in a separate message (for example, a signed and encrypted Secure MIME (S/MIME) object), the message would need to be bound to the certificate or to an identity in the certificate (like the X.501 distinguished name). The first option is problematic because certificates expire ⏳. The second can cause problems if names are ever reused in the infrastructure 😬. An explicit binding in the certificate is simpler and more reliable 💜.
(4) This specification lets the subject of the privacy-sensitive identifier control how the identifier is distributed and how much security is applied to it 🛡️. The identifier is only disclosed when the subject chooses to disclose it, even if the certificate is posted in a public directory. By choosing a strong password, the subject can make sure the identifier is protected against brute force attacks 💪. This specification allows subjects to selectively disclose an identifier wherever they think it's appropriate, which matches the common way these identifiers get used 🍓.
(5) Certificates that contain a sensitive identifier can still be used to support other applications 🌸. A party that gets a certificate containing a sensitive identifier, but to whom the subject does not choose to disclose it, has to run a brute force attack to get the identifier. By selecting a strong hash algorithm, this attack becomes computationally infeasible 🙅♀️. Also, when certificates include privacy-sensitive identifiers as described here, each certificate has to be attacked separately 🔥. And finally, subjects can use this mechanism to prove they possess a certificate containing a particular type of identifier without actually disclosing it to the relying party 🪄.
This feature MUST be used only in conjunction with protocols that make use of digital signatures generated using the subject's private key. Non-negotiable, bestie 🚨.
On top of all that, this document defines an Encrypted PEPSI (EPEPSI) so sensitive identifier information can be exchanged during certificate issuance without disclosing the identifier to an eavesdropper 🕵️♀️✨.
This document is organized as follows:
- Section 3 establishes security and usability requirements 📋;
- Section 4 gives an overview of the mechanism 🗺️;
- Section 5 defines syntax and generation rules 🧩; and
- Section 6 provides example use cases 🎬.
1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Yes, these words are capitalized on purpose, and they carry real weight 🤓.
2. Symbols
Here's the cryptography symbol cheat sheet for this document 🧁:
H() Cryptographically secure hash algorithm.
SHA-1 [FIPS 180-1] or a more secure hash function is
required.
SII Sensitive Identification Information
(e.g., Social Security Number).
SIItype Object Identifier that identifies the type of SII.
P A user-chosen password.
R The random number value generated by a Registration
Authority (RA).
PEPSI Privacy-Enhanced Protected Subject Information.
Calculated from the input value P, R, SIItype, SII
using two iteration of H().
E() The encryption algorithm to encrypt the PEPSI value.
EPEPSI Encrypted PEPSI.
D() The decryption algorithm to decrypt the EPEPSI.3. Requirements
3.1. Security Requirements
Let's set the scene 🎭. We're assuming the following about the context where SIM and PEPSI get used:
- Alice, a certificate holder, with a sensitive identifier SIIa (such as her Social Security Number) 👩
- Bob, a relying party who will need to know Alice's SIIa 🧑💼
- Eve, an attacker who gets hold of Alice's certificate 😈
- An RA that Alice has to hand her SIIa to 📨
- A CA that will issue Alice's certificate 🏛️
We want to design SIM and PEPSI, using a password Alice picks, with these properties 💅:
- Alice can prove her SII, SIIa, to Bob 🙌.
- Eve has a large work factor to figure out Alice's SIIa from Alice's certificate, even if Alice picks a weak password, and a very large work factor if Alice picks a good password 💪.
- Even if Eve can figure out SIIa, she has an equally hard problem finding any other SII values from any other PEPSI. In other words, there's nothing she can pre-compute that helps her attack PEPSIs in other certificates, and nothing she learns from a successful attack helps in any other attack 🧱.
- The CA doesn't learn Alice's SIIa, except when the CA needs to validate the SII passed by the RA 🫣.
- The CA can treat the SIM as an additional name form in the
subjectAltNameextension with no special processing 🧃. - Alice cannot find another SII (SIIx) and a password (P) that would let her use her certificate to assert a false SII 🚫.
3.2. Usability Requirements
Besides the security properties above, there are also these usability requirements 🎀:
- When SIM and PEPSI are used, any custom processing happens at the relying party. Alice can use commercial off-the-shelf software (e.g., a standard browser) without modification with a certificate containing a SIM value 🦋.
3.3. Solution 💖
okay so the big idea is that we define SIM as R || PEPSI, where PEPSI = H(H( P || R || SIItype || SII)). 🎀 It's giving layers, and I'm obsessed.
Here's how the whole thing goes down ✨
- Alice picks a password P, then gives P, SIItype, and SII to the RA (via a secure channel) 🔐
- The RA validates SIItype and SII. Basically it checks that the SII value is correctly tied to the subject and that the SIItype is correct 🧐
- The RA generates a random value R 🎲
- The RA generates the SIM = (R || PEPSI), where PEPSI = H(H(P || R || SIItype || SII)) 🧮
- The RA sends the SIM to Alice by some out-of-band means, and also passes it to the CA 📬
- Alice sends a certRequest to the CA. The CA generates Alice's certificate with the SIM as a form of otherName from the GeneralName structure in the subjectAltName extension 📜
- Alice sends Bob her Cert, plus P, SIItype, and SII. The latter values must be communicated via a secure communication channel, to preserve their confidentiality 🤫
- Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and compare SIM' = R || PEPSI' to the SIM value in Alice's certificate, which verifies SII ✅
If Bob doesn't need Alice's SII (he already knows it and doesn't require it), then steps 7 and 8 become:
- Alice sends Bob her Cert and P. P must be sent via a secure communication channel, to preserve its confidentiality 🔒
- Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and compare SIM' = R || PEPSI' to the value in the SIM, which verifies SII 💅
If Alice wants to prove she's the subject of an RA-validated identifier without disclosing her identifier to Bob, then steps 7 and 8 look like this 🦋
- Alice sends the intermediate value H(P || R || SIItype || SII) and her certificate to Bob 🫣
- Bob can get R from the SIM in the certificate, then compute H (intermediate value) and compare it to the value in SIM. That verifies Alice's knowledge of P and SII 🧠
Now the bad guy, Eve, has to exhaustively search the H(P || R || SIItype || SII) space to find Alice's SII. That's a fairly hard problem even if Alice uses a poor password, because of how big R is (more on that later), and a really hard problem if Alice uses a fairly good password (see Section 8) 😤
Even if Eve finds Alice's P and SII, or builds a massive dictionary of P and SII values, it doesn't help her find any other SII values, because a new R is used for each PEPSI and SIM. Main character energy for R 👑
4. Procedures 🧚
4.1. SII and SIItype 🌸
The user presents evidence that a particular SII has been assigned to him/her. The SIItype is an Object Identifier (OID) that defines the format and scope of the SII value. For example, in Korea, one SIItype is defined like this 🇰🇷
-- KISA specific arc
id-KISA OBJECT IDENTIFIER ::=
{iso(1) member-body(2) korea(410) kisa(200004)}
-- KISA specific OIDs
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-kisa-identifyData OBJECT IDENTIFIER ::= {id-attribute 1}
id-VID OBJECT IDENTIFIER ::= {id-kisa-identifyData 10}
id-SII OBJECT IDENTIFIER ::= {id-VID 1}For closed communities, the SIItype value may be assigned by the CA itself, but it is still recommended that the OID be registered 📝
4.2. User Chosen Password 🔑
The user picks a password as one of the input values for computing the SIM. The strength of the password is critical to protecting the user's SII, in the following sense. If an attacker has a candidate SII value and wants to determine whether it matches the SIM value in a specific subject certificate, P is the only protection for the SIM. So the user should be encouraged to pick passwords that are hard to guess and long enough to stand up to brute force attacks 💪
Implementations of this specification MUST permit a user to select passwords of up to 28 characters. RAs SHOULD implement password filter rules to prevent users from picking trivial passwords 🚫. See [FIPS 112] and [FIPS 180-1] for security criteria for passwords, plus an automated password generator algorithm that randomly creates simple pronounceable syllables as passwords 🗣️
4.3. Random Number Generation 🎲
The RA generates a random number, R. A new R MUST be generated for each SIM. The length of R MUST be the same as the length of the output of the hash algorithm H. For example, if H is SHA-1, the random number MUST be 160 bits 🔢
A Random Number Generator (RNG) that meets the requirements defined in [FIPS 140-2] and its use is strongly recommended ✨
4.4. Generation of SIM 🧮
The SIM in the subjectAltName extension within a certificate identifies an entity, even if multiple subjectAltNames appear in a certificate. RAs MUST calculate the SIM value with the designated inputs according to the following algorithm 🙌
SIM = R || PEPSI
where PEPSI = H(H(P || R || SIItype || SII))The SII is made known to an RA at user enrollment. Both SHA-1 and SHA-256 MUST be supported for generation and verification of PEPSI values. This specification doesn't preclude the use of other one-way hash functions, but SHA-1 or SHA-256 SHOULD be used wherever interoperability is a concern 🤝
Note that 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 🛡️
The syntax and the associated OID for SIM are also provided in the ASN.1 modules in Section 5.1. Also, Section 5.2 describes the syntax for PEPSI in the ASN.1 modules 📖
4.5. Encryption of PEPSI 🔐
It may be required that the CA (not just the RA) verifies SII before issuing a certificate. To meet this requirement, the RA SHOULD encrypt the SIItype, SII, and SIM and send the result to the CA by a secure channel. The user SHOULD also encrypt the same values and send the result to the CA in his or her certificate request message. Then the CA compares these two results to verify the user's SII 👀
Where the results from the RA and the user are the EPEPSI:
EPEPSI = E(SIItype || SII || SIM)When the EPEPSI is used in a user certificate request, it is in regInfo of [RFC4211] and [RFC2986] 📝
Note: Specific encryption/decryption methods are not defined in this document. For transmission of the PEPSI value from a user to a CA, the certificate request protocol employed defines how encryption is performed. For transmission of this data between an RA and a CA, the details of how encryption is performed are a local matter 🙈
The syntax and the associated OID for EPEPSI are provided in the ASN.1 modules in Section 5.3 🧚
4.6. Certification Request 📨
As described above, a certificate request message MAY contain the SIM. [RFC2986] and [RFC4211] are widely used message syntaxes for certificate requests 💌
Basically, a PKCS#10 message consists of a distinguished name, a public key, and an optional set of attributes, all collectively signed by the end entity. The SIM alternative name MUST be placed in the subjectAltName extension if this certificate request format is used. If a CA verifies SII before issuing the certificate, the value of SIM in the certification request MUST be conveyed in the EPEPSI form and provided by the subject 🫶
4.7. Certification 🏅
A CA that issues certificates containing the SIM includes the SIM as a form of otherName from the GeneralName structure in the "subjectAltName" extension 📜
In an environment where a CA verifies SII before issuing the certificate, the CA decrypts the EPEPSI values it receives from both the user and the RA, then compares them. It then validates that the SII value is correctly bound to the subject 🔍
SIItype, SII, SIM = D(EPEPSI)5. Definition 📚
5.1. SIM Syntax 🧾
This section specifies the syntax for the SIM name form included in the subjectAltName extension. The SIM is composed of three fields: the hash algorithm identifier, the authority-chosen random value, and the value of the PEPSI itself 💜
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}5.2. PEPSI 🌈
This section specifies the syntax for the PEPSI. The PEPSI is generated by performing the same hash function twice. It's generated over the ASN.1 structure HashContent, which has four values: the user-selected password, the authority-chosen random number, the identifier type, and the identifier itself 🧩
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String -- SII
}Before calculating a PEPSI, conforming implementations MUST process the userPassword with the six-step [LDAPBIS STRPREP] string preparation algorithm, with the following changes 🧼
- In step 2, Map, the mapping shall include processing of characters commonly mapped to nothing, as specified in Appendix B.1 of [RFC3454].
- Omit step 6, Insignificant Character Removal.
5.3. Encrypted PEPSI 🎀
This section describes the syntax for the Encrypted PEPSI. The Encrypted PEPSI has three fields: identifierType, identifier, and SIM 🦋
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}When it's used in a certificate request, the OID in 'regInfo' of [RFC4211] and [RFC2986] is as follows:
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }6. Example Usage of SIM 🎀
okay so, SIM can be used in three different situations depending on how locked down the environment is 🔐
- When a relying party does not have any information about the certificate user.
- When a relying party already knows the SII of the certificate user.
- When the certificate user does not want to disclose his SII.
For case 1, the SII and a user-chosen password P (which only the user knows) must be sent to a relying party over a secure channel, and the certificate containing the SIM also has to be sent. The relying party gets R from the certificate. It can then check that the SII was validated by the CA (or RA) and is tied to the entity that showed the password and certificate. ✨ In this case the RP finds out which SII is bound to the subject as a result of the whole procedure, so it's giving full disclosure 👀
Case 2 is basically the same vibe. The certificate user only sends the password P and the certificate, and the rest of the procedure matches case 1. The difference is that the relying party supplies the SII value itself, based on what it already knows outside the protocol. The point here is for the RP to confirm that the subject is bound to that SII, probably because the RP identifies the subject using that SII in the first place 💅
Case 3 is the privacy-first one 🫶 The certificate user doesn't want to share their SII, so the only thing the subject sends is the intermediate PEPSI value, H(R || P || SIItype || SII). This value MUST be transmitted via a secure channel so that it stays confidential 🔒 When the relying party gets it, it hashes the intermediate PEPSI value the user sent and checks the result against the SIM value in the user's certificate. The RP never learns the user's SII from this, but it can still verify that the user knows the right SII and password, which makes it more confident the user really is the certificate subject. Important note: this form of identity verification is NOT to be used in lieu of standard certificate validation procedures. It's an extra layer on top of those procedures, not a replacement 🙅♀️
7. Name Constraints 🦋
The SIM value is stored as an otherName inside a subject alternative name. The catch is that no constraints can be placed on this form of the name, so there's nothing to restrict there 🤷♀️
8. Security Considerations 🔥
Okay, serious section incoming, bestie 😭 The confidentiality of a SIM value comes from iterated hashing of the R, P, and SII values. A SIM value leans on two properties of a hash function: it can't be inverted, and collisions (especially with formatted data) are rare. The current attacks described in [WANG] don't apply to SIM values, because the end entity supplying the SII and SIItype values doesn't supply all of the data being hashed. The RA provides the R value, so that's a whole other input the attacker doesn't control 🧚
Also, a fairly good password is needed to protect against guessing attacks on SIMs 🔐 Lots of SIIs are short, so an attacker might be able to guess one if they already have partial info about gender, age, and date of birth. SIItype values are also very limited. That's why users really need to pick a fairly good password, so an attacker can't tell whether a guessed SII is correct 💀
This protocol assumes that Bob is a trustworthy relying party who will not reuse Alice's information. If it weren't, Bob could "impersonate" Alice whenever only knowledge of P and SII was used to verify a subject's claimed identity. So this protocol MUST be used only with protocols that make use of digital signatures generated using the subject's private key. No exceptions, periodt 👑
Digital signatures are how a message sender shows they know the private key matching the public key in a certificate, which authenticates them and binds their identity to the signed message. The problem is that managing a private key can be vulnerable in some situations. It isn't fully guaranteed that the claimed private key is bound to the subject of a certificate, so the SIM can help strengthen verification of user identity 🫶
One more thing: whenever a certificate needs to be updated, a new R SHOULD be generated and the SIM SHOULD be recomputed. If you repeat the SIM value from a previous certificate, an attacker can use it to link certificates belonging to the same individual, and that can be a real problem for personal privacy 🙈
9. Acknowledgements 🌸
Huge thanks to Jim Schaad (Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon, Baehyo Park (KISA), Bill Burr, Morrie Dworkin (NIST), and the Internet Security Technology Forum (ISTF). They did a ton of work on the SIM and PEPSI concept and spotted a potential security attack. Their comments on the set of desirable properties for PEPSI, plus their suggested enhancements, were honestly so illuminating ✨ Also, thank you to Russell Housley, Stephen Kent, and Denis Pinkas for their contributions to this document 🩷
10. IANA Considerations 🧁
In the future, IANA may be asked to set up a registry of object identifiers, which would help promote interoperability when specifying SII types 🌈
11. References
11.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10:
Certification Request Syntax Specification Version
1.7", RFC 2986, November 2000.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC
3454, December 2002.
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public
Key Infrastructure Permanent Identifier", RFC 4043,
May 2005.
[RFC4211] Schaad, J., "Internet X.509 Public Key
Infrastructure Certificate Request Message Format
(CRMF)", RFC 4211, September 2005.11.2. Informative References 🦋
[LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String
Preparation", Work in Progress.
[FIPS 112] Fedreal Information Processing Standards
Publication (FIPS PUB) 112, "Password Usage", 30
May 1985.
[FIPS 180-1] Federal Information Processing Standards
Publication (FIPS PUB) 180-1, "Secure Hash
Standard", 17 April 1995.
[FIPS 140-2] Federal Information Processing Standards
Publication (FIPS PUB) 140-2, "Security
Requirements for Cryptographic Modules", 25 May
2001.
[WANG] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu,
"Finding Collisions in the Full SHA-1", Crypto'05.
<http://www.infosec.sdu.edu.cn/paper/sha1-crypto-
auth-new-2-yao.pdf>Authors' Addresses 🖊️
Jongwook Park
Korea Information Security Agency
78, Garak-Dong, Songpa-Gu, Seoul, 138-803
REPUBLIC OF KOREA
Phone: 2-405-5432
EMail: khopri@kisa.or.kr
Jaeil Lee
78, Garak-Dong, Songpa-Gu, Seoul, 138-803
REPUBLIC OF KOREA
Korea Information Security Agency
Phone: 2-405-5300
EMail: jilee@kisa.or.kr
Hongsub Lee
Korea Information Security Agency
78, Garak-Dong, Songpa-Gu, Seoul, 138-803
REPUBLIC OF KOREA
Phone: 2-405-5100
EMail: hslee@kisa.or.kr
Sangjoon Park
BCQRE Co.,Ltd
Yuil Bldg. Dogok-dong 411-14, Kangnam-ku, Seoul, 135-270
REPUBLIC OF KOREA
EMail: sjpark@bcqre.com
Tim Polk
National Institute of Standards and Technology
100 Bureau Drive, MS 8930
Gaithersburg, MD 20899
EMail: tim.polk@nist.govAppendix A. "Compilable" ASN.1 Module, 1988 Syntax 🧩
PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim2005(38) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
IMPORTS
AlgorithmIdentifier, AttributeTypeAndValue FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
-- SIM
-- SIM certificate OID
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
-- Certificate Syntax
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}
-- PEPSI
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String -- SII
}
-- Encrypted PEPSI
-- OID for encapsulated content type
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
ENDFull Copyright Statement ⭐
Copyright (C) The Internet Society (2006) 🌷
This document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights.
This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property ✨
Okay bestie, the IETF is being super careful here 💅 They're NOT saying whether any patents or other rights that might be claimed over the tech in this doc are valid, or how far they reach, and they're NOT saying they've gone looking for any of them either 🙈 If you want to know how licensing works for RFC documents, the answers are in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat are a whole thing too 📜 So are any assurances of licenses, plus the results of anyone trying to get a general license or permission for implementers or users to use those proprietary rights. You can find all of that in the IETF on-line IPR repository at http://www.ietf.org/ipr. It's giving organized paperwork energy 🗂️✨
And if you're an interested party who spots any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, please tell the IETF! 🫶 Send it to ietf-ipr@ietf.org. Lowkey the most helpful thing you can do for the community 🌸
Acknowledgement ✨
Last but not least, the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 💖 Thank you to the IASA for keeping the lights on, periodt 🌈
📦 where this page comes from
- ietf: rfc4683 2006-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms