PKIX Working Group J. H. Yoon (KISA) Internet Draft C. J. Chung expires May, 2002 Y. Lee J. I. Lee November, 2001 Wireless Internet X.509 Public Key Infrastructure Certificate Request Message Format and Protocol (WCRMFP) 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, 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 CRMF(RFC2511) 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 optimised certificate request format and protocol 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. 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 Yoon, Chung, Lee Expires May. 2002 [Page 2] Internet Draft Nov 2001 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 direct confrontation and the subscriber makes the document which contains other information for certificate. Then the RA SHOULD give an ID and a Password for certificate request to subscriber. 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 certificate request form, signs on certificate request form, and sends 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 (PKCS#10 or RFC2511) to CA. f) The CA issues a subscriber's X.509v3 certificate. g) The CA publishes the certificate on its directory and SHOULD give a subscriber's certificate or certificate URL [See Appendix C] to RA or subscriber. Yoon, Chung, Lee Expires May. 2002 [Page 3] Internet Draft Nov 2001 h) The RA SHOULD send the response[See Appendix C] information to the subscriber. 2.2 Configuration of certification request format Subscribers 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|H(M,N), 1, 0, í—í˜) [See Appendix B] where, M = type | PK | ID N = Password H(M,N) [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 : authorization 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 ++++++++++++++++++++++++++++++++++++++++++++++++ RA(or CA) MUST verify SignedContent by means of PK (public key). (POP verification process [RFC2510]) Yoon, Chung, Lee Expires May. 2002 [Page 4] Internet Draft Nov 2001 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) 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, Chung, Lee Expires May. 2002 [Page 5] Internet Draft Nov 2001 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 terminal. However because of its 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 concerning with protection from replay attack and DoS attack. 5. 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 Yoon, Chung, Lee Expires May. 2002 [Page 6] Internet Draft Nov 2001 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. 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 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. Yoon, Chung, Lee Expires May. 2002 [Page 7] Internet Draft Nov 2001 +++++++++++++++++++++++++++ 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 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. +++++++++++++++++++++++++++++++++++++++++++++++++ Yoon, Chung, Lee Expires May. 2002 [Page 8] Internet Draft Nov 2001 íñ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. 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; Yoon, Chung, Lee Expires May. 2002 [Page 9] Internet Draft Nov 2001 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 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 ; Yoon, Chung, Lee Expires May. 2002 [Page 10] Internet Draft Nov 2001 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; 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; Yoon, Chung, Lee Expires May. 2002 [Page 11] Internet Draft Nov 2001 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; 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 12]