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) 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 ietf-pkix@imc.org 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] INTERNET-DRAFT Oct 2002 3. Definition 3.1 identityData This section gives the syntax for identityData including the real name of a subject and a set of attributes. The 'othername' component of the subjectAltName extension field will contain this object. id-on-identityData OBJECT IDENTIFIER ::= { id-on ? } IdentityData ::= SEQUENCE { realName UTF8String, userInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL } - realName field is the real name of the subject and SHOULD be encoded in UTF8String. - Additional information for subject identification MAY be stored in userInfo field. If any, the VID SHOULD be included right here. 3.2 Virtual ID This section gives the syntax for Virtual ID. The Virtual ID is composed of two parts, the hash algorithm identifier and hashed value fields. id-on-identityData-vid OBJECT IDENTIFIER ::= {id-on-identityData 2} VirtualID ::= SEQUENCE { hashAlg HashAlgorithm, vid [0] OCTET STRING } HashAlgorithm ::= AlgorithmIdentifier HashContent ::= SEQUENCE { identifier PrintableString, randomNum BIT STRING } - hashAlg field represents the hash algorithm and its parameter is used for calculating the VID. - vid field contains a computed value in accordance with the method described in section 2.4, and is computed by hashing DER-encoded HashContent value once more. - identifier field contains the subject's identifier. It SHOULD be expressed as PrintableString. - randomNum field contains a 160-bit random string. Park, et. al. [Page 7] INTERNET-DRAFT Oct 2002 3.3 Encrypted Virtual ID This section gives the syntax for Encrypted Virtual ID. The Encrypted Virtual ID is divided into five fields. id-on-identityData-evid OBJECT IDENTIFIER ::= {id-on-identityData 2} EncryptedVID ::= SEQUENCE { version [0] INTEGER DEFAULT v1(0), vidHashAlg [1] VIDHashAlgorithm OPTIONAL, vidEncAlg [2] VIDEncryptionAlgorithm, certID [3] IssuerAndSerialNumber, encryptedVID [4] OCTET STRING } VIDHashAlgorithm ::= AlgorithmIdentifier VIDEncryptionAlgorithm ::= AlgorithmIdentifier IssuerAndSerialNumber ::= SEQUENCE { issuer Name, serialNumber CertificateSerialNumber } EncryptContent ::= SEQUENCE { vid VID, randomNum BIT STRING } - version field describes version information of the EVID. If this spec is applied, v1(0) value will be used. - vidHashAlg field is the hash algorithm and parameters are used to generate the VID. - vidEncAlg field is the asymmetric encryption algorithm and parameters are used to compute the VID. - certID field identifies CA's certificate which is used to encrypt the VID. It consists of the issuer and the serial number of CA's certificate. - encryptedVID field is the output of encrypting DER-encoded EncryptContent value with the CA's public key. Park, et. al. [Page 8] INTERNET-DRAFT Oct 2002 4. Example Usage of VID The VID in a certificate MAY be used to go through different verification procedures depending on the various situations. If a relying party doesn't have any information of a user's identifier, the user SHOULD send his/her ID and R simultaneously. Step ---- 1. The user sends the ID and R to a relying party securely. 2. The certificate including the VID transferred in step 1 is sent to the relying party also. 3. The Relying party extracts the VID from the received certificate. 4. Both the ID and the R transferred in step 1 are used to compute VID'. 5. The VID and VID' calculated in step 3 and 4 separately and compared with each other to see if they are identical. The order in which data are sent in step 1 and 2 doesn't matter, but the ID and R MUST be transferred securely so as not to be leaked to a third party. In case of the relying party already knows the user ID, then user only have to submit R. Upon receiving the R and the certificate, the relying party can derive the VID' by putting the user's ID already obtained in advance and the R. At last relying party can tell whether two VIDs are equal or not. In case of the user wants to protect his ID from the relying party, the user sends only the output of a hashed value of the ID and the R along with his certificate to the relying party. With h(ID,R) and the certificate, the relying party can draw the VID' by applying one more hash function. Like the other cases, the replying party is able to verify if a user's identity is correct. 5. References [X.509] ITU-T Recommendation X.509: The Directory - Public-Key and Attribute Certificate Frameworks. 2000. [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 2510, March 1999. [RFC2511] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet X.509 Certificate Request Message Format", RFC 2511, March 1999. Park, et. al. [Page 9] INTERNET-DRAFT Oct 2002 [RFC3280] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [PKCS#5] RSA Laboratories, "PKCS #5: Password-Based Cryptography Standard Version 2.0", March, 1999. [PKCS#8] RSA Laboratories, "PKCS #8: Private Key Information Syntax Standard Version 1.2", November 1993. [PKCS#10] RSA Laboratories, "PKCS #10: Certification Request Syntax Version 1.7", November 2001. [PKCS#11] RSA Laboratories, "PKCS #11: Cryptographic Token Interface Standard Version 2.10", November, 1999. 6. Security Considerations The security of a VID delivery is entirely upon the security level of procedures for communicating with CAs. Therefore, EVID, the output of encryption of a VID, SHOULD be included in [PKCS#10] or [RFC2511]. 7. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Park, et. al. [Page 10] INTERNET-DRAFT Oct 2002 8. Authors' Addresses Jong-Wook, Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA EMail: khopri@kisa.or.kr Jae-Ho, Yoon Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA EMail: jhyoon@kisa.or.kr Seungjoo, Kim Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA EMail: skim@kisa.or.kr Sangjoon, Park BCQRE 467-12, Dogok-Dong, Kangnam-Gu, Seoul, 135-270 REPUBLIC OF KOREA EMail: sangjoon@bcqre.com Jae-Il, Lee Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA EMail: jllee@kisa.or.kr Hong-Sub, Lee Internet Security Technology Forum 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA EMail: hslee@kisa.or.kr Appendix A. ASN.1 Structures and OIDs IMPORTS AlgorithmIdentifier, Name, CertificateSerialNumber, Attribute, AttributeTypeAndValue FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}; -- Arc for other name forms id-on OBJECT IDENTIFIER ::= { id-pkix 8 } Park, et. al. [Page 11] INTERNET-DRAFT Oct 2002 -- Arcs for randomNum, VID and EVID. id-on-identityData OBJECT IDENTIFIER ::= { id-on ? } id-on-identityData-randomNum OBJECT IDENTIFIER ::= { id-on-identityData 1 } id-on-identityData-vid OBJECT IDENTIFIER ::= { id-on-identityData 2 } id-on-identityData-evid OBJECT IDENTIFIER ::= { id-on-identityData 3 } -- IdentityData IdentityData ::= SEQUENCE { realName UTF8String, userInfo SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue OPTIONAL } -- Virtual ID virtualID ::= SEQUENCE { hashAlg HashAlgorithm, virtualID [0] OCTET STRING } HashAlgorithm ::= AlgorithmIdentifier HashContent ::= SEQUENCE { identifier PrintableString, randomNum BIT STRING } -- Encrypted VID EncryptedVID ::= SEQUENCE { version [0] INTEGER DEFAULT 0, vidHashAlg [1] VIDHashAlgorithm OPTIONAL, vidEncAlg [2] VIDEncryptionAlgorithm, certID [3] IssuerAndSerialNumber, encryptedVID [4] OCTET STRING } VIDHashAlgorithm ::= AlgorithmIdentifier VIDEncryptionAlgorithm ::= AlgorithmIdentifier IssuerAndSerialNumber ::= SEQUENCE { issuer Name, serialNumber CertificateSerialNumber } EncryptContent ::= SEQUENCE { vid VID, randomNum BIT STRING } END Park, et. al. [Page 12]