Request for Comments: 4683 J. Lee
Category: Standards Track H. Lee
KISA
S. Park
BCQRE
T. Polk
NIST
October 2006
Internet X.509 Public Key Infrastructure
Subject Identification Method (SIM)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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.
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
1.1. Key Words ..................................................5
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 .....................................................12
5.3. Encrypted PEPSI ...........................................12
6. Example Usage of SIM ...........................................13
7. Name Constraints ...............................................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................15
10. IANA Considerations ...........................................15
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax ...............18
1. Introduction
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 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’s or corporation’s identifier (e.g., a Social
Security Number) is regarded as 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 a Social Security
Number to open a bank account or obtain a loan. This is typically
corroborated by presenting physical credentials (e.g., a driver’s
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
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 Information (PEPSI) format for including a privacy sensitive
identifier in a certificate. Although 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 (RP) 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.)
Whereas implementations of this specification will require some SIM-
specific code, an alternative format would increase cost without
enhancing security. In addition, that has 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
encrypted Secure MIME (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 subjects 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 subjects 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.
1.1. Key Words
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].
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 a Registration
Authority (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 and
PEPSI are to be employed:
- Alice, a certificate holder, with 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
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 PEPSIs 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 in 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
compare SIM’ = R || PEPSI’ to the SIM value in Alice’s
certificate, thereby verifying SII.
If Alice’s SII value is not required by Bob (Bob already knows
Alice’s SII and does not 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 does not 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 Object Identifier (OID) that defines the
format and scope of the SII value. For example, in Korea, one
SIItype is defined as follows:
-- 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}
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 whether 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
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 or 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 [RFC4211] and [RFC2986].
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. [RFC2986] and [RFC4211] 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.
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 the
"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