the 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 the 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: 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 [RFC3454].
* Omit step 6, Insignificant Character Removal.
5.3. Encrypted PEPSI
This section describes the syntax for the 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
[RFC4211] and [RFC2986] is as follows:
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
6. Example Usage of SIM
Depending on different security environments, there are three
possible use cases with SIM.
1. When a relying party does not 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 does not want to disclose his 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 the 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 does not 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
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 SIIs, 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 or 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. Acknowledgements
Jim Schaad (Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon,
Baehyo Park (KISA), Bill Burr, Morrie Dworkin (NIST), and the
Internet Security Technology Forum (ISTF) 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 to Russell Housley, Stephen Kent,
and Denis Pinkas for their contributions to this document.
10. 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.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10:
Certification Request Syntax Specification Version
1.7", RFC 2986, November 2000.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC
3454, December 2002.
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public
Key Infrastructure Permanent Identifier", RFC 4043,
May 2005.
[RFC4211] Schaad, J., "Internet X.509 Public Key
Infrastructure Certificate Request Message Format
(CRMF)", RFC 4211, September 2005.
11.2. Informative References
[LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String
Preparation", 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>
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
Sangjoon 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
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 random 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,
-- 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
Full 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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).