diff options
Diffstat (limited to 'doc/rfc/rfc4683.txt')
| -rw-r--r-- | doc/rfc/rfc4683.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc4683.txt b/doc/rfc/rfc4683.txt new file mode 100644 index 0000000..564bc2a --- /dev/null +++ b/doc/rfc/rfc4683.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group J. Park +Request for Comments: 4683 J. Lee +Category: Standards Track H. Lee + KISA + S. Park + BCQRE + T. Polk + NIST + October 2006 + + + Internet X.509 Public Key Infrastructure + Subject Identification Method (SIM) + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines the Subject Identification Method (SIM) for + including a privacy-sensitive identifier in the subjectAltName + extension of a certificate. + + The SIM is an optional feature that may be used by relying parties to + determine whether the subject of a particular certificate is also the + person corresponding to a particular sensitive identifier. + + + + + + + + + + + + + + + +Park, et al. Standards Track [Page 1] + +RFC 4683 Subject Identification Method October 2006 + + +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 ...............18 + +1. Introduction + + A Certification Authority (CA) issues X.509 public key certificates + to bind a public key to a subject. The subject is specified through + one or more subject names in the "subject" or "subjectAltName" fields + of a certificate. The "subject" field contains a hierarchically + structured distinguished name. The "subjectAltName field" may + contain an electronic mail address, IP address, or other name forms + that correspond to the subject. + + For each particular CA, a subject name corresponds to a unique + person, device, group, or role. The CA will not knowingly issue + certificates to multiple entities under the same subject name. That + is, for a particular certificate issuer, all currently valid + certificates asserting the same subject name(s) are bound to the same + entity. + + + + +Park, et al. Standards Track [Page 2] + +RFC 4683 Subject Identification Method October 2006 + + + Where the subject is a person, the name that is specified in the + subject field of the certificate may reflect the name of the + individual and affiliated entities (e.g., their corporate + affiliation). In reality, however, there are individuals or + corporations that have the same or similar names. It may be + difficult for a relying party (e.g., a person or application) to + associate the certificate with a specific person or organization + based solely on the subject name. This ambiguity presents a problem + for many applications. + + In some cases, applications or relying parties need to ensure that + the subject of certificates issued by different CAs are in fact the + same entity. This requirement may be met by including a "permanent + identifier" in all certificates issued to the same subject, which is + unique across multiple CAs. By comparing the "permanent identifier", + the relying party may identify certificates from different CAs that + are bound to the same subject. This solution is defined in [RFC + 4043]. + + In many cases, a person's or corporation's identifier (e.g., a Social + Security Number) is regarded as sensitive, private, or personal data. + Such an identifier cannot simply be included as part of the subject + field, since its disclosure may lead to misuse. Therefore, privacy- + sensitive identifiers of this sort should not be included in + certificates in plaintext form. + + On the other hand, such an identifier is not actually a secret. + People choose to disclose these identifiers for certain classes of + transactions. For example, a person may disclose a Social Security + Number to open a bank account or obtain a loan. This is typically + corroborated by presenting physical credentials (e.g., a driver's + license) that confirm the person's name or address. + + To support such applications in an online environment, relying + parties need to determine whether the subject of a particular + certificate is also the person corresponding to a particular + sensitive identifier. Ideally, applications would leverage the + applicants' electronic credential (e.g., the X.509 public key + certificate) to corroborate this identifier, but the subject field of + a certificate often does not provide sufficient information. + + To fulfill these demands, 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. Although other solutions for binding + privacy-sensitive identifiers to a certificate could be developed, + the method specified in this document has especially attractive + properties. This specification extends common PKI practices and + + + +Park, et al. Standards Track [Page 3] + +RFC 4683 Subject Identification Method October 2006 + + + mechanisms to allow privacy-sensitive identifiers to be included in + the certificate as well. The SIM mechanism also permits the subject + to control exposure of the sensitive identifier; when the subject + chooses to expose the sensitive identifier, relying parties can + verify the binding. Specifically: + + (1) A Public Key Infrastructure (PKI) depends upon 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 may also be specified in terms of RFC 822 + addresses or DNS names. The SIM specification allows the same + trusted third party -- the CA -- that binds a name to the public key + to include a privacy-sensitive identifier in the certificate as well. + Since the relying party (RP) already trusts the CA to issue + certificates, it is a simple extension to cover verification and + binding of a sensitive identifier as well. This binding could be + established separately, by another trusted third party, but this + would complicate the infrastructure. + + (2) This specification leverages standard PKI extensions to achieve + new functional goals with a minimum of new code. This specification + encodes the sensitive identifier in the otherName field in the + alternative subject name extension. Since otherName field is widely + used, this solution leverages a certificate field that is often + populated and processed. (For example, smart card logon + implementations generally rely upon names encoded in this field.) + Whereas implementations of this specification will require some SIM- + specific code, an alternative format would increase cost without + enhancing security. In addition, that has no impact on + implementations that do not process sensitive identifiers. + + (3) By explicitly binding the public key to the identifier, this + specification allows the relying party to confirm the claimant's + identifier and confirm that the claimant is the subject of that + identifier. That is, 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 upon the architecture). + + To achieve the same goal in a separate message (e.g., a signed and + encrypted Secure MIME (S/MIME) object), the message would need to be + bound to the certificate or an identity in the certificate (e.g., the + X.501 distinguished name). The former solution is problematic, since + certificates expire. The latter solution may cause problems if names + are ever reused in the infrastructure. An explicit binding in the + certificate is a simpler solution, and more reliable. + + + + + + +Park, et al. Standards Track [Page 4] + +RFC 4683 Subject Identification Method October 2006 + + + (4) This specification allows the subject of the privacy-sensitive + identifier to control the distribution and level of security applied + to the identifier. 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 ensure + that the identifier is protected against brute force attacks. This + specification permits subjects to selectively disclose an identifier + where they deem it appropriate, which is consistent with common use + of such identifiers. + + (5) Certificates that contain a sensitive identifier may still be + used to support other applications. A party that obtains a + certificate containing a sensitive identifier, but to whom the + subject does not choose to disclose the identifier, must perform a + brute force attack to obtain the identifier. By selecting a strong + hash algorithm, this attack becomes computationally infeasible. + Moreover, when certificates include privacy-sensitive identifiers as + described in this specification, each certificate must be attacked + separately. Finally, the 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. + + In addition, this document defines an Encrypted PEPSI (EPEPSI) so + that sensitive identifier information can be exchanged during + certificate issuance processes without disclosing the identifier to + an eavesdropper. + + This document is organized as follows: + + - Section 3 establishes security and usability requirements; + - Section 4 provides 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]. + + + + + + + + +Park, et al. Standards Track [Page 5] + +RFC 4683 Subject Identification Method October 2006 + + +2. Symbols + + The following cryptography symbols are defined in 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 + + We make the following assumptions about the context in which SIM and + PEPSI are to be employed: + + - Alice, a certificate holder, with a sensitive identifier SIIa + (such as her Social Security Number) + - Bob, a relying party who will require knowledge of Alice's SIIa + - Eve, an attacker who acquires Alice's certificate + - An RA to whom Alice must divulge her SIIa + - A CA who will issue Alice's certificate + + We wish to design SIM and PEPSI, using a password that Alice chooses, + that has the following properties: + + - Alice can prove her SII, SIIa to Bob. + + + + + +Park, et al. Standards Track [Page 6] + +RFC 4683 Subject Identification Method October 2006 + + + - Eve has a large work factor to determine Alice's SIIa from + Alice's certificate, even if Alice chooses a weak password, and a + very large work factor if Alice chooses a good password. + - Even if Eve can determine SIIa, she has an equally hard problem + to find any other SII values from any other PEPSI; that is, there + is nothing she can pre-compute that helps her attack PEPSIs in + other certificates, and nothing she learns from a successful + attack that helps in any other attack. + - The CA does not learn Alice's SIIa except in the case where the + CA needs to validate the SII passed by the RA. + - The CA can treat the SIM as an additional name form in the + "subjectAltName" extension with no special processing. + - Alice cannot find another SII (SIIx), and a password (P), that + will allow her to use her certificate to assert a false SII. + +3.2. Usability Requirements + + In addition to the security properties stated above, we have the + following usability requirements: + + - When SIM and PEPSI are used, any custom processing occurs at the + relying party. Alice can use commercial off-the-shelf software + (e.g., a standard browser) without modification in conjunction + with a certificate containing a SIM value. + +3.3. Solution + + We define SIM as: R || PEPSI + where PEPSI = H(H( P || R || SIItype || SII)) + + The following steps describe construction and use of SIM: + + 1. Alice picks a password P, and gives P, SIItype, and SII to + the RA (via a secure channel). + 2. The RA validates SIItype and SII; i.e., it determines that + the SII value is correctly associated with the subject and + the SIItype is correct. + 3. The RA generates a random value R. + 4. The RA generates the SIM = (R || PEPSI) where PEPSI = H(H(P + || R || SIItype || SII)). + 5. The RA sends the SIM to Alice by some out-of-band means and + also passes it to the CA. + 6. Alice sends a certRequest to CA. The CA generates Alice's + certificate including the SIM as a form of otherName from the + GeneralName structure in the subjectAltName extension. + 7. Alice sends Bob her Cert, as well as P, SIItype, and SII. + The latter values must be communicated via a secure + communication channel, to preserve their confidentiality. + + + +Park, et al. Standards Track [Page 7] + +RFC 4683 Subject Identification Method October 2006 + + + 8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and + compare SIM' = R || PEPSI' to the SIM value in Alice's + certificate, thereby verifying SII. + + If Alice's SII value is not required by Bob (Bob already knows + Alice's SII and does not require it), then steps 7 and 8 are as + follows: + + 7. Alice sends Bob her Cert and P. P must be sent via a secure + communication channel, to preserve its confidentiality. + 8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and + compare SIM' = R || PEPSI' to the value in the SIM, thereby + verifying SII. + + If Alice wishes to prove she is the subject of an RA-validated + identifier, without disclosing her identifier to Bob, then steps 7 + and 8 are as follows: + + 7. Alice sends the intermediate value H(P || R || SIItype || + SII) and her certificate to Bob. + 8. Bob can get R from the SIM in the certificate, then compute H + (intermediate value) and compare it to the value in SIM, + thereby verifying Alice's knowledge of P and SII. + + Eve has to exhaustively search the H(P || R || SIItype || SII) space + to find Alice's SII. This is a fairly hard problem even if Alice + uses a poor password, because of the size of R (as specified 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 constructs a massive + dictionary of P and SII values, it does not help find any other SII + values, because a new R is used for each PEPSI and SIM. + +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 as follows: + + -- KISA specific arc + id-KISA OBJECT IDENTIFIER ::= + {iso(1) member-body(2) korea(410) kisa(200004)} + + + + + +Park, et al. Standards Track [Page 8] + +RFC 4683 Subject Identification Method October 2006 + + + -- 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 selects a password as one of the input values for computing + the SIM. The strength of the password is critical to protection of + the user's SII, in the following sense. If an attacker has a + candidate SII value, and wants to determine whether the SIM value in + a specific subject certificate, P is the only protection for the SIM. + The user should be encouraged to select passwords that will be + difficult to be guessed, and long enough to protect against 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 user selection of trivial passwords. See + [FIPS 112] and [FIPS 180-1] for security criteria for passwords and + 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)) + + + + +Park, et al. Standards Track [Page 9] + +RFC 4683 Subject Identification Method October 2006 + + + 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 does not preclude 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 passing 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, 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 for verifying the user's SII. + + Where the results from 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 is a + local matter. + + The syntax and the associated OID for EPEPSI is 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, collectively signed by + + + +Park, et al. Standards Track [Page 10] + +RFC 4683 Subject Identification Method October 2006 + + + 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, a CA decrypts the EPEPSI values it receives from both + the user and the RA, and 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 the 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 + } + + + + + + + + +Park, et al. Standards Track [Page 11] + +RFC 4683 Subject Identification Method October 2006 + + +5.2. PEPSI + + This section specifies the syntax for the PEPSI. The PEPSI is + generated by performing the same hash function twice. The PEPSI is + generated over the ASN.1 structure HashContent. HashContent 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 is used in a certificate request, the OID in 'regInfo' of + [RFC4211] and [RFC2986] is as follows: + + id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 } + + + + + + + + + +Park, et al. Standards Track [Page 12] + +RFC 4683 Subject Identification Method October 2006 + + +6. Example Usage of SIM + + Depending on different security environments, there are three + possible use cases with SIM. + + 1. When a relying party does not have any information about the + certificate user. + 2. When a relying party already knows the SII of the + certificate user. + 3. When the certificate user does not want to disclose his SII. + + For the use case 1, the SII and a user-chosen password P (which only + the user knows) must be sent to a relying party via a secure + communication channel; the certificate including the SIM also must be + transmitted. The relying party acquires R from the certificate. The + relying party can verify that the SII was validated by the CA (or RA) + and is associated with the entity that presented the password and + certificate. In this case, the RP learns which SII is bound to the + subject as a result of the procedure. + + In case 2, a certificate user transmits only the password, P, and the + certificate. The rest of the detailed procedure is the same as case + 1, but here the relying party supplies the SII value, based on its + external knowledge of that value. The purpose in this case is to + enable the RP to verify that the subject is bound to the SII, + presumably because the RP identifies the subject based on this SII. + + In the last case, the certificate user does not want to disclose his + or her SII because of privacy concerns. Here the only information + sent by a certificate subject is the intermediate value of the PEPSI, + H(R || P || SIItype || SII). This value MUST be transmitted via a + secure channel, to preserve its confidentiality. Upon receiving this + value, the relying party applies the hash function to the + intermediate PEPSI value sent by the user, and matches it against the + SIM value in the user's certificate. The relying party does not + learn the user's SII value as a result of this processing, but the + relying party can verify the fact that the user knows the right SII + and password. This gives the relying party more confidence that the + user is the certificate subject. Note that this form of user + identity verification is NOT to be used in lieu of standard + certificate validation procedures, but rather in addition to such + procedures. + +7. Name Constraints + + The SIM value is stored as an otherName of a subject alternative + name; however, there are no constraints that can be placed on this + form of the name. + + + +Park, et al. Standards Track [Page 13] + +RFC 4683 Subject Identification Method October 2006 + + +8. Security Considerations + + Confidentiality for a SIM value is created by the iterated hashing of + the R, P, and SII values. A SIM value depends on two properties of a + hash function: the fact that it cannot be inverted and the fact that + collisions (especially with formatted data) are rare. The current + attacks by [WANG] are not applicable to SIM values since the end + entity supplying the SII and SIItype values does not supply all of + the data being hashed; i.e., the RA provides the R value. + + In addition, a fairly good password is needed to protect against + guessing attacks on SIMs. Due to the short length of many SIIs, it + is possible that an attacker may be able to guess it with partial + information about gender, age, and date of birth. SIItype values are + very limited. Therefore, it is important for users to select a + fairly good password to prevent an attacker from determining whether + a guessed SII is accurate. + + This protocol assumes that Bob is a trustworthy relying party who + will not reuse the Alice's information. Otherwise, Bob could + "impersonate" Alice if only knowledge of P and SII were used to + verify a subject's claimed identity. Thus, this protocol MUST be + used only with the protocols that make use of digital signatures + generated using the subject's private key. + + Digital signatures are used by a message sender to demonstrate + knowledge of the private key corresponding to the public key in a + certificate, and thus to authenticate and bind his or her identity to + a signed message. However, managing a private key is vulnerable + under certain circumstances. It is not fully guaranteed that the + claimed private key is bound to the subject of a certificate. So, + the SIM can enhance verification of user identity. + + Whenever a certificate needs to be updated, a new R SHOULD be + generated and the SIM SHOULD be recomputed. Repeating the value of + the SIM from a previous certificate permits an attacker to identify + certificates associated with the same individual, which may be + undesirable for personal privacy purposes. + + + + + + + + + + + + + +Park, et al. Standards Track [Page 14] + +RFC 4683 Subject Identification Method October 2006 + + +9. Acknowledgements + + Jim Schaad (Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon, + Baehyo Park (KISA), Bill Burr, Morrie Dworkin (NIST), and the + Internet Security Technology Forum (ISTF) have significantly + contributed to work on the SIM and PEPSI concept and identified a + potential security attack. Also their comments on the set of + desirable properties for the PEPSI and enhancements to the PEPSI were + most illumination. Also, thanks 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 establish a registry of object + identifiers to promote interoperability in the specification of 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. + + + +Park, et al. Standards Track [Page 15] + +RFC 4683 Subject Identification Method October 2006 + + + [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 + + + + + + + + + + +Park, et al. Standards Track [Page 16] + +RFC 4683 Subject Identification Method October 2006 + + + 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.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park, et al. Standards Track [Page 17] + +RFC 4683 Subject Identification Method October 2006 + + +Appendix 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, + + + +Park, et al. Standards Track [Page 18] + +RFC 4683 Subject Identification Method October 2006 + + + -- 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 + } + + END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park, et al. Standards Track [Page 19] + +RFC 4683 Subject Identification Method October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein 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 + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Park, et al. Standards Track [Page 20] + |