draft-ietf-pkix-sim-00.txt

PKIX的RFC英文文档

PKIX Working Group                                 Jong-Wook, Park(KISA)
Internet Draft                                        Jae-Ho, Yoon(KISA)
Expires : April, 2003                                Seungjoo, Kim(KISA)                      
                                                   Sangjoon, Park(BCQRE)                          
                                                       Jae-Il, Lee(KISA)
                                                     Hong-Sub, Lee(ISTF)                    
                                                           October, 2002


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


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC 2026].

   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.

   Copyright (C) The Internet Society (2002). All Rights Reserved.

   Please send comments on this document to the [e-mail]
   mailing list.

Abstract

   This document provides the new straightforward approach to generate 
   and verify unique information for identifying of the certificate 
   subject. 
   
   A Virtual ID(VID) may be put into the "othername" field of the X.509 
   subjectAltName certificate extension to make provisions for 
   identifying the subject. 
 






Park, et. al.                                                   [Page 1]

INTERNET-DRAFT                                                  Oct 2002

Table of Contents   

   Status of this Memo..............................................1
   Abstract.........................................................1
   Table of Contents................................................2   
   1. Introduction..................................................2 
   2. Procedures....................................................3
      2.1 Symbols...................................................3     
      2.2 Initialization............................................4   
      2.3 Random Number Generation..................................4   
      2.4 Generating VID............................................5
      2.5 Encryption of VID.........................................5 
      2.6 certificate Request.......................................6      
      2.7 Certification.............................................6   
   3. Definition....................................................7
      3.1 IdentityData..............................................7      
      3.2 Virtual ID (VID)..........................................7  
      3.3 Encrypted Virtual ID (EVID)...............................8
   4. Example Usage of VID..........................................9           
   5. References....................................................9 
   6. Security Considerations......................................10 
   7. Full Copyright Statements....................................10
   8. Author's Addresses...........................................11  
   Appendix A. ASN.1 Structures and OIDs...........................11

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 [RFC2119].                        
   
   In general, "subject" and/or "subjectAltName" field of certificate is 
   unique for each subject entity. However, it seems to be better to 
   consider various situations. For example, suppose that one person 
   has multiple certificates issued by several CAs and each certificate 
   has different subject name. This situation clearly makes   
   PKI-application size bigger because there is no same type of 
   identifying entity and it needs a smarter decision support process. 
   
   So, the subject name carried in the subject field and/or 
   subjectAltName extension may not guarantee that the certificate 
   refers to the same entity if the entity data changes.
   
   Therefore, there has been constant demand to define a technical 
   specification to solve the question of identifying the subject by 
   including a person/corporation's identifier such as codes, numbers
   and strings in a certificate. 

   Since most people have their own ID number granted by their own
   country, it is adequate to use it in the certificate to identify the 
   users. 
   


Park, et. al.                                                   [Page 2]

INTERNET-DRAFT                                                  Oct 2002

   However, in some countries, a person/corporation's identifier is 
   regarded as a "private or personal data" by law since the identifier 
   contains information such date of birth and gender. Therefore, 
   its misuse and disclosure in public such as uploading the identifier 
   in web pages could be a violation of law. Not only that but also some 
   people may not want to expose their personal data although the 
   identifier is considered as "public data" in his country.

   To fulfill this demand, this document specifies secure procedures of 
   generating and verifying identification without leaking any sensitive
   information. The certificate user's unique identifier will be stored 
   in the certificate in the form of a hash value, so-called Virtual ID, 
   which will also be put into the "othername" field of the 
   subjectAltName extension. Then, Virtual ID can be extracted to 
   identify the user without the third party's help.

   To request a certificate containing Virtual ID, the user makes a 
   digital signature on a private key, and sends it to a CA along with 
   the user's public key, DN and Virtual ID. The CA validates the 
   digital signature and verify the Virtual ID, then puts the VID in the 
   certificate.
        
2. Procedures

2.1 Symbols

