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