idnits 2.17.1 draft-ietf-pkix-sim-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 831. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNIVERSAL 12' is mentioned on line 783, but not defined == Unused Reference: 'RFC 4043' is defined on line 671, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2511 (Obsoleted by RFC 4211) ** Obsolete normative reference: RFC 2314 (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) -- No information found for draft-ietf-ldapbis-strprep-xx - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group J.W. Park (KISA) 3 Internet Draft J.I. Lee (KISA) 4 Document: draft-ietf-pkix-sim-08.txt H.S. Lee (KISA) 5 Expires : August, 2006 S.J. Park (BCQRE) 6 Target category: Standard Track Polk, Tim (NIST) 7 February, 2006 9 Internet X.509 Public Key Infrastructure 10 Subject Identification Method (SIM) 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on August 20, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document defines the Subject Identification Method (SIM) for 45 including a privacy sensitive identifier in the subjectAltName 46 extension of a certificate. 48 The SIM is an optional feature that may be used by relying parties to 49 determine whether the subject of a particular certificate is also the 50 person corresponding to a particular sensitive identifier. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 55 2 Symbols . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3 Requirements . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 Security Requirements . . . . . . . . . . . . . . . . . 6 58 3.2 Usability Requirements . . . . . . . . . . . . . . . . 7 59 3.3 Solution . . . . . . . . . . . . . . . . . . . . . . . 7 60 4 Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1 SII and SIItype . . . . . . . . . . . . . . . . . . . . 8 62 4.2 User Chosen Password . . . . . . . . . . . . . . . . . 9 63 4.3 Random Number Generation . . . . . . . . . . . . . . . 9 64 4.4 Generation of SIM . . . . . . . . . . . . . . . . . . . 9 65 4.5 Encryption of PEPSI . . . . . . . . . . . . . . . . . . 10 66 4.6 Certification Request . . . . . . . . . . . . . . . . . 10 67 4.7 Certification . . . . . . . . . . . . . . . . . . . . . 11 68 5 Definition . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1 SIM Syntax . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2 PEPSI . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.3 Encrypted PEPSI . . . . . . . . . . . . . . . . . . . . 12 72 6 Example Usage of SIM . . . . . . . . . . . . . . . . . . 12 73 7 Name Constraints . . . . . . . . . . . . . . . . . . . . 13 74 8 Security Considerations . . . . . . . . . . . . . . . . . 13 75 9 IANA Considerations . . . . . . . . . . . . . . . . . . . 14 76 10 References . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1 Normative References . . . . . . . . . . . . . . . . . 14 78 10.2 Informative References . . . . . . . . . . . . . . . . 15 79 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . 15 80 12 Authors Addresses . . . . . . . . . . . . . . . . . . . 16 81 Appendix A. "Compilable" ASN.1 Module, 1988 Syntax . . . . 17 83 1. Introduction 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC 2119]. 89 A Certification Authority (CA) issues X.509 public key certificates 90 to bind a public key to a subject. The subject is specified through 91 one or more subject names in the "subject" or "subjectAltName" fields 92 of a certificate. The "subject" field contains a hierarchically 93 structured distinguished name. The "subjectAltName field" may contain 94 an electronic mail address, IP address, or other name forms that 95 correspond to the subject. 97 For each particular CA, a subject name corresponds to a unique 98 person, device, group, or role. The CA will not knowingly issue 99 certificates to multiple entities under the same subject name. That 100 is, for a particular certificate issuer, all currently valid 101 certificates asserting the same subject name(s) are bound to the same 102 entity. 104 Where the subject is a person, the name that is specified in the 105 subject field of the certificate may reflect the name of the 106 individual and affiliated entities (e.g., their corporate 107 affiliation). In reality, however, there are individuals or 108 corporations that have the same or similar names. It may be difficult 109 for a relying party (e.g., a person or application) to associate the 110 certificate with a specific person or organization based solely on 111 the subject name. This ambiguity presents a problem for many 112 applications. 114 In some cases, applications or relying parties need to ensure that 115 the subject of certificates issued by different CAs are in fact the 116 same entity. This requirement may be met by including a "permanent 117 identifier" in all certificates issued to the same subject, which is 118 unique across multiple CAs. By comparing the "permanent identifier", 119 the relying party may identify certificates from different CAs that 120 are bound to the same subject. This solution is defined in [RFC 121 4043]. 123 In many cases a person or corporation's identifier (e.g., such as a 124 Social Security Number) is regarded as a sensitive, private or 125 personal data. Such an identifier cannot simply be included as part 126 of the subject field, since its disclosure may lead to misuse. 127 Therefore, privacy sensitive identifiers of this sort should not be 128 included in certificates in plaintext form. 130 On the other hand, such an identifier is not actually a secret. 131 People choose to disclose these identifiers for certain classes of 132 transactions. For example, a person may disclose his/her Social 133 Security Number to open a bank account or obtain a loan. This is 134 typically corroborated by presenting physical credentials (e.g., a 135 driver license) that confirm the person's name or address. 137 To support such applications in an online environment, relying 138 parties need to determine whether the subject of a particular 139 certificate is also the person corresponding to a particular 140 sensitive identifier. Ideally, applications would leverage the 141 applicants' electronic credential (e.g., the X.509 public key 142 certificate) to corroborate this identifier, but the subject field of 143 a certificate often does not provide sufficient information. 145 To fulfill these demands, this specification defines the Subject 146 Identification Method (SIM) and the Privacy-Enhanced Protected 147 Subject Identifier (PEPSI) format for including a privacy sensitive 148 identifier in a certificate. While other solutions for binding 149 privacy sensitive identifiers to a certificate could be developed, 150 the method specified in this document has especially attractive 151 properties. This specification extends common PKI practices and 152 mechanisms to allow privacy sensitive identifiers to be included in 153 the certificate as well. The SIM mechanism also permits the subject 154 to control exposure of the sensitive identifier; when the subject 155 chooses to expose the sensitive identifier, relying parties can 156 verify the binding. Specifically: 158 (1) A Public Key Infrastructure (PKI) depends upon a trusted third 159 party - the CA - to bind one or more identities to a public key. 160 Traditional PKI implementations bind X.501 distinguished names to the 161 public key, but identity may also be specified in terms of RFC 822 162 addresses or DNS names. The SIM specification allows the same 163 trusted third party - the CA - that binds a name to the public key to 164 include a privacy sensitive identifier in the certificate as well. 165 Since the relying party already trusts the CA to issue certificates, 166 it is a simple extension to cover verification and binding of a 167 sensitive identifier as well. This binding could be established 168 separately, by another trusted third party, but this would complicate 169 the infrastructure. 171 (2) This specification leverages standard PKI extensions to achieve 172 new functional goals with a minimum of new code. This specification 173 encodes the sensitive identifier in the otherName field in the 174 alternative subject name extension. Since otherName field is widely 175 used, this solution leverages a certificate field that is often 176 populated and processed. (For example, smart card logon 177 implementations generally rely upon names encoded in this field.) 178 While implementations of this specification will require some SIM- 179 specific code, an alternative format would increase cost without 180 enhancing security. In addition, that is no impact on 181 implementations that do not process sensitive identifiers. 183 (3) By explicitly binding the public key to the identifier, this 184 specification allows the relying party to confirm the claimant's 185 identifier and confirm that the claimant is the subject of that 186 identifier. That is, proof of possession of the private key confirms 187 that the claimant is the same person whose identity was confirmed by 188 the PKI (CA or RA, depending upon the architecture.) 190 To achieve the same goal in a separate message (e.g., a signed and 191 encrypted S/MIME object), the message would need to be bound to the 192 certificate or an identity in the certificate (e.g., the X.501 193 distinguished name). The former solution is problematic, since 194 certificates expire. The latter solution may cause problems if names 195 are ever reused in the infrastructure. An explicit binding in the 196 certificate is a simpler solution, and more reliable. 198 (4) This specification allows the subject of the privacy sensitive 199 identifier to control the distribution and level of security applied 200 to the identifier. The identifier is only disclosed when the subject 201 chooses to disclose it, even if the certificate is posted in a public 202 directory. By choosing a strong password, the subject can ensure 203 that the identifier is protected against brute force attacks. This 204 specification permits the subject to selectively disclose an 205 identifier where they deem it appropriate, which is consistent with 206 common use of such identifiers. 208 (5) Certificates that contain a sensitive identifier may still be 209 used to support other applications. A party that obtains a 210 certificate containing a sensitive identifier, but to whom the 211 subject does not choose to disclose the identifier, must perform a 212 brute force attack to obtain the identifier. By selecting a strong 213 hash algorithm, this attack becomes computationally infeasible. 214 Moreover, when certificates include privacy sensitive identifiers as 215 described in this specification, each certificate must be attacked 216 separately. Finally, the subject can use this mechanism to prove they 217 possess a certificate containing a particular type of identifier 218 without actually disclosing it to the relying party. 220 This feature MUST be used only in conjunction with protocols that 221 make use of digital signatures generated using the subject's private 222 key. 224 In addition, this document defines an Encrypted PEPSI(EPEPSI) so that 225 sensitive identifier information can be exchanged during certificate 226 issuance processes without disclosing the identifier to an 227 eavesdropper. 229 This document is organized as follows: 231 - Section 3 establishes security and usability requirements; 232 - Section 4 provides an overview of the mechanism; 233 - Section 5 defines syntax and generation rules; and 234 - Section 6 provides example use cases. 236 2. Symbols 238 The following cryptography symbols are defined in this document. 240 H() Cryptographically secure hash algorithm. 241 SHA-1[FIPS 180-1] or a more secure hash function is 242 required. 244 SII Sensitive Identification Information. 245 (e.g., Social Security Number) 247 SIItype Object Identifier that identifies the type of SII. 249 P A user chosen password. 251 R The random number value generated by an RA. 253 PEPSI Privacy-Enhanced Protected Subject Information. 254 Calculated from the input value P, R, SIItype, SII 255 using two iteration of H(). 257 E() The encryption algorithm to encrypt the PEPSI value. 259 EPEPSI Encrypted PEPSI. 261 D() The decryption algorithm to decrypt the EPEPSI. 263 3. Requirements 265 3.1 Security Requirements 267 We make the following assumptions about the context in which SIM & 268 PEPSI are to be employed: 270 - Alice, a certificate holder, with an a sensitive identifier SIIa 271 (such as her Social Security Number) 272 - Bob, a relying party who will require knowledge of Alice's SIIa 273 - Eve, an attacker who acquires Alice's certificate 274 - An RA to whom Alice must divulge her SIIa 275 - A CA who will issue Alice's certificate 277 We wish to design SIM and PEPSI, using a password that Alice chooses, 278 that has the following properties: 280 - Alice can prove her SII, SIIa to Bob. 281 - Eve has a large work factor to determine Alice's SIIa from 282 Alice's certificate, even if Alice chooses a weak password, and a 283 very large work factor if Alice chooses a good password. 284 - Even if Eve can determine SIIa, she has an equally hard problem 285 to find any other SII values from any other PEPSI; that is, 286 there is nothing she can pre-compute that helps her attack 287 PEPSI's in other certificates, and nothing she learns from a 288 successful attack that helps in any other attack. 289 - The CA does not learn Alice's SIIa except the case where the CA 290 needs to validate the SII passed by the RA. 291 - The CA can treat the SIM as an additional name form in the 292 "subjectAltName" extension with no special processing. 293 - Alice cannot find another SII (SIIx), and a password (P), that 294 will allow her to use her certificate to assert a false SII. 296 3.2 Usability Requirements 298 In addition to the security properties stated above, we have the 299 following usability requirements: 301 - When SIM and PEPSI are used, any custom processing occurs at 302 the relying party. Alice can use commercial off the shelf 303 software (e.g., a standard browser) without modification in 304 conjunction with a certificate containing a SIM value. 306 3.3 Solution 308 We define SIM as: R || PEPSI 309 where PEPSI = H(H( P || R || SIItype || SII)) 311 The following steps describe construction and use of SIM: 313 1. Alice picks a password P, and gives P, SIItype, and SII 314 to the RA(via a secure channel). 315 2. The RA validates SIItype and SII, i.e., it determines that 316 the SII value is correctly associated with the subject and 317 the SIItype is correct. 318 3. The RA generates a random value R. 319 4. The RA generates the SIM = (R || PEPSI) where PEPSI = 320 H(H(P || R || SIItype || SII)). 321 5. The RA sends the SIM to Alice by some out-of-band means 322 and also passes it to the CA. 323 6. Alice sends a certRequest to CA. The CA generates 324 Alice's certificate including the SIM as a form of 325 otherName from the GeneralName structure in the 326 SubjectAltName extension. 327 7. Alice sends Bob her Cert, as well as P, SIItype, and SII. 328 The latter values must be communicated via a secure 329 communication channel, to preserve their confidentiality. 330 8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and 331 compare SIM' = R || PEPSI' to the SIM value in Alice's 332 certificate, thereby verifying SII. 334 If Alice's SII value isn't required by Bob (Bob already knows Alice's 335 SII and doesn't require it), then steps 7 and 8 are as follows: 337 7. Alice sends Bob her Cert and P. P must be sent via a secure 338 communication channel, to preserve its confidentiality. 339 8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and 340 compare SIM' = R || PEPSI' to the value in the SIM, thereby 341 verifying SII. 343 If Alice wishes to prove she is the subject of an RA-validated 344 identifier, without disclosing her identifier to Bob, then steps 7 345 and 8 are as follows: 347 7. Alice sends the intermediate value H(P || R || SIItype || 348 SII) and her certificate to Bob. 349 8. Bob can get R from the SIM in the certificate, then compute 350 H(intermediate value) and compare it to the value in SIM, 351 thereby verifying Alice's knowledge of P and SII. 353 Eve has to exhaustively search the H(P || R || SIItype || SII) space 354 to find Alice's SII. This is a fairly hard problem even if Alice uses 355 a poor password, because of the size of R(as specified later), and a 356 really hard problem if Alice uses a fairly good password (see Section 357 8). 359 Even if Eve finds Alice's P and SII, or constructs a massive 360 dictionary of P and SII values, it doesn't help find any other SII 361 values, because a new R is used for each PEPSI and SIM. 363 4. Procedures 365 4.1 SII and SIItype 367 The user presents evidence that a particular SII has been assigned to 368 him/her. The SIItype is an OID that defines the format and scope of 369 the SII value. For example, in Korea, one SIItype is defined as: 371 -- KISA specific arc 372 id-KISA OBJECT IDENTIFIER ::= 373 {iso(1) member-body(2) korea(410) kisa(200004)} 375 -- KISA specific OIDs 376 id-npki OBJECT IDENTIFIER ::= {id-KISA 10} 377 id-attribute OBJECT IDENTIFIER ::= {id-npki 1} 378 id-kisa-identifyData OBJECT IDENTIFIER ::= {id-attribute 1} 379 id-VID OBJECT IDENTIFIER ::= {id-kisa-identifyData 10} 380 id-SII OBJECT IDENTIFIER ::= {id-VID 1} 382 For closed communities, the SIItype value may be assigned by the CA 383 itself, but it is still recommended that the OID be registered. 385 4.2 User Chosen Password 387 The user selects a password as one of the input values for computing 388 the SIM. The strength of the password is critical to protection of 389 the user's SII, in the following sense. If an attacker has a 390 candidate SII value, and wants to determine if the SIM value in a 391 specific subject certificate, P is the only protection for the SIM. 392 The user should be encouraged to select passwords that will be 393 difficult to be guessed, and long enough to protect against brute 394 force attacks. 396 Implementations of this specification MUST permit a user to select 397 passwords of up to 28 characters. RAs SHOULD implement password 398 filter rules to prevent user selection of trivial passwords. See 399 [FIPS 112] and [FIPS 180-1] for security criteria for passwords and 400 an automated password generator algorithm that randomly creates 401 simple pronounceable syllables as passwords. 403 4.3 Random Number Generation 405 The RA generates a random number, R. A new R MUST be generated for 406 each SIM. The length of R MUST be the same as the length of the 407 output of the hash algorithm H. For example, if H is SHA-1, the 408 random number MUST be 160 bits. 410 A Random Number Generator(RNG) that meets the requirements defined in 411 [FIPS 140-2] and its use is strongly recommended. 413 4.4 Generation of SIM 415 The SIM in the subjectAltName extension within a certificate 416 identifies an entity, even if multiple subjectAltNames appear in a 417 certificate. RAs MUST calculate the SIM value with the designated 418 inputs according to the following algorithm: 420 SIM = R || PEPSI 421 where PEPSI = H(H(P || R || SIItype || SII)) 423 The SII is made known to an RA at user enrollment. Both SHA-1 and 424 SHA-256 MUST be supported for generation and verification of PEPSI 425 values. This specification does not preclude use of other one-way 426 hash functions, but SHA-1 or SHA-256 SHOULD be used wherever 427 interoperability is a concern. 429 Note that a secure communication channel MUST be used to pass P and 430 SII passing from the end entity to the RA, to protect them from 431 disclosure or modification. 433 The syntax and the associated OID for SIM are also provided in the 434 ASN.1 modules in Section 5.1. Also, Section 5.2 describes the syntax 435 for PEPSI in the ASN.1 modules. 437 4.5 Encryption of PEPSI 439 It may be required that the CA (not just the RA) verifies SII before 440 issuing a certificate. To meet this requirement, RA SHOULD encrypt 441 the SIItype, SII and SIM and send the result to the CA by a secure 442 channel. The user SHOULD also encrypt the same values and send the 443 result to the CA in his/her certificate request message. Then the CA 444 compares these two results for verifying the user's SII. 446 Where, the results from RA and the user are the EPEPSI. 448 EPEPSI = E(SIItype || SII || SIM) 450 When the EPEPSI is used in a user certificate request, it is in 451 regInfo of [RFC 2511] and [RFC 2314]. 453 Note: Specific encryption/decryption methods are not defined in this 454 document. For transmission of the PEPSI value from a user to a 455 CA, the certificate request protocol employed defines how 456 encryption is performed. For transmission of this data between 457 an RA and a CA, the details of how encryption is performed is 458 a local matter. 460 The syntax and the associated OID for EPEPSI is provided in the ASN.1 461 modules in Section 5.3. 463 4.6 Certification Request 465 As described above, a certificate request message MAY contain the 466 SIM. [RFC 2314] and [RFC 2511] are widely used message syntaxes for 467 certificate requests. 469 Basically, a PKCS#10 message consists of a distinguished name, a 470 public key and an optional set of attributes, collectively signed by 471 the end entity. The SIM alternative name MUST be placed in the 472 subjectAltName extension if this certificate request format is used. 474 If a CA verifies SII before issuing the certificate, the value of SIM 475 in the certification request MUST be conveyed in the EPEPSI form and 476 provided by the subject. 478 4.7 Certification 480 A CA that issues certificates containing the SIM includes the SIM as 481 a form of otherName from the GeneralName structure in 482 "SubjectAltName" extension. 484 In an environment where a CA verifies SII before issuing the 485 certificate, a CA decrypts the EPEPSI values it receives from both 486 the user and the RA, and compares them. It then validates that the 487 SII value is correctly bound to the subject. 489 SIItype, SII, SIM = D(EPEPSI) 491 5. Definition 493 5.1 SIM Syntax 495 This section specifies the syntax for the SIM name form included in 496 subjectAltName extension. The SIM is composed of the three fields, 497 the hash algorithm identifier, the authority-chosen random value, and 498 the value of the PEPSI itself. 500 id-pkix OBJECT IDENTIFIER ::= 501 { iso(1) identified-organization(3) dod(6) internet(1) 502 security(5) mechanisms(5) pkix(7) } 504 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 505 id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 } 507 SIM ::= SEQUENCE { 508 hashAlg AlgorithmIdentifier, 509 authorityRandom OCTET STRING, -- RA chosen random number 510 -- used in computation of 511 -- pEPSI 512 pEPSI OCTET STRING -- hash of HashContent 513 -- with algorithm hashAlg 514 } 516 5.2 PEPSI 518 This section specifies the syntax for PEPSI. The PEPSI is generated 519 by performing the same hash function twice. The PEPSI is generated 520 over the ASN.1 structure HashContent. HashContent has four values: 522 the user selected password, the authority-chosen random number, the 523 identifier type, and the identifier itself. 525 HashContent ::= SEQUENCE { 526 userPassword UTF8String, 527 -- user supplied password 528 authorityRandom OCTET STRING, 529 -- RA chosen random number 530 identifierType OBJECT IDENTIFIER, -- SIItype 531 identifier UTF8String -- SII 532 } 534 Before calculating a PEPSI, conforming implementations MUST process 535 the userPassword with the six step [LDAPBIS STRPREP] string 536 preparation algorithm, with the following changes: 538 * In step 2, Map, the mapping shall include processing of 539 characters commonly mapped to nothing, as specified in Appendix 540 B.1 of [RFC 3454]. 541 * Omit step 6, Insignificant Character Removal. 543 5.3 Encrypted PEPSI 545 This section describes the syntax for Encrypted PEPSI. The Encrypted 546 PEPSI has three fields: identifierType, identifier, and SIM. 548 EncryptedPEPSI ::= SEQUENCE { 549 identifierType OBJECT IDENTIFIER, -- SIItype 550 identifier UTF8String, -- SII 551 sIM SIM -- Value of the SIM 552 } 554 When it is used in a certificate request, the OID in 'regInfo' of 555 [RFC 2511] and [RFC 2314] is as follows: 557 id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 } 559 6. Example Usage of SIM 561 Depending on a different security environments, there are three 562 possible use cases with SIM. 564 1. When a relying party doesn't have any information about 565 the certificate user. 566 2. When a relying party already knows the SII of the 567 certificate user. 568 3. When the certificate user doesn't want to disclose his 569 SII. 571 For the use case 1, the SII and a user-chosen password P (which only 572 the user knows) must be sent to a relying party via a secure 573 communication channel; the certificate including the SIM also must be 574 transmitted. The relying party acquires R from the certificate. The 575 relying party can verify that the SII was validated by the CA (or RA) 576 and is associated with the entity that presented the password and 577 certificate. In this case, the RP learns which SII is bound to the 578 subject as a result of the procedure. 580 In case 2, a certificate user transmits only the password, P, and the 581 certificate. The rest of detailed procedure is the same as case 1, 582 but here the relying party supplies the SII value, based on its 583 external knowledge of that value. The purpose in this case is to 584 enable the RP to verify that the subject is bound to the SII, 585 presumably because the RP identifies the subject based on this SII. 587 In the last case, the certificate user doesn't want to disclose his 588 or her SII because of privacy concerns. Here the only information 589 sent by a certificate subject is the intermediate value of the PEPSI, 590 H(R || P || SIItype || SII). This value MUST be transmitted via a 591 secure channel, to preserve its confidentiality. Upon receiving this 592 value, the relying party applies the hash function to the 593 intermediate PEPSI value sent by the user, and matches it against the 594 SIM value in the user's certificate. The relying party does not learn 595 the user's SII value as a result of this processing, but the relying 596 party can verify the fact that the user knows the right SII and 597 Password. This gives the relying party more confidence that the user 598 is the certificate subject. Note that this form of user identity 599 verification is NOT to be used in lieu of standard certificate 600 validation procedures, but rather, in addition to such procedures. 602 7. Name Constraints 604 The SIM value is stored as an otherName of a subject alternative 605 name, however, there are no constraints that can be placed on this 606 form of the name. 608 8. Security Considerations 610 Confidentiality for a SIM value is created by the iterated hashing of 611 the R, P, and SII values. A SIM value depends on two properties of a 612 hash function; the fact that it cannot be inverted and the fact that 613 collisions (especially with formatted data) are rare. The current 614 attacks by [WANG] are not applicable to SIM values since the end 615 entity supplying the SII and SIItype values does not supply all of 616 the data being hashed, i.e. , the RA provides the R value. 618 In addition, a fairly good password is needed to protect against 619 guessing attacks on SIMs. Due to the short length of many SII's, it 620 is possible that an attacker may be able to guess it with partial 621 information about gender, age, and date of birth. SIIType values are 622 very limited. Therefore, it is important for users to select a fairly 623 good password to prevent an attacker from determining whether a 624 guessed SII is accurate. 626 This protocol assumes that Bob is a trustworthy relying party who 627 will not reuse the Alice's information. Otherwise, Bob could 628 "impersonate" Alice if only knowledge of P and SII were used to 629 verify a subject's claimed identity. Thus, this protocol MUST be used 630 only with the protocols that make use of digital signatures generated 631 using the subject's private key. 633 Digital signatures are used by a message sender to demonstrate 634 knowledge of the private key corresponding to the public key in a 635 certificate, and thus to authenticate and bind his/her identity to a 636 signed message. However, managing a private key is vulnerable under 637 certain circumstances. It is not fully guaranteed that the claimed 638 private key is bound to the subject of a certificate. So, the SIM can 639 enhance verification of user identity. 641 Whenever a certificate needs to be updated, a new R SHOULD be 642 generated and the SIM SHOULD be recomputed. Repeating the value of 643 the SIM from a previous certificate permits an attacker to identify 644 certificates associated with the same individual, which may be 645 undesirable for personal privacy purposes. 647 9. IANA Considerations 649 In the future, IANA may be asked to establish a registry of object 650 identifiers to promote interoperability in the specification of SII 651 types. 653 10. References 655 10.1 Normative References 657 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, March 1997. 660 [RFC 2511] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet 661 X.509 Certificate Request Message Format", RFC 2511, 662 March 1999. 664 [RFC 2314] Kaliski, B., "PKCS #10: Certification Request Syntax 665 Version 1.5", RFC 2314, March 1998. 667 [RFC 3454] P. Hoffman, M. Blanchet, "Preparation of 668 Internationalized Strings ("stringprep")", RFC 3454, 669 December 2002. 671 [RFC 4043] D. Pinkas, T. Gindin, "Internet X.509 Public Key 672 Infrastructure Permanent Identifier", RFC4043, 673 May 2005. 675 10.2 Informative References 677 [LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String 678 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work 679 in progress. 681 [FIPS 112] Fedreal Information Processing Standards Publication 682 (FIPS PUB) 112, "Password Usage", 30 May 1985. 684 [FIPS 180-1] Federal Information Processing Standards Publication 685 (FIPS PUB) 180-1, "Secure Hash Standard", 17 April 1995. 687 [FIPS 140-2] Federal Information Processing Standards Publication 688 (FIPS PUB) 140-2, "Security Requirements for 689 Cryptographic Modules", 25 May 2001. 691 [WANG] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu, "Finding 692 Collisions in the Full SHA-1", Crypto'05. 693 696 11. Acknowledgments 698 Jim Schaad(Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon, Baehyo 699 Park(KISA), Bill Burr, Morrie Dworkin(NIST), and ISTF(Internet 700 Security Technical Forum, http://www.istf.org) have significantly 701 contributed to work on the SIM and PEPSI concept and identified a 702 potential security attack. Also their comments on the set of 703 desirable properties for the PEPSI and enhancements to the PEPSI were 704 most illumination. Also, thanks for Russell Housley, Stephen Kent, 705 Denis Pinkas for their contributions to this document. 707 12. Authors Addresses 709 Jongwook Park 710 Korea Information Security Agency 711 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 712 REPUBLIC OF KOREA 713 Phone: 2-405-5432 714 Email: khopri@kisa.or.kr 716 Jaeil Lee 717 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 718 REPUBLIC OF KOREA 719 Korea Information Security Agency 720 Phone: 2-405-5300 721 Email: jilee@kisa.or.kr 723 Hongsub Lee 724 Korea Information Security Agency 725 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 726 REPUBLIC OF KOREA 727 Phone: 2-405-5100 728 EMail: hslee@kisa.or.kr 730 Sungjun Park 731 BCQRE Co.,Ltd 732 Yuil Bldg. Dogok-dong 411-14, Kangnam-ku, Seoul, 135-270 733 REPUBLIC OF KOREA 734 Email: sjpark@bcqre.com 736 Tim Polk 737 National Institute of Standards and Technology 738 100 Bureau Drive, MS 8930 739 Gaithersburg, MD 20899 740 Email: tim.polk@nist.gov 742 Appendix A. "Compilable" ASN.1 Module, 1988 Syntax 744 PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1) 745 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim2005(38) } 747 DEFINITIONS EXPLICIT TAGS ::= 749 BEGIN 751 -- EXPORTS ALL 753 IMPORTS 755 AlgorithmIdentifier, AttributeTypeAndValue FROM PKIX1Explicit88 756 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 757 mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} 759 -- SIM 761 -- SIM certificate OID 763 id-pkix OBJECT IDENTIFIER ::= 764 { iso(1) identified-organization(3) dod(6) internet(1) 765 security(5) mechanisms(5) pkix(7) } 767 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 768 id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 } 770 -- Certificate Syntax 772 SIM ::= SEQUENCE { 773 hashAlg AlgorithmIdentifier, 774 authorityRandom OCTET STRING, -- RA chosen radom number 775 -- used in computation of 776 -- pEPSI 777 pEPSI OCTET STRING -- hash of HashContent 778 -- with algorithm hashAlg 779 } 781 -- PEPSI 783 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 784 -- The content of this type conforms to RFC 2279 786 HashContent ::= SEQUENCE { 787 userPassword UTF8String, 788 -- user supplied password 789 authorityRandom OCTET STRING, 790 -- RA chosen random number 791 identifierType OBJECT IDENTIFIER, -- SIItype 792 identifier UTF8String -- SII 793 } 795 -- Encrypted PEPSI 797 -- OID for encapsulated content type 799 id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 } 801 EncryptedPEPSI ::= SEQUENCE { 802 identifierType OBJECT IDENTIFIER, -- SIItype 803 identifier UTF8String, -- SII 804 sIM SIM -- Value of the SIM 805 } 807 END 809 Intellectual Property Statement 811 The IETF takes no position regarding the validity or scope of any 812 Intellectual Property Rights or other rights that might be claimed to 813 pertain to the implementation or use of the technology described in 814 this document or the extent to which any license under such rights 815 might or might not be available; nor does it represent that it has 816 made any independent effort to identify any such rights. Information 817 on the procedures with respect to rights in RFC documents can be 818 found in BCP 78 and BCP 79. 820 Copies of IPR disclosures made to the IETF Secretariat and any 821 assurances of licenses to be made available, or the result of an 822 attempt made to obtain a general license or permission for the use of 823 such proprietary rights by implementers or users of this 824 specification can be obtained from the IETF on-line IPR repository at 825 http://www.ietf.org/ipr. 827 The IETF invites any interested party to bring to its attention any 828 copyrights, patents or patent applications, or other proprietary 829 rights that may cover technology that may be required to implement 830 this standard. Please address the information to the IETF at 831 ietf-ipr@ietf.org. 833 Disclaimer of Validity 835 This document and the information contained herein are provided on an 836 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 837 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 838 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 839 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 840 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 841 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 843 Copyright Statement 845 Copyright (C) The Internet Society (2006). This document is subject 846 to the rights, licenses and restrictions contained in BCP 78, and 847 except as set forth therein, the authors retain all their rights. 849 Acknowledgment 851 Funding for the RFC Editor function is currently provided by the 852 Internet Society.