Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
draft-ietf-pkix-sim-08

PKIX Working Group                                     J.W. Park (KISA)
Internet Draft                                          J.I. Lee (KISA)
Document: draft-ietf-pkix-sim-08.txt                    H.S. Lee (KISA)
Expires : August, 2006                                S.J. Park (BCQRE)
Target category: Standard Track                        Polk, Tim (NIST)
                                                        February, 2006

                Internet X.509 Public Key Infrastructure
                  Subject Identification Method (SIM)
                      <draft-ietf-pkix-sim-08.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 20, 2006.

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.

Park, et. al.             Expires December 2006                 [Page 1]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
   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 . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.3  Encrypted PEPSI . . . . . . . . . . . . . . . . . . . .  12
   6  Example Usage of SIM  . . . . . . . . . . . . . . . . . .  12
   7  Name Constraints  . . . . . . . . . . . . . . . . . . . .  13
   8  Security Considerations . . . . . . . . . . . . . . . . .  13
   9  IANA Considerations . . . . . . . . . . . . . . . . . . .  14
   10  References . . . . . . . . . . . . . . . . . . . . . . .  14
   10.1 Normative References  . . . . . . . . . . . . . . . . .  14
   10.2 Informative References  . . . . . . . . . . . . . . . .  15
   11  Acknowledgements . . . . . . . . . . . . . . . . . . . .  15
   12  Authors Addresses  . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  "Compilable" ASN.1 Module, 1988 Syntax  . . . .  17

1. Introduction

   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 [RFC 2119].

   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

Park, et. al.             Expires December 2006                 [Page 2]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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.

   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 or corporation's identifier (e.g., such as a
   Social Security Number) is regarded as a 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 his/her Social
   Security Number to open a bank account or obtain a loan. This is
   typically corroborated by presenting physical credentials (e.g., a
   driver 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

Park, et. al.             Expires December 2006                 [Page 3]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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 Identifier (PEPSI) format for including a privacy sensitive
   identifier in a certificate.  While 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
   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 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.)
   While implementations of this specification will require some SIM-
   specific code, an alternative format would increase cost without
   enhancing security.  In addition, that is 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

Park, et. al.             Expires December 2006                 [Page 4]
INTERNET-DRAFT        Subject Identification Method            July 2006

   encrypted 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.

   (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 the subject 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 subject 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.

Park, et. al.             Expires December 2006                 [Page 5]
INTERNET-DRAFT        Subject Identification Method            July 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 an 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 &
   PEPSI are to be employed:

     - Alice, a certificate holder, with an 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.
     - Eve has a large work factor to determine Alice's SIIa from
       Alice's certificate, even if Alice chooses a weak password, and a

Park, et. al.             Expires December 2006                 [Page 6]
INTERNET-DRAFT        Subject Identification Method            July 2006

       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
       PEPSI's 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 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.
   8.      Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and

Park, et. al.             Expires December 2006                 [Page 7]
INTERNET-DRAFT        Subject Identification Method            July 2006

           compare SIM' = R || PEPSI' to the SIM value in Alice's
           certificate, thereby verifying SII.

   If Alice's SII value isn't required by Bob (Bob already knows Alice's
   SII and doesn't 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 doesn't 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 OID that defines the format and scope of
   the SII value.  For example, in Korea, one SIItype is defined as:

   -- 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}

Park, et. al.             Expires December 2006                 [Page 8]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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 if 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))

   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

Park, et. al.             Expires December 2006                 [Page 9]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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/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 [RFC 2511] and [RFC 2314].

   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. [RFC 2314] and [RFC 2511] 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
   the end entity. The SIM alternative name MUST be placed in the
   subjectAltName extension if this certificate request format is used.

Park, et. al.             Expires December 2006                [Page 10]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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
   "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
   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
        }

5.2 PEPSI

   This section specifies the syntax for 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:

Park, et. al.             Expires December 2006                [Page 11]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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 [RFC 3454].
      * Omit step 6, Insignificant Character Removal.

5.3 Encrypted PEPSI

   This section describes the syntax for 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
   [RFC 2511] and [RFC 2314] is as follows:

   id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }

6. Example Usage of SIM

   Depending on a different security environments, there are three
   possible use cases with SIM.

        1.     When a relying party doesn't 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 doesn't want to disclose his

Park, et. al.             Expires December 2006                [Page 12]
INTERNET-DRAFT        Subject Identification Method            July 2006

               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 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 doesn't 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.

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

Park, et. al.             Expires December 2006                [Page 13]
INTERNET-DRAFT        Subject Identification Method            July 2006

   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 SII's, 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/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.

9. 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.

10. References

10.1 Normative References

   [RFC 2119]   S. Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 2511]   Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet

Park, et. al.             Expires December 2006                [Page 14]
INTERNET-DRAFT        Subject Identification Method            July 2006

                X.509 Certificate Request Message Format", RFC 2511,
                March 1999.

   [RFC 2314]   Kaliski, B., "PKCS #10: Certification Request Syntax
                Version 1.5", RFC 2314, March 1998.

   [RFC 3454]   P. Hoffman, M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.

   [RFC 4043]   D. Pinkas, T. Gindin, "Internet X.509 Public Key
                Infrastructure Permanent Identifier", RFC4043,
                May 2005.

10.2 Informative References

   [LDAPBIS STRPREP]    Zeilenga, K., "LDAP: Internationalized String
                Preparation", draft-ietf-ldapbis-strprep-xx.txt, a 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>

11. Acknowledgments

   Jim Schaad(Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon, Baehyo
   Park(KISA), Bill Burr, Morrie Dworkin(NIST), and ISTF(Internet
   Security Technical Forum, http://www.istf.org) 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 for Russell Housley, Stephen Kent,
   Denis Pinkas for their contributions to this document.

Park, et. al.             Expires December 2006                [Page 15]
INTERNET-DRAFT        Subject Identification Method            July 2006

12. 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

   Sungjun 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.             Expires December 2006                [Page 16]
INTERNET-DRAFT        Subject Identification Method            July 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 radom 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.             Expires December 2006                [Page 17]
INTERNET-DRAFT        Subject Identification Method            July 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.             Expires December 2006                [Page 18]
INTERNET-DRAFT        Subject Identification Method            July 2006

Intellectual Property Statement

   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.

Disclaimer of Validity

   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.

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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Park, et. al.             Expires December 2006                [Page 19]