The below cryptography symbols will be used in this document 
in the following ways.
   
   Symbol       Meaning
   ------       -------
   h()          One-way hash function for generating a Virtual ID.  
                MD2 and MD5 is NOT RECOMMENDED but SHA-1 is RECOMMENDED.
   R            A 160-bit random string, which is necessary for 
                producing Virtual ID. 
   ID           A person or an organization identifier, which could be 
                composed of numbers or alphanumeric to associate 
                each citizen or organization in worldwide and is 
                essential for computing a Virtual ID.
   E()          Encryption function. RSA or ECDSA(if possible) is 
                RECOMMENDED to encrypt the Virtual ID with a CA's 
                certificate because it is important.
   VID          A Virtual ID. It is calculated by applying the hash 
                function twice to the concatenated value of ID and R 
                successively.
   EVID         Encrypted Virtual ID, The subject public Key algorithm
                in CA's certificate is used for encrypting Virtual ID.
                If a certificate with VID is requested, EVID will be 
                carried within the certificate request defined in 
                [PKCS#10] or [RFC2511]. 




Park, et. al.                                                   [Page 3]

INTERNET-DRAFT                                                  Oct 2002

2.2 Initialization

   Every certificate request that a user sends to CA SHOULD be encrypted 
   with the CA's certificate to ensure confidentiality. To this end, a
   user is REQUIRED to obtain a CA's certificate in advance. However, 
   how to acquire a CA's certificate is not covered in this 
   specification. 
   
   After generating a public key pair, it will be stored in the form of
   a certificate, whereas the private key is encrypted and safely stored
   in a separate storage device (e.g, smart cards, USB tokens etc).

2.3 Random Number Generation  
    
   A 160-bit random string, 'R' SHOULD be globally unique and only 
   associated to each person like an ID. Its usage and objective are to 
   extend the confidentiality of VID. 
   
   A random string will be used with ID and it is sent to CA along with
   the VID. When receiving a certificate request contains the user's 
   VID, CA will validate the VID by regenerating another VID with R. It 
   is important to manage the random string securely because the exposed 
   VID SHOULD NOT be used for identifying the subject.   
   
   In order to protect the random string from undesired exposure, 
   [PKCS#8] or [PKCS#11] MAY be used for holding R in a secure hardware 
   module. 
   
   If PKCS#8 is used as a syntax for encrypted private-key information 
   including a private key and a set of attributes. A new attribute of a 
   simple way to hold 'R' MAY define as follows :
   
        id-on-identityData-randomNum OBJECT IDENTIFIER ::= 
                                        {id-on-identityData 1} 
         
   The random string value 'ASN.1' encoded as a BIT STRING and put into
   the attribute of encrypted private-key information with its object 
   identifier defined as just above. 

   Next, if the PKCS#11 compatible cryptographic token is used as a
   storage device, the PKCS#11 DATA OBJECT including the following 
   set of attributes MUST be defined in order to manage a random string 
   R. 
   
      - CKA_CLASS attribute indicates the object type, therefore it 
        SHOULD be specified as CKO_DATA value.
      - CKA_TOKEN attribute SHOULD be set to TRUE since the random 
        string is a token object.






Park, et. al.                                                   [Page 4]

INTERNET-DRAFT                                                  Oct 2002
   
      - CKA_PRIVATE attribute SHOULD be set to TRUE because a user may 
        not access the random string until the user has been 
        authenticated to the token.
      - A random string SHOULD NOT be modified once it's created,
        CKA_MODIFIABLE attribute is set to FALSE.
      - CKA_LABEL attribute MAY be modified after the random string 
        data object is created and this information could be accessed at
        any time.
      - CKA_APPLICATION attribute SHOULD have a name of the application 
        that manages the random string object.
      - CKA_VALUE attribute SHOULD have a value of the random string.

   Note that only CKA_APPLICATION and CKA_VALUE are additional 
   attributes supported by the data object, but others are common 
   attributes.

2.4 Generating VID
  
   The VID in the subjectAltName extension of the certificate identifies 
   a user who has multiple names in his certificates. The unique value
   of the VID SHOULD be derived from hashing the ID and R twice with
   the designated hash function, yielding 160-bit hash of the inputs.
      
        VID = h(h(ID, R))
        
   Among hash functions, SHA-1 is RECOMMENDED. The reason for applying 
   the hash function twice is to increase the security level of VID 
   because if each person's ID is considered as "public data", the level 
   of security of the VID entirely depends on the random string. In the 
   worst case, an attacker may be able to acquire VID through the 
   meet-in-the-middle-attack.   
   
   Under the special circumstances, the hash of a private key MAY be an 
   alternative to the random string. Even though any hint or partial 
   information of the private key would bring into undesired situation, 
   the hash of the private key is still the secure cryptographically. 
   
   The syntax and associated object identifiers (OIDs) for VID are 
   provided in the ASN.1 modules in Appendices A.

2.5 Encryption of VID

   Since a CA can't decide if the VID sent by a user is valid with only 
   the VID itself, the CA SHOULD obtain ID and R in advance. During the 
   user registration, which requires to provide user name, e-mail 
   address and other attributes, acquiring ID is REQUIRED. But a CA can 
   hardly get R beforehand.  







Park, et. al.                                                   [Page 5]

INTERNET-DRAFT                                                  Oct 2002
        
   Because R is very important component for identifying the user, its 
   confidentiality MUST be kept in securely all the time. For this 
   reason, both VID and R SHOULD be encrypted together and then sent to 
   CA in form of a certificate request. 

   An EVID is defined as follows :
   
        EVID = E(VID, R)
        
   The algorithm and the public key used here for encryption are derived
   from the CA's certificate.
   
2.6 certificate request

   The certificate request message SHOULD contain the EVID. [PKCS#10]and 
   [RFC2511] are widely used to describe message syntax for certificate
   requests. EVID will be put into optional attributes for conveying 
   attributes to the CA with additional information.
   
   The new attribute to describe the EVID SHOULD be defined as follows :
   
        id-on-identityData-evid  OBJECT IDENTIFIER ::= 
                                        { id-on-identityData 3 } 
   
   Basically, PKCS#10 is composed of the user's name and public key.  
   To satisfy this specification, it SHOULD be contain EVID attributes 
   for additional authentication of the requester's identity to verify 
   the request, which has never been altered.
   
   In case of using the RFC2511(CRMF) for certificate request message, 
   an EVID SHOULD be put into the "regToken" control defined in section 
   6.1 of [RFC2511]. 
   
2.7 Certification 

   After the CA receives the certificate request from the user, the CA 
   MUST check the accuracy of the VID. The EVID is extracted from the 
   certificate request and decrypted with the CA's private key. After 
   these process, the VID and the R can be acquired. Then CA SHOULD 
   compute another VID and check if it is identical to the original VID.
   
        VID' = h(h(ID, R)
        
   If the CA assures both VID' and VID are the same, VID is now put into 
   the subjectAltName extension filed of the certificate being issued.  









Park, et. al.                                                   [Page 6]