idnits 2.17.1 draft-yoon-pkix-wireless-internet-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 56 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '..., the subscriber MUST be identifed at ...' RFC 2119 keyword, line 101: '...r certificate. Then the RA SHOULD give...' RFC 2119 keyword, line 107: '...a) RA (or CA) MUST confirm the subscri...' RFC 2119 keyword, line 110: '...b) RA (or CA) SHOULD give an ID (Refer...' RFC 2119 keyword, line 113: '...c) RA MUST enroll a subscriber's infor...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 406 has weird spacing: '...KeyType pub...' == Line 427 has weird spacing: '...ameType ecN...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'See RFC2104' is mentioned on line 147, but not defined -- Looks like a reference, but probably isn't: '0' on line 517 -- Looks like a reference, but probably isn't: '1' on line 518 == Missing Reference: 'PKCS11' is mentioned on line 543, but not defined == Missing Reference: 'RFC2202' is mentioned on line 544, but not defined == Unused Reference: 'WAP211' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'WAP217' is defined on line 189, but no explicit reference was found in the text == Unused Reference: 'WAPe2e' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'WAP261' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 210, but no explicit reference was found in the text == Unused Reference: 'RFC2511' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'ITUTX509' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 224, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 227, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP211' -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP217' -- Possible downref: Non-RFC (?) normative reference: ref. 'WAPe2e' -- Possible downref: Non-RFC (?) normative reference: ref. 'WAPscriptCrypto' -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP261' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2511 (Obsoleted by RFC 4211) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUTX509' ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10' Summary: 12 errors (**), 0 flaws (~~), 16 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group J. H. Yoon (KISA) 2 Internet Draft C. J. Chung 3 expires November, 2002 Y. Lee 4 J. I. Lee 5 H. S. Lee 6 May, 2002 8 Wireless Internet X.509 Public Key Infrastructure 9 Certificate Request Message Format and Protocol (WCRMFP) 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This document describes the Wireless Certificate Request 39 Message Format and Protocol (WCRMFP) in wireless internet 40 environment. This format and protocol are used to convey a request 41 for a certificate to a Certification Authority (CA) (possibly via a 42 Registration Authority (RA)) for the purposes of X.509 certificate 43 production. The request will typically include a public key and 44 associated registration information. 46 1. Introduction 48 Different from wired system terminal, wireless one has many 49 limitations in CPU, memory, battery life, and a user interface. 50 Moreover the wireless network has very low bandwidth, latency, and 51 data loss. For that reasons, using CRMF(RFC2511) is a burden to 52 wireless and environment. So new message format in certificate 53 request is needed. 55 This document describes optimised certificate request format fitted 56 for wireless and mobile devices protocol using SignText function 57 [WAPscriptCrypto] defined in WAP specification. 59 1.1 Protocol requirements 61 Construction of a certificate request needs the following requirements: 63 a) Certificate Request Message Format is constructed at mobile 64 device. This value should include the public key, end-entity's 65 (EE's) ID and password. Other requested certificate fields, and 66 additional control information related to the registration process 67 are made in out-of-band. 69 b) A proof of possession (of the private key corresponding to the 70 public key for which a certificate is being requested) value is 71 included in certificate request massage. 73 c) The CR(Certificate Request) message is securely 74 communicated to a CA. However the specific methods of secure 75 transport are beyond the scope of this document. 77 1.2 Terminology 79 The key words "MUST", "REQUIRED", "SHOULD", 80 "RECOMMENDED", and "MAY" in this document (in uppercase, as 81 shown) are to be interpreted as described in RFC 2119. 83 The following abbreviations are used in this document. 85 A) CA: Certification Authority 86 B) CRL: Certificate Revocation List 87 C) CMP: Certificate Management Protocol 88 D) DN: Distinguished Name 89 E) DER: Distinguished Encoding Rules 90 F) LDAP: Lightweight Directory Access Protocol 91 G) POP: Proof of Possession [RFC2510] 92 H) PEM: Privacy Enhanced Mail 93 I) RA: Registration Authority 95 2. Protocol Overview 97 2.1 Certificate Request Process 99 To get a certificate, the subscriber MUST be identifed at RA through 100 out-of-band and the subscriber makes the document which 101 contains other information for certificate. Then the RA SHOULD give 102 subscriber an ID and a Password for certificate request. 104 The following describes the procedure that a user receives a digital 105 signature certificate in wireless PKI model. 107 a) RA (or CA) MUST confirm the subscriber's identification through 108 direct confrontation. 110 b) RA (or CA) SHOULD give an ID (Reference Number) and a 111 Password (Authorization Code) to subscriber. 113 c) RA MUST enroll a subscriber's information in its data-base and 114 sends it to related CA 116 d) The subscriber SHOULD generate a key pair and make certificate 117 request form, sign on certificate request form, and send it to RA 118 (or CA). 120 e) The RA (or CA) that received the certificate request form and 121 subscriber's digital signature MUST confirm the ownership of the 122 public key that actually corresponds to private key through verifying 123 the subscriber's digital signature. RA MAY send certificate request 124 form (RFC2511) to CA. 126 f) The CA issues a subscriber's X.509v3 certificate. 128 g) The CA publishes the certificate on its directory or WEB and 129 SHOULD give a subscriber's certificate or certificate URL 130 [See Appendix C] to RA or subscriber. 132 h) The RA SHOULD send the response[See Appendix C] 133 information to the subscriber. 135 2.2 Configuration of certification request format 137 Subscriber SHOULD generate certificate request format including 138 their public keys, and configure a request format that can prevent 139 Replay attack, message counterfeiting and forging, and deliver the 140 certification request formats to a CA (or through an RA). 142 2.2.1 Message Format 144 SignedContent = signText(M|HMAC(M,K), 1, 0, " ") [See Appendix B] 145 where, M = type | PK | ID 146 K = Password 147 HMAC(M,K)=H(K XOR opad, H(K XOR ipad, M)) [See RFC2104] 149 "type" : Type string value of management type (digital signature: 150 110, key distribution: 120) [See appendix A] 152 PK: digital signature verifying key of subscriber or public key for 153 key distribution [See appendix D] 155 ID: reference number of subscriber 157 Password : authentication code of subscriber 159 As the option of signText SHOULD be set at 1, PK (public key) and 160 ID are extracted from M among signed messages. 162 2.2.2 Structure of certification request protocol 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 165 Subscriber | | RA (or CA) 166 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 167 CR = SignedContent | | 168 | ----> | 169 | | SignedContent = CR 170 response | <---- | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 173 RA (or CA) MUST verify SignedContent by means of PK (public 174 key). (POP verification process [RFC2510]) 175 RA (or CA) retrieves the Password corresponding to ID from its 176 database, and composes N. Then, RA (or CA) calculates H(M,N), 177 where the M is in the Subscriber's signed CR message. And RA 178 (or CA) compares calculated value with subscriber's hash value 179 which is in the Subscriber's signed CR message. (user 180 authentication) 182 Response [see Appendix C] 184 3. References 186 [WAP211] Forum Proposed Version 9-Mar-2000, WAP-211-X.509: 187 WAP Certificate and CRL Profile 189 [WAP217] WAP Forum Proposed Version 3-Mar-2000, 190 WAP-217-WPKI: Wireless Application Protocol Public Key 191 Infrastructure Definition 193 [WAPe2e] WAP Forum Approved Version 11-July-2000, WAPTM 194 Transport Layer E2E Security Document 196 [WAPscriptCrypto] WAP Forum Proposed Version 05-Nov-1999, 197 WMLScript Crypto Library 199 [WAP261] WAP Forum Approved Version 06-April-2001, Wireless 200 Transport Layer Security 202 [RFC2104] H. Krawczyk, M. Bellare,R. Canetti, "HMAC: 203 Keyed-Hashing for Message Authentication", February 1997. 205 [RFC1521] N. Borenstein, N. Freed, "MIME (Multipurpose Internet 206 Mail Extensions) Part One: Mechanisms for Specifying and 207 Describing the Format of Internet Message Bodies", September 208 1993. 210 [RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. 211 Adams, "X.509 Internet Public Key Infrastructure Online Certificate 212 Status Protocols", June 1999. 214 [RFC2510] C. Adams, S. Farrell, "Internet X.5.09 Public Key 215 Infrastructure Certificate Management Protocols", March 1999 217 [RFC2511] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet 218 X.5.09 Certificate Request Message Format", March 1999 220 [ITUTX509] ITU-T Recommendation X.509(1997), Information 221 technology - Open System Interconnection - The Directory : 222 Authentication Framework 224 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 225 Public Key Infrastructure Certificate and CRL Profile", January 1999 227 [PKCS10] RSA Laboratories, "PKCS#10, Certification Request 228 Syntax Format", 1999. 230 [PKCS12]RSA Laboratories, "PKCS#12, Personal Information 231 Exchange Standard", 1999. 233 4. Security Considerations 235 To apply the PKI solution in wireless environment, X.509v3 236 certificate is needed at the mobile terminals. However because of 237 its performance limitation, the certificate management protocol, like 238 PKCS#10 or RFC2510, can not be implemented in it. Thus new 239 certificate management protocol and format is required. And the 240 this protocol and format should be securely transferred between 241 subscriber and RA or CA. 243 This document describes the certificate request format and protocol 244 which can provide the message integrity and proof of possession 245 protecting from replay attack. 247 5. Intellectual Property Rights 249 This document and translations of it may be copied and furnished to 250 others, and derivative works that comment on or otherwise explain it 251 or assist in its implementation may be prepared, copied, published 252 and distributed, in whole or in part, without restriction of any kind. 254 The IETF has been notified of intellectual property rights claimed in 255 regard to some or all of the specification contained in this 256 document. For more information consult the online list of claimed 257 rights [see http://www.ietf.org/ipr.html and the part related with WAP, 258 see http://www.wapforum.org/what/ipr.htm]. 260 The IETF takes no position regarding the validity or scope of any 261 intellectual property or other rights that might be claimed to 262 pertain to the implementation or use of the technology described in 263 this document or the extent to which any license under such rights 264 might or might not be available; neither does it represent that it 265 has made any effort to identify any such rights. Information on the 266 IETF's procedures with respect to rights in standards-track and 267 standards-related documentation can be found in BCP-11. Copies 268 of claims of rights made available for publication and any 269 assurances of licenses to be made available, or the result of an 270 attempt made to obtain a general license or permission for the use 271 of such proprietary rights by implementors or users of this 272 specification can be obtained from the IETF Secretariat. 274 6. Acknowledgements 276 The authors gratefully acknowledge the contributions of various 277 members of the Wireless PKI Working Group in Korea - Licensed 278 CAs, PKI vendors, and Telecommunication companies. Many of 279 these clarified and improved this document. 281 Appendix A. Definition of management type string, and encoding & 282 decoding rules 284 * Definition of management type string 286 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 287 Type| Encryption & digital signature | Digital signature | Encryption 288 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 289 Request | 100 | 110 | 120 290 Re-issuing | 200 | 210 | 220 291 Update | 300 | 310 | 320 292 Key Update | 400 | 410 | 420 293 Suspension | 500 | 510 | 520 294 Revocation | 600 | 610 | 620 295 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 297 type = 3byte(string) & req = Base64 encoded(string) : POST mode 298 is used. 300 * Encoding & Decoding rules 302 - In this document, all binary data MUST comply with the base64 303 encoding rules. 304 - The vertical line (|) is used as the separator, but it will not be 305 used for hash message concatenation. 306 - The vertical line (|) will be excluded from the range of characters 307 that can be used as reference numbers (ID). 308 - The maximum length of the reference number is 10 characters, 309 and it is alphanumeric and case-sensitive. 310 - The maximum length of the authorization code is 30 characters, 311 and it is alphanumeric and case-sensitive. 312 - The minimum length of the authorization code varies depending 313 on the period. 315 Appendix B. SignText function [WAPscriptCrypto] 317 B.1 SignText configuration 319 signedString = Crypto.signText(StringToSign, options, 320 keyIdType, keyId) 322 B.2 Parameters 324 *stringToSign = String 325 : contents of actual message 327 *options = Integer 328 : OR operation of several optional values is possible. 329 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 330 value description 331 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 332 0x0001 INCLUDE_CONTENT: Information is transferred. 333 Return value includes StringToSign. 334 0x0002 INCLUDE_KEY_HASH: Return value includes the public key 335 hash value corresponding to the signature key. 336 0x0004 INCLUDE_CERTIFICATE: Return value includes the 337 certificate or the URL of the certificate. If the Browser cannot 338 obtain the certificate, "error:noCert" value must be returned. 339 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 341 *KeyIdType = Integer 342 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 343 value description 344 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 345 0 None:Used when Key Identifier is not used. 346 1 User_Key_HASH: User public key hash value is 347 offered to the next parameter (keyId). 348 2 TRUSTED_Key_HASH: The public key hash value of the 349 Trusted CA is offered to the next parameter (keyId). 350 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 351 *keyId = String 352 : Hash value defined in accordance with KeyIdType. For 353 instance, SHA-1 public key hash value is 20 bytes. 355 B.3 Return value 357 *Return value = String or Invalid 358 : If the return value is without errors, it is the base-64 359 [RFC1521] encoding of SignedContent. 361 Appendix C. Response to certification request format 363 C.1 Success 365 * MIME Type : application/vnd.wap.cert-response 366 * Content : Base64-encoded CertResponse 368 enum { cert_info(0), cert(1), referral(2), (255) } CertRespType; 370 struct { 371 CharacterSet character_set; 372 opaque displayName <1 .. 2^8 - 1>; 373 } CertDisplayName; 375 struct { 376 opaque url <0 .. 128>; 377 } UrlPoint; 379 struct { 380 unit8 version; 381 CertRespType type; 382 select (type) { 383 case cert_info: 384 CertDisplayName display_name; 385 Identifier ca_domain; 386 UrlPoint url; 387 case cert: 388 CertDisplayName display_name; 389 Identifier ca_domain; 390 X509Certificate cert; 391 case referral: 392 UrlPoint url; 393 unit32 seconds_to_wait; 394 } 395 } CertResponse; 397 C.2 Fail 399 * MIME Type : text/plain 400 * Content : Error message of ascii text value 401 Appendix D. Structure of PK(Public Key) 403 enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ; 405 struct { 406 PublicKeyType publicKeyType; 407 select (publicKeyType) { 408 case ecdh : ECPublicKey ; 409 case ecdsa : ECPublicKey ; 410 case rsa : RSAPublicKey ; 411 } ; 412 } PublicKey ; 414 struct { 415 opaque url <0 .. 128>; 416 } UrlPoint; 418 struct { 419 opaque rsa_exponent<1..2^16-1> ; 420 opaque rsa_modulus<1..2^16-1> ; 421 } RSAPublicKey ; 423 enum { ECunNamed(0), ECNamed(1), implicitlyCA(2), (255) } 424 ECNameType; 426 struct { 427 ECNameType ecNameType; 428 select (ecNameType) { 429 case ECunNamed : 430 ECParameters ecParameters; 431 case ECNamed : 432 opaque oid<1..2^8-1> ; 433 case implicitlyCA : 434 struct { }; 435 } ; 437 opaque public_key_point<1..2^8-1> ; 439 } ECPublicKey ; 441 enum { ec_prime_p(1), ec_characteristic_two(2), (255) } ECFieldID; 443 enum { ec_basis_onb(1), ec_basis_trinomial(2), 444 ec_basis_pentanomial(3), ec_basis_polynomial(4) } ECBasisType; 445 struct { 446 opaque a <1..2^8-1>; 447 opaque b <1..2^8-1>; 448 opaque seed <0..2^8-1>; 449 } ECCurve; 451 struct { 452 ECFieldID field; 453 select (field) { 454 case ec_prime_p: opaque prime_p <1..2^8-1>; 455 case ec_characteristic_two: 456 uint16 m; 457 ECBasisType basis; 458 select (basis) { 459 case ec_basis_onb: 460 struct { }; 461 case ec_trinomial: 462 uint16 k; 463 case ec_pentanomial: 464 uint16 k1; 465 uint16 k2; 466 uint16 k3; 467 case ec_basis_polynomial: 468 opaque irreducible <1..2^8-1> 469 }; 470 }; 471 ECCurve curve; 472 ECPoint base; 473 opaque order <1..2^8-1>; 474 opaque cofactor <1..2^8-1>; 475 } ECParameters; 476 Appendix E. ASN.1 Notes 478 This ASN.1 syntax is just an example. Our wireless certificate request 479 may be presented this way. The ID and Password which are given to 480 subscribers through out-of-band (ex. visit) are put to 'certReqId' and 481 'K' in HMAC. This ASN.1 syntax is based on RFC2511bis. 483 E.1. CertReqMessage Syntax 485 CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg 487 CertReqMsg ::= SEQUENCE { 488 certReqId INTEGER, 489 -- endowed ID to subscriber 490 pop ProofOfPossession, 491 -- content depends upon key type } 493 E.2. Proof of Possession Syntax 495 ProofOfPossession ::= CHOICE { 496 signature [0] EXPLICIT POPOSigningKey, 497 keyDistribution [1] EXPLICIT POPOPrivKey } 499 POPOSigningKey ::= SEQUENCE { 500 poposkInput [0] EXPLICIT POPOSigningKeyInput, 501 algorithmIdentifier AlgorithmIdentifier, 502 signature BIT STRING } 504 POPOSigningKeyInput ::= SEQUENCE { 505 publicKeyMAC PKMACValue, 506 publicKey SubjectPublicKeyInfo 507 -- publicKey info is not defined in this document, 508 -- but you can find the related information at 509 -- draft-ietf-pkix-ipki-pkalgs-05.txt 510 } 512 PKMACValue ::= SEQUENCE { 513 algId AlgorithmIdentifier, 514 value BIT STRING } 516 POPOPrivKey ::= CHOICE { 517 subsequentMessage [0] EXPLICIT SubsequentMessage, 518 dhMAC [1] EXPLICIT BIT STRING } 520 SubsequentMessage ::= INTEGER { 521 encrURL (0), 522 -- requests that resulting cert URL be encrypted for the 523 -- end entity (following which, POP will be proven in a 524 -- confirmation message. see appendix C) 525 challengeResp (1) } 526 -- requests that CA/RA engage in challenge-response 527 -- exchange with end entity in order to prove private key 528 -- possession. 530 It is expected that protocols which incorporate this specification 531 will include the confirmation and challenge-response messages 532 necessary to a complete protocol. 534 E.2.1 Use of Password-Based MAC 536 PBMParameter ::= SEQUENCE { 537 salt OCTET STRING, 538 owf AlgorithmIdentifier, 539 -- AlgId for a One-Way Function (SHA-1 recommended) 540 iterationCount INTEGER, 541 -- number of times the OWF is applied 542 mac AlgorithmIdentifier 543 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 544 } -- or HMAC [RFC2104, RFC2202]) 546 publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) ) 548 where ipad and opad are defined in [RFC2104]. 550 The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and 551 for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}. 553 Appendix F. Considerations 555 As mentioned in introduction, because the mobile environment is limited, 556 RFC2511 can not be used there. Thus, if possible to reduce the PKI 557 module and data size, most of functions are omitted except core ones 558 which can preserve message integrity and entity authentication and 559 proof of possession. ASN.1 which can be ported in mobile devices is 560 comparatively big and slow. Usual cert request message format size is 561 around 600 bytes. But ours are around 200 bytes, a third smaller than 562 RFC2511 and PKCS#10. And no additional run-time libraries are needed. 564 Although we tested ASN.1 encoder and decoder at mobile device, WTLS 565 encoding method is more efficient and effective. PDAs and other handheld 566 equipments can be afford ASN.1, but still weigh on mobile phone compared 567 with WTLS one at the moment. 569 Here are our test equipments; 571 1. Test phone A 572 Device model : Samsung A-5000 573 CPU : msm3100 574 Clock : 13.5Mhz 575 Memory : 2M (RAM), 4M(ROM) 576 OS : REX 577 Compiler : Arm2.5 compiler 578 Browser : Mobile Explorer (KS1.2 - optimized by Korean vendor) 580 2. Test phone B 581 Device model : Nokia 8887 582 CPU : msm3100 583 Clock : 13.5Mhz 584 Memory : 2M (RAM), 4M(ROM) 585 OS : REX 586 Compiler: Arm compiler 587 Browser: WAP 588 Appendix G. Author Addresses: 590 Hongsub Lee 591 78, Garak-dong, Songpa-Gu, Seoul, Korea, 138-803 592 Korea Information Security Agency 593 E-Mail: hslee@kisa.or.kr 595 Jaeil Lee 596 Korea Information Security Agency 597 E-Mail: jilee@kisa.or.kr 599 Young Lee 600 Korea Information Security Agency 601 E-Mail: ylee@kisa.or.kr 603 Chanjoo Chung 604 Korea Information Security Agency 605 E-Mail: cjchung@kisa.or.kr 607 Jaeho Yoon 608 Korea Information Security Agency 609 E-Mail: jhyoon@kisa.or.kr