PKIX Working Group J. H. Yoon (KISA)
Internet Draft C. J. Chung
expires November, 2002 Y. Lee
J. I. Lee
H. S. Lee
May, 2002
Wireless Internet X.509 Public Key Infrastructure
Certificate Request Message Format and Protocol (WCRMFP)
<draft-yoon-pkix-wireless-internet-01.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 (2001). All Rights Reserved.
Abstract
This document describes the Wireless Certificate Request
Message Format and Protocol (WCRMFP) in wireless internet
environment. This format and protocol are used to convey a request
for a certificate to a Certification Authority (CA) (possibly via a
Registration Authority (RA)) for the purposes of X.509 certificate
production. The request will typically include a public key and
associated registration information.
Yoon, et. al. Expires Nov. 2002 [Page 1]
Internet Draft May 2002
1. Introduction
Different from wired system terminal, wireless one has many
limitations in CPU, memory, battery life, and a user interface.
Moreover the wireless network has very low bandwidth, latency, and
data loss. For that reasons, using CRMF(RFC2511) is a burden to
wireless and environment. So new message format in certificate
request is needed.
This document describes optimised certificate request format fitted
for wireless and mobile devices protocol using SignText function
[WAPscriptCrypto] defined in WAP specification.
1.1 Protocol requirements
Construction of a certificate request needs the following requirements:
a) Certificate Request Message Format is constructed at mobile
device. This value should include the public key, end-entity's
(EE's) ID and password. Other requested certificate fields, and
additional control information related to the registration process
are made in out-of-band.
b) A proof of possession (of the private key corresponding to the
public key for which a certificate is being requested) value is
included in certificate request massage.
c) The CR(Certificate Request) message is securely
communicated to a CA. However the specific methods of secure
transport are beyond the scope of this document.
1.2 Terminology
The key words "MUST", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" in this document (in uppercase, as
shown) are to be interpreted as described in RFC 2119.
The following abbreviations are used in this document.
A) CA: Certification Authority
B) CRL: Certificate Revocation List
Yoon, et. al. Expires Nov. 2002 [Page 2]
Internet Draft May 2002
C) CMP: Certificate Management Protocol
D) DN: Distinguished Name
E) DER: Distinguished Encoding Rules
F) LDAP: Lightweight Directory Access Protocol
G) POP: Proof of Possession [RFC2510]
H) PEM: Privacy Enhanced Mail
I) RA: Registration Authority
2. Protocol Overview
2.1 Certificate Request Process
To get a certificate, the subscriber MUST be identifed at RA through
out-of-band and the subscriber makes the document which
contains other information for certificate. Then the RA SHOULD give
subscriber an ID and a Password for certificate request.
The following describes the procedure that a user receives a digital
signature certificate in wireless PKI model.
a) RA (or CA) MUST confirm the subscriber's identification through
direct confrontation.
b) RA (or CA) SHOULD give an ID (Reference Number) and a
Password (Authorization Code) to subscriber.
c) RA MUST enroll a subscriber's information in its data-base and
sends it to related CA
d) The subscriber SHOULD generate a key pair and make certificate
request form, sign on certificate request form, and send it to RA
(or CA).
e) The RA (or CA) that received the certificate request form and
subscriber's digital signature MUST confirm the ownership of the
public key that actually corresponds to private key through verifying
the subscriber's digital signature. RA MAY send certificate request
form (RFC2511) to CA.
f) The CA issues a subscriber's X.509v3 certificate.
g) The CA publishes the certificate on its directory or WEB and
SHOULD give a subscriber's certificate or certificate URL
[See Appendix C] to RA or subscriber.
Yoon, et. al. Expires Nov. 2002 [Page 3]
Internet Draft May 2002
h) The RA SHOULD send the response[See Appendix C]
information to the subscriber.
2.2 Configuration of certification request format
Subscriber SHOULD generate certificate request format including
their public keys, and configure a request format that can prevent
Replay attack, message counterfeiting and forging, and deliver the
certification request formats to a CA (or through an RA).
2.2.1 Message Format
SignedContent = signText(M|HMAC(M,K), 1, 0, " ") [See Appendix B]
where, M = type | PK | ID
K = Password
HMAC(M,K)=H(K XOR opad, H(K XOR ipad, M)) [See RFC2104]
"type" : Type string value of management type (digital signature:
110, key distribution: 120) [See appendix A]
PK: digital signature verifying key of subscriber or public key for
key distribution [See appendix D]
ID: reference number of subscriber
Password : authentication code of subscriber
As the option of signText SHOULD be set at 1, PK (public key) and
ID are extracted from M among signed messages.
2.2.2 Structure of certification request protocol
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Subscriber | | RA (or CA)
+++++++++++++++++++++++++++++++++++++++++++++++++++++
CR = SignedContent | |
| ----> |
| | SignedContent = CR
response | <---- |
+++++++++++++++++++++++++++++++++++++++++++++++++++++
RA (or CA) MUST verify SignedContent by means of PK (public
key). (POP verification process [RFC2510])
Yoon, et. al. Expires Nov. 2002 [Page 4]
Internet Draft May 2002
RA (or CA) retrieves the Password corresponding to ID from its
database, and composes N. Then, RA (or CA) calculates H(M,N),
where the M is in the Subscriber's signed CR message. And RA
(or CA) compares calculated value with subscriber's hash value
which is in the Subscriber's signed CR message. (user
authentication)
Response [see Appendix C]
3. References
[WAP211] Forum Proposed Version 9-Mar-2000, WAP-211-X.509:
WAP Certificate and CRL Profile
[WAP217] WAP Forum Proposed Version 3-Mar-2000,
WAP-217-WPKI: Wireless Application Protocol Public Key
Infrastructure Definition
[WAPe2e] WAP Forum Approved Version 11-July-2000, WAPTM
Transport Layer E2E Security Document
[WAPscriptCrypto] WAP Forum Proposed Version 05-Nov-1999,
WMLScript Crypto Library
[WAP261] WAP Forum Approved Version 06-April-2001, Wireless
Transport Layer Security
[RFC2104] H. Krawczyk, M. Bellare,R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", February 1997.
[RFC1521] N. Borenstein, N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", September
1993.
[RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, C.
Adams, "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocols", June 1999.
[RFC2510] C. Adams, S. Farrell, "Internet X.5.09 Public Key
Infrastructure Certificate Management Protocols", March 1999
[RFC2511] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet
X.5.09 Certificate Request Message Format", March 1999
[ITUTX509] ITU-T Recommendation X.509(1997), Information
Yoon, et. al. Expires Nov. 2002 [Page 5]
Internet Draft May 2002
technology - Open System Interconnection - The Directory :
Authentication Framework
[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", January 1999
[PKCS10] RSA Laboratories, "PKCS#10, Certification Request
Syntax Format", 1999.
[PKCS12]RSA Laboratories, "PKCS#12, Personal Information
Exchange Standard", 1999.
4. Security Considerations
To apply the PKI solution in wireless environment, X.509v3
certificate is needed at the mobile terminals. However because of
its performance limitation, the certificate management protocol, like
PKCS#10 or RFC2510, can not be implemented in it. Thus new
certificate management protocol and format is required. And the
this protocol and format should be securely transferred between
subscriber and RA or CA.
This document describes the certificate request format and protocol
which can provide the message integrity and proof of possession
protecting from replay attack.
5. Intellectual Property Rights
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights [see http://www.ietf.org/ipr.html and the part related with WAP,
see http://www.wapforum.org/what/ipr.htm].
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
Yoon, et. al. Expires Nov. 2002 [Page 6]
Internet Draft May 2002
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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies
of claims of rights made available for publication 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 implementors or users of this
specification can be obtained from the IETF Secretariat.
6. Acknowledgements
The authors gratefully acknowledge the contributions of various
members of the Wireless PKI Working Group in Korea - Licensed
CAs, PKI vendors, and Telecommunication companies. Many of
these clarified and improved this document.
Yoon, et. al. Expires Nov. 2002 [Page 7]
Internet Draft May 2002
Appendix A. Definition of management type string, and encoding &
decoding rules
* Definition of management type string
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Type| Encryption & digital signature | Digital signature | Encryption
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Request | 100 | 110 | 120
Re-issuing | 200 | 210 | 220
Update | 300 | 310 | 320
Key Update | 400 | 410 | 420
Suspension | 500 | 510 | 520
Revocation | 600 | 610 | 620
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
type = 3byte(string) & req = Base64 encoded(string) : POST mode
is used.
* Encoding & Decoding rules
- In this document, all binary data MUST comply with the base64
encoding rules.
- The vertical line (|) is used as the separator, but it will not be
used for hash message concatenation.
- The vertical line (|) will be excluded from the range of characters
that can be used as reference numbers (ID).
- The maximum length of the reference number is 10 characters,
and it is alphanumeric and case-sensitive.
- The maximum length of the authorization code is 30 characters,
and it is alphanumeric and case-sensitive.
- The minimum length of the authorization code varies depending
on the period.
Yoon, et. al. Expires Nov. 2002 [Page 8]
Internet Draft May 2002
Appendix B. SignText function [WAPscriptCrypto]
B.1 SignText configuration
signedString = Crypto.signText(StringToSign, options,
keyIdType, keyId)
B.2 Parameters
*stringToSign = String
: contents of actual message
*options = Integer
: OR operation of several optional values is possible.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
value description
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
0x0001 INCLUDE_CONTENT: Information is transferred.
Return value includes StringToSign.
0x0002 INCLUDE_KEY_HASH: Return value includes the public key
hash value corresponding to the signature key.
0x0004 INCLUDE_CERTIFICATE: Return value includes the
certificate or the URL of the certificate. If the Browser cannot
obtain the certificate, "error:noCert" value must be returned.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*KeyIdType = Integer
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
value description
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
0 None:Used when Key Identifier is not used.
1 User_Key_HASH: User public key hash value is
offered to the next parameter (keyId).
2 TRUSTED_Key_HASH: The public key hash value of the
Trusted CA is offered to the next parameter (keyId).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*keyId = String
: Hash value defined in accordance with KeyIdType. For
instance, SHA-1 public key hash value is 20 bytes.
B.3 Return value
*Return value = String or Invalid
: If the return value is without errors, it is the base-64
[RFC1521] encoding of SignedContent.
Yoon, et. al. Expires Nov. 2002 [Page 9]
Internet Draft May 2002
Appendix C. Response to certification request format
C.1 Success
* MIME Type : application/vnd.wap.cert-response
* Content : Base64-encoded CertResponse
enum { cert_info(0), cert(1), referral(2), (255) } CertRespType;
struct {
CharacterSet character_set;
opaque displayName <1 .. 2^8 - 1>;
} CertDisplayName;
struct {
opaque url <0 .. 128>;
} UrlPoint;
struct {
unit8 version;
CertRespType type;
select (type) {
case cert_info:
CertDisplayName display_name;
Identifier ca_domain;
UrlPoint url;
case cert:
CertDisplayName display_name;
Identifier ca_domain;
X509Certificate cert;
case referral:
UrlPoint url;
unit32 seconds_to_wait;
}
} CertResponse;
C.2 Fail
* MIME Type : text/plain
* Content : Error message of ascii text value
Yoon, et. al. Expires Nov. 2002 [Page 10]
Internet Draft May 2002
Appendix D. Structure of PK(Public Key)
enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ;
struct {
PublicKeyType publicKeyType;
select (publicKeyType) {
case ecdh : ECPublicKey ;
case ecdsa : ECPublicKey ;
case rsa : RSAPublicKey ;
} ;
} PublicKey ;
struct {
opaque url <0 .. 128>;
} UrlPoint;
struct {
opaque rsa_exponent<1..2^16-1> ;
opaque rsa_modulus<1..2^16-1> ;
} RSAPublicKey ;
enum { ECunNamed(0), ECNamed(1), implicitlyCA(2), (255) }
ECNameType;
struct {
ECNameType ecNameType;
select (ecNameType) {
case ECunNamed :
ECParameters ecParameters;
case ECNamed :
opaque oid<1..2^8-1> ;
case implicitlyCA :
struct { };
} ;
opaque public_key_point<1..2^8-1> ;
} ECPublicKey ;
enum { ec_prime_p(1), ec_characteristic_two(2), (255) } ECFieldID;
enum { ec_basis_onb(1), ec_basis_trinomial(2),
ec_basis_pentanomial(3), ec_basis_polynomial(4) } ECBasisType;
Yoon, et. al. Expires Nov. 2002 [Page 11]
Internet Draft May 2002
struct {
opaque a <1..2^8-1>;
opaque b <1..2^8-1>;
opaque seed <0..2^8-1>;
} ECCurve;
struct {
ECFieldID field;
select (field) {
case ec_prime_p: opaque prime_p <1..2^8-1>;
case ec_characteristic_two:
uint16 m;
ECBasisType basis;
select (basis) {
case ec_basis_onb:
struct { };
case ec_trinomial:
uint16 k;
case ec_pentanomial:
uint16 k1;
uint16 k2;
uint16 k3;
case ec_basis_polynomial:
opaque irreducible <1..2^8-1>
};
};
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
} ECParameters;
Yoon, et. al. Expires Nov. 2002 [Page 12]
Internet Draft May 2002
Appendix E. ASN.1 Notes
This ASN.1 syntax is just an example. Our wireless certificate request
may be presented this way. The ID and Password which are given to
subscribers through out-of-band (ex. visit) are put to 'certReqId' and
'K' in HMAC. This ASN.1 syntax is based on RFC2511bis.
E.1. CertReqMessage Syntax
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReqId INTEGER,
-- endowed ID to subscriber
pop ProofOfPossession,
-- content depends upon key type }
E.2. Proof of Possession Syntax
ProofOfPossession ::= CHOICE {
signature [0] EXPLICIT POPOSigningKey,
keyDistribution [1] EXPLICIT POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] EXPLICIT POPOSigningKeyInput,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKeyInput ::= SEQUENCE {
publicKeyMAC PKMACValue,
publicKey SubjectPublicKeyInfo
-- publicKey info is not defined in this document,
-- but you can find the related information at
-- draft-ietf-pkix-ipki-pkalgs-05.txt
}
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
value BIT STRING }
POPOPrivKey ::= CHOICE {
subsequentMessage [0] EXPLICIT SubsequentMessage,
dhMAC [1] EXPLICIT BIT STRING }
Yoon, et. al. Expires Nov. 2002 [Page 13]
Internet Draft May 2002
SubsequentMessage ::= INTEGER {
encrURL (0),
-- requests that resulting cert URL be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message. see appendix C)
challengeResp (1) }
-- requests that CA/RA engage in challenge-response
-- exchange with end entity in order to prove private key
-- possession.
It is expected that protocols which incorporate this specification
will include the confirmation and challenge-response messages
necessary to a complete protocol.
E.2.1 Use of Password-Based MAC
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
where ipad and opad are defined in [RFC2104].
The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and
for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.
Yoon, et. al. Expires Nov. 2002 [Page 14]
Internet Draft May 2002
Appendix F. Considerations
As mentioned in introduction, because the mobile environment is limited,
RFC2511 can not be used there. Thus, if possible to reduce the PKI
module and data size, most of functions are omitted except core ones
which can preserve message integrity and entity authentication and
proof of possession. ASN.1 which can be ported in mobile devices is
comparatively big and slow. Usual cert request message format size is
around 600 bytes. But ours are around 200 bytes, a third smaller than
RFC2511 and PKCS#10. And no additional run-time libraries are needed.
Although we tested ASN.1 encoder and decoder at mobile device, WTLS
encoding method is more efficient and effective. PDAs and other handheld
equipments can be afford ASN.1, but still weigh on mobile phone compared
with WTLS one at the moment.
Here are our test equipments;
1. Test phone A
Device model : Samsung A-5000
CPU : msm3100
Clock : 13.5Mhz
Memory : 2M (RAM), 4M(ROM)
OS : REX
Compiler : Arm2.5 compiler
Browser : Mobile Explorer (KS1.2 - optimized by Korean vendor)
2. Test phone B
Device model : Nokia 8887
CPU : msm3100
Clock : 13.5Mhz
Memory : 2M (RAM), 4M(ROM)
OS : REX
Compiler: Arm compiler
Browser: WAP
Yoon, et. al. Expires Nov. 2002 [Page 15]
Internet Draft May 2002
Appendix G. Author Addresses:
Hongsub Lee
78, Garak-dong, Songpa-Gu, Seoul, Korea, 138-803
Korea Information Security Agency
E-Mail: hslee@kisa.or.kr
Jaeil Lee
Korea Information Security Agency
E-Mail: jilee@kisa.or.kr
Young Lee
Korea Information Security Agency
E-Mail: ylee@kisa.or.kr
Chanjoo Chung
Korea Information Security Agency
E-Mail: cjchung@kisa.or.kr
Jaeho Yoon
Korea Information Security Agency
E-Mail: jhyoon@kisa.or.kr
Yoon, et. al. Expires Nov. 2002 [Page 16]