PKIX Working Group J. H. Yoon (KISA)
Internet Draft C. J. Chung (KISA)
expires May, 2002 Y. Lee (KISA)
J. I. Lee (KISA)
November, 2001
Wireless Internet X.509 Public Key Infrastructure
Certificate Management Protocols
<draft-yoon-pkix-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 (2001). All Rights Reserved.
Abstract
This document describes the X.509 Public Key Infrastructure(PKI)
Certificate Management Protocols(CMP) in wireless internet
environment. Protocol messages are defined for all relevant
aspects of certificate creation and management. Note that
"certificate" in this document refers to an X.509v3 Certificate as
defined in [ITUTX509].
Yoon, Chung, Lee Expires May. 2002 [Page 1]
Internet Draft Nov 2001
1. Introduction
Differring from wired system terminal, wirelss one has many
limitations in CPU, memory, battery life, and a user interface.
Moreover the wireless network has very low bandwith, latency, and
data loss. For that reasons, using PKCS#10 or CMP(RFC2510) is
difficult in wireless environment. Actually the problem comes from
ASN.1 encoding. Some big modules, like ASN.1 (compilier) and
LDAP etc., can not be uploaded at mobile terminals. So new format
and protocol in certificate request are needed.
This document describes wireless cerfificate management
protocols using signText function[WAPscriptCrypto] defined
in WAP specification.
1.1 Protocol requirements
Construction of a certification request involves the following steps:
a) A SignedContent(Certificate Request) value is constructed. This
value may include the public key, a portion of the end-entity's (EE's)
ID and password, nonce. Other requested certificate fields, and
additional control information related to the registration process are
made in off-line.
b) A proof of possession (of the private key corresponding to the
public key for which a certificate is being requested) value may
be calculated across the SignedContent value.
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
C) CMP: Certificate Management Protocol
D) DN: Distinguished Name
E) DER: Distinguished Encoding Rules
Yoon, Chung, Lee Expires May. 2002 [Page 2]
Internet Draft Nov 2001
F) LDAP: Lightweight Directory Access Protocol
G) POP: Proof of Possession
H) PEM: Privacy Enhanced Mail
I) RA: Registration Authority
J) CN: Common Name
2. Certificate management protocol
When reissue, renewal, suspension, or revocation of a subscriber's
certificate is requested, the signText function defined in WAP is
used to generate the request format.
2.1 Certificate reissuing request
2.1.1 Overview
Certificate reissuing request format is created when the subscriber
believes that the digital signature generation key is lost, damaged,
stolen, or leaked, and transmit it to the certification authority (or the
registration authority).
2.1.2 Configuration of certificate reissue request format
The subscriber MUST generate POP method, certificate reissue
request format including the public keys, and configure a request
format that can prevent Replay attack, message counterfeiting and
forgery, and ensures confidentiality, and deliver the certificate
reissue request format to a certification authority (or a registration
authority).
2.1.3 Structure of certificate reissue request format
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subscriber | | RA (or CA)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CR = SignedContent | CR |
| ----------> |
| | SignedContent = CR
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
M = type|PK_new|ID_new
N = Password
H(M,N) [See RFC2104]
SignedContent = signText(M|H(M,N), 1, 0, íí) [See Appendix B]
Yoon, Chung, Lee Expires May. 2002 [Page 3]
Internet Draft Nov 2001
"type" : Type string value of management type (digital signature: 210)
PK_new: new digital signature verification key of subscriber
[See appendix D]
ID_new: new reference number of subscriber
Password: authorization code of subscriber
As the option of signText is set at 1, PK (public key) and ID
are extracted from M among signed messages.
RA(or CA) MUST verify SignedContent by means of PK (public
key). (POP verification process [RFC2510])
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)
2.2 Certificate renewal request
2.2.1Overview
The certificate update request is to configure and
create the certificate renewal request format before
the expiry date, and submit it to the certification authority
(or the registration authority).
2.2.2 Configuration of certificate renewal request format
Renewal can be done with or without key replacement. In these cases,
the update request format must be created and sent to the certification
authority (or the registration authority).
2.2.3 Structure of certificate update request format
Yoon, Chung, Lee Expires May. 2002 [Page 4]
Internet Draft Nov 2001
o Case1. No key replacement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subscriber | | RA (or CA)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| nonce | nonce generated
| <---------- |
CR = SignedContent | CR |
| ----------> |
| | SignedContent = CR
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
M = type|CN string in owner's DN
N = nonce(replay attack prevention)
SignedContent = signText(M|N, 5, 1, H(public key))
"type" : Type string value of management type (digital signature: 310)
PK: digital signature verification key of subscriber
H(public key) : hash value for subscriber's existing public key
nonce : UTC time generated by server
As the option of signText is set at 5, the existing certificate must be
brought along with the PK of the existing certificate.
Verify SignedContent by means of PK(public key).(user
verification process)
Here, the CN string in subscriber's DN is an option,
and can have a null value. (including the vertical line ( | )). The "type"
string must be included.
o Case2. Key replacement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subscriber | | RA (or CA)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| nonce | nonce generated
| <---------- |
CR = SignedContent | CR |
| ----------> |
| | SignedContent = CR
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
M = type|PK
Generate SignValue with nonce signed by SK_new distribution
N = nonce|SignValue
SignedContent = signText(M|N, 5, 1, H(public key))
Yoon, Chung, Lee Expires May. 2002 [Page 5]
Internet Draft Nov 2001
"type" : Type string value of management type (digital signature: 410)
PK: digital signature verification key of subscriber
PK_new : subscriberí¯s new digital signature verification key
SK_new : subscriberí¯s digital signature generation key
H(public key) : hash value for subscriber's existing public key
nonce : UTC time generated by server
As the option of signText is set at 5, the existing certificate must be
brought along with the PK of the existing certificate.
Verify SignedContent by means of PK(public key).(user
verification process)
N is verified by the signed message M (POP verification regarding
new public key)
2.3 Certificate suspension request
2.3.1 Overview
The suspension request format is created when the
subscriber suspects that his generation key has been lost, damaged,
stolen, or leaked.
2.3.2 Configuration of certificate suspension request format
The subscriber must configure the certificate suspension request
format capable of preventing user certification and replay attack, and
submit it to the certification authority (or the registration authority).
2.3.3 Structure of certificate suspension request format
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subscriber | | RA (or CA)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| nonce | nonce generated
| <---------- |
CR = SignedContent | CR |
| ----------> |
| | SignedContent = CR
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
M = type|CertificateHold
N = nonce(replay attack prevention)
SignedContent = signText(M|N, 5, 1, H(public key))
Yoon, Chung, Lee Expires May. 2002 [Page 6]
Internet Draft Nov 2001
"type" : Type string value of management type (digital signature: 510)
PK: digital signature verification key of subscriber
H(public key) : hash value for subscriber's digital signature
verification key
nonce : UTC time generated by server
As the option of signText is set at 5, the existing certificate must be
brought along with the PK of the existing certificate.
Verify SignedContent by means of PK(public key) (user verification
process).
The reason for suspension is checked through signed message M.
As the option of SignText is set at 5, the existing certificate is added
to the suspension list.
2.4 Certificate revocation request
2.4.1 Overview
When the subscriber applied for certificate revocation, or it is suspected
that the subscriberí¯s generation key is lost, damaged, stolen, or leaked,
the subscriber must create the revocation request format, and submit it
to the certification authority (or the registration authority).
2.4.2 Configuration of certificate revocation request format
If the subscriberí¯s generation key is lost or damaged, the subscriber
must visit the certification authority (or the registration authority) in person,
and apply for revocation. If revocation has been applied for because
it is suspected that the subscriberí¯s generation key was stolen or leaked,
the subscriber must create the revocation request format via online, and
submit it to certification authority (or the registration authority).
2.4.3 Structure of certificate revocation request format
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subscriber | | RA (or CA)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| nonce | nonce generated
| <---------- |
CR = SignedContent | CR |
| ----------> |
| | SignedContent = CR
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yoon, Chung, Lee Expires May. 2002 [Page 7]
Internet Draft Nov 2001
M = type|ReasonCode
SignedContent = signText(M, 5, 1, H(public key))
"type" : Type string value of management type (digital signature: 610)
PK: digital signature verification key of subscriber
H(public server) : hash value for subscriber's digital signature
verification key
nonce : UTC time generated by server
As the option of signText is set at 5, the existing certificate must be
brought along with the PK of the existing certificate.
Verify SignedContent by means of PK(public key) (user verification process).
The reason for revocation is checked through signed message M.
As the option of SignText is set at 5, the existing certificate is added
to the revocation list.
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
Yoon, Chung, Lee Expires May. 2002 [Page 8]
Internet Draft Nov 2001
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
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. Intellectual Property Rights
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).
The IETF takes no position regarding the validity or scope of any
intellectual property 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; 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.
Yoon, Chung, Lee Expires May. 2002 [Page 9]
Internet Draft Nov 2001
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
Renewal | 300 310 320
Update (key) | 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.
+++++++++++++++++++++++++++
Period Length
+++++++++++++++++++++++++++
1 day 12 characters
3 days 13 characters
1 week 14 characters
10 days 14 characters
2 weeks 15 characters
1 month 16 characters
+++++++++++++++++++++++++++
íÛ In case that ECDSA key is 20 bytes long, and the reference
Yoon, Chung, Lee Expires May. 2002 [Page 10]
Internet Draft Nov 2001
number is 8 bytes long
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).
++++++++++++++++++++++++++++++++++++++++++++++++
Yoon, Chung, Lee Expires May. 2002 [Page 11]
Internet Draft Nov 2001
íñ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.
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:
Yoon, Chung, Lee Expires May. 2002 [Page 12]
Internet Draft Nov 2001
UrlPoint url;
unit32 seconds_to_wait;
}
} CertResponse;
C.2 Fail
í MIME Type : text/plain
í Content : Error message of ascii text value
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) {
Yoon, Chung, Lee Expires May. 2002 [Page 13]
Internet Draft Nov 2001
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;
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;
Yoon, Chung, Lee Expires May. 2002 [Page 14]
Internet Draft Nov 2001
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
} ECParameters;
Appendix E. Author Addresses:
Jaeil Lee
78, Garak-dong, Songpa-Gu, Seoul, Korea, 138-803
Korea Information Security Agency
E-Mail: jilee@kisa.or.kr
Young Lee
Korea Information Security Agency
E-Mail: ylee@kisa.or.kr
Chanju Chung
Korea Information Security Agency
E-Mail: cjchung@kisa.or.kr
Jaeho Yoon
Korea Information Security Agency
E-Mail: jhyoon@kisa.or.kr
Yoon, Chung, Lee Expires May. 2002 [Page 15]