idnits 2.17.1 draft-yoon-pkix-00.txt: -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(280): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(283): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 11 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 93 instances of lines with control characters in the document. ** The abstract seems to contain references ([ITUTX509]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 112: '...The subscriber MUST generate POP metho...' RFC 2119 keyword, line 142: '...RA(or CA) MUST verify SignedContent by...' RFC 2119 keyword, line 405: '... all binary data MUST comply with the ...' 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 525 has weird spacing: '...KeyType pub...' == Line 546 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 131, but not defined == Unused Reference: 'WAP211' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'WAP217' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'WAPe2e' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'WAP261' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC2511' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 357, 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: 15 errors (**), 0 flaws (~~), 16 warnings (==), 10 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 (KISA) 3 expires May, 2002 Y. Lee (KISA) 4 J. I. Lee (KISA) 5 November, 2001 7 Wireless Internet X.509 Public Key Infrastructure 8 Certificate Management Protocols 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This document describes the X.509 Public Key Infrastructure(PKI) 37 Certificate Management Protocols(CMP) in wireless internet 38 environment. Protocol messages are defined for all relevant 39 aspects of certificate creation and management. Note that 40 "certificate" in this document refers to an X.509v3 Certificate as 41 defined in [ITUTX509]. 43 1. Introduction 45 Differring from wired system terminal, wirelss one has many 46 limitations in CPU, memory, battery life, and a user interface. 47 Moreover the wireless network has very low bandwith, latency, and 48 data loss. For that reasons, using PKCS#10 or CMP(RFC2510) is 49 difficult in wireless environment. Actually the problem comes from 50 ASN.1 encoding. Some big modules, like ASN.1 (compilier) and 51 LDAP etc., can not be uploaded at mobile terminals. So new format 52 and protocol in certificate request are needed. 54 This document describes wireless cerfificate management 55 protocols using signText function[WAPscriptCrypto] defined 56 in WAP specification. 58 1.1 Protocol requirements 60 Construction of a certification request involves the following steps: 62 a) A SignedContent(Certificate Request) value is constructed. This 63 value may include the public key, a portion of the end-entity's (EE's) 64 ID and password, nonce. Other requested certificate fields, and 65 additional control information related to the registration process are 66 made in off-line. 68 b) A proof of possession (of the private key corresponding to the 69 public key for which a certificate is being requested) value may 70 be calculated across the SignedContent value. 72 c) The CR(Certificate Request) message is securely 73 communicated to a CA. However the specific methods of secure 74 transport are beyond the scope of this document. 76 1.2 Terminology 78 The key words "MUST", "REQUIRED", "SHOULD", 79 "RECOMMENDED", and "MAY" in this document (in uppercase, 80 as shown) are to be interpreted as described in RFC 2119. 82 The following abbreviations are used in this document. 84 A) CA: Certification Authority 85 B) CRL: Certificate Revocation List 86 C) CMP: Certificate Management Protocol 87 D) DN: Distinguished Name 88 E) DER: Distinguished Encoding Rules 89 F) LDAP: Lightweight Directory Access Protocol 90 G) POP: Proof of Possession 91 H) PEM: Privacy Enhanced Mail 92 I) RA: Registration Authority 93 J) CN: Common Name 95 2. Certificate management protocol 97 When reissue, renewal, suspension, or revocation of a subscriber's 98 certificate is requested, the signText function defined in WAP is 99 used to generate the request format. 101 2.1 Certificate reissuing request 103 2.1.1 Overview 105 Certificate reissuing request format is created when the subscriber 106 believes that the digital signature generation key is lost, damaged, 107 stolen, or leaked, and transmit it to the certification authority (or the 108 registration authority). 110 2.1.2 Configuration of certificate reissue request format 112 The subscriber MUST generate POP method, certificate reissue 113 request format including the public keys, and configure a request 114 format that can prevent Replay attack, message counterfeiting and 115 forgery, and ensures confidentiality, and deliver the certificate 116 reissue request format to a certification authority (or a registration 117 authority). 119 2.1.3 Structure of certificate reissue request format 121 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 122 Subscriber | | RA (or CA) 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 124 CR = SignedContent | CR | 125 | ----------> | 126 | | SignedContent = CR 127 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 129 M = type|PK_new|ID_new 130 N = Password 131 H(M,N) [See RFC2104] 132 SignedContent = signText(M|H(M,N), 1, 0, ��) [See Appendix B] 133 "type" : Type string value of management type (digital signature: 210) 134 PK_new: new digital signature verification key of subscriber 135 [See appendix D] 136 ID_new: new reference number of subscriber 137 Password: authorization code of subscriber 139 As the option of signText is set at 1, PK (public key) and ID 140 are extracted from M among signed messages. 142 RA(or CA) MUST verify SignedContent by means of PK (public 143 key). (POP verification process [RFC2510]) 145 RA (or CA) retrieves the Password corresponding to ID from its 146 database, and composes N. Then, RA (or CA) calculates H(M,N), 147 where the M is in the Subscriber's signed CR message. And RA 148 (or CA) compares calculated value with subscriber's hash value 149 which is in the Subscriber's signed CR message. (user 150 authentication) 152 2.2 Certificate renewal request 154 2.2.1Overview 156 The certificate update request is to configure and 157 create the certificate renewal request format before 158 the expiry date, and submit it to the certification authority 159 (or the registration authority). 161 2.2.2 Configuration of certificate renewal request format 163 Renewal can be done with or without key replacement. In these cases, 164 the update request format must be created and sent to the certification 165 authority (or the registration authority). 167 2.2.3 Structure of certificate update request format 168 o Case1. No key replacement 169 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 170 Subscriber | | RA (or CA) 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 172 | nonce | nonce generated 173 | <---------- | 174 CR = SignedContent | CR | 175 | ----------> | 176 | | SignedContent = CR 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 179 M = type|CN string in owner's DN 180 N = nonce(replay attack prevention) 181 SignedContent = signText(M|N, 5, 1, H(public key)) 183 "type" : Type string value of management type (digital signature: 310) 184 PK: digital signature verification key of subscriber 185 H(public key) : hash value for subscriber's existing public key 186 nonce : UTC time generated by server 188 As the option of signText is set at 5, the existing certificate must be 189 brought along with the PK of the existing certificate. 190 Verify SignedContent by means of PK(public key).(user 191 verification process) 193 Here, the CN string in subscriber's DN is an option, 194 and can have a null value. (including the vertical line ( | )). The "type" 195 string must be included. 197 o Case2. Key replacement 198 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 199 Subscriber | | RA (or CA) 200 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 201 | nonce | nonce generated 202 | <---------- | 203 CR = SignedContent | CR | 204 | ----------> | 205 | | SignedContent = CR 206 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 208 M = type|PK 209 Generate SignValue with nonce signed by SK_new distribution 210 N = nonce|SignValue 211 SignedContent = signText(M|N, 5, 1, H(public key)) 212 "type" : Type string value of management type (digital signature: 410) 213 PK: digital signature verification key of subscriber 214 PK_new : subscriber��s new digital signature verification key 215 SK_new : subscriber��s digital signature generation key 216 H(public key) : hash value for subscriber's existing public key 217 nonce : UTC time generated by server 219 As the option of signText is set at 5, the existing certificate must be 220 brought along with the PK of the existing certificate. 221 Verify SignedContent by means of PK(public key).(user 222 verification process) 223 N is verified by the signed message M (POP verification regarding 224 new public key) 226 2.3 Certificate suspension request 228 2.3.1 Overview 230 The suspension request format is created when the 231 subscriber suspects that his generation key has been lost, damaged, 232 stolen, or leaked. 234 2.3.2 Configuration of certificate suspension request format 236 The subscriber must configure the certificate suspension request 237 format capable of preventing user certification and replay attack, and 238 submit it to the certification authority (or the registration authority). 240 2.3.3 Structure of certificate suspension request format 242 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 243 Subscriber | | RA (or CA) 244 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 245 | nonce | nonce generated 246 | <---------- | 247 CR = SignedContent | CR | 248 | ----------> | 249 | | SignedContent = CR 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 252 M = type|CertificateHold 253 N = nonce(replay attack prevention) 254 SignedContent = signText(M|N, 5, 1, H(public key)) 255 "type" : Type string value of management type (digital signature: 510) 256 PK: digital signature verification key of subscriber 257 H(public key) : hash value for subscriber's digital signature 258 verification key 259 nonce : UTC time generated by server 261 As the option of signText is set at 5, the existing certificate must be 262 brought along with the PK of the existing certificate. 263 Verify SignedContent by means of PK(public key) (user verification 264 process). 265 The reason for suspension is checked through signed message M. 266 As the option of SignText is set at 5, the existing certificate is added 267 to the suspension list. 269 2.4 Certificate revocation request 271 2.4.1 Overview 273 When the subscriber applied for certificate revocation, or it is suspected 274 that the subscriber��s generation key is lost, damaged, stolen, or leaked, 275 the subscriber must create the revocation request format, and submit it 276 to the certification authority (or the registration authority). 278 2.4.2 Configuration of certificate revocation request format 280 If the subscriber��s generation key is lost or damaged, the subscriber 281 must visit the certification authority (or the registration authority) in person, 282 and apply for revocation. If revocation has been applied for because 283 it is suspected that the subscriber��s generation key was stolen or leaked, 284 the subscriber must create the revocation request format via online, and 285 submit it to certification authority (or the registration authority). 287 2.4.3 Structure of certificate revocation request format 289 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 290 Subscriber | | RA (or CA) 291 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 292 | nonce | nonce generated 293 | <---------- | 294 CR = SignedContent | CR | 295 | ----------> | 296 | | SignedContent = CR 297 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 298 M = type|ReasonCode 299 SignedContent = signText(M, 5, 1, H(public key)) 301 "type" : Type string value of management type (digital signature: 610) 302 PK: digital signature verification key of subscriber 303 H(public server) : hash value for subscriber's digital signature 304 verification key 305 nonce : UTC time generated by server 307 As the option of signText is set at 5, the existing certificate must be 308 brought along with the PK of the existing certificate. 309 Verify SignedContent by means of PK(public key) (user verification process). 310 The reason for revocation is checked through signed message M. 311 As the option of SignText is set at 5, the existing certificate is added 312 to the revocation list. 314 3. References 316 [WAP211] Forum Proposed Version 9-Mar-2000, WAP-211-X.509: 317 WAP Certificate and CRL Profile 319 [WAP217] WAP Forum Proposed Version 3-Mar-2000, 320 WAP-217-WPKI: Wireless Application Protocol Public Key 321 Infrastructure Definition 323 [WAPe2e] WAP Forum Approved Version 11-July-2000, WAPTM 324 Transport Layer E2E Security Document 326 [WAPscriptCrypto] WAP Forum Proposed Version 05-Nov-1999, 327 WMLScript Crypto Library 329 [WAP261] WAP Forum Approved Version 06-April-2001, Wireless 330 Transport Layer Security 332 [RFC2104] H. Krawczyk, M. Bellare,R. Canetti, "HMAC: 333 Keyed-Hashing for Message Authentication", February 1997. 335 [RFC1521] N. Borenstein, N. Freed, "MIME (Multipurpose Internet 336 Mail Extensions) Part One: Mechanisms for Specifying and 337 Describing the Format of Internet Message Bodies", September 338 1993. 340 [RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. 341 Adams, "X.509 Internet Public Key Infrastructure Online Certificate 342 Status Protocols", June 1999. 344 [RFC2510] C. Adams, S. Farrell, "Internet X.5.09 Public Key 345 Infrastructure Certificate Management Protocols", March 1999 347 [RFC2511] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet 348 X.5.09 Certificate Request Message Format", March 1999 350 [ITUTX509] ITU-T Recommendation X.509(1997), Information 351 technology - Open System Interconnection - The Directory : 352 Authentication Framework 354 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 355 Public Key Infrastructure Certificate and CRL Profile", January 1999 357 [PKCS10] RSA Laboratories, "PKCS#10, Certification Request 358 Syntax Format", 1999. 360 [PKCS12]RSA Laboratories, "PKCS#12, Personal Information 361 Exchange Standard", 1999. 363 4. Intellectual Property Rights 365 The IETF has been notified of intellectual property rights claimed in 366 regard to some or all of the specification contained in this 367 document. For more information consult the online list of claimed 368 rights (see http://www.ietf.org/ipr.html). 370 The IETF takes no position regarding the validity or scope of any 371 intellectual property or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; neither does it represent that it 375 has made any effort to identify any such rights. Information on the 376 IETF's procedures with respect to rights in standards-track and 377 standards-related documentation can be found in BCP-11. Copies 378 of claims of rights made available for publication and any 379 assurances of licenses to be made available, or the result of an 380 attempt made to obtain a general license or permission for the use 381 of such proprietary rights by implementors or users of this 382 specification can be obtained from the IETF Secretariat. 384 Appendix A. Definition of management type string, and encoding & 385 decoding rules 387 � Definition of management type string 389 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 390 Type| Encryption & digital signature | Digital signature | Encryption 391 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 392 Request | 100 110 120 393 Re-issuing | 200 210 220 394 Renewal | 300 310 320 395 Update (key) | 400 410 420 396 Suspension | 500 510 520 397 Revocation | 600 610 620 398 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 400 type = 3byte(string) & req = Base64 encoded(string) : POST mode 401 is used. 403 � Encoding & Decoding rules 405 - In this document, all binary data MUST comply with the base64 406 encoding rules. 407 - The vertical line (|) is used as the separator, but it will not be 408 used for hash message concatenation. 409 - The vertical line (|) will be excluded from the range of characters 410 that can be used as reference numbers (ID). 411 - The maximum length of the reference number is 10 characters, 412 and it is alphanumeric and case-sensitive. 413 - The maximum length of the authorization code is 30 characters, 414 and it is alphanumeric and case-sensitive. 415 - The minimum length of the authorization code varies depending 416 on the period. 418 +++++++++++++++++++++++++++ 419 Period Length 420 +++++++++++++++++++++++++++ 421 1 day 12 characters 422 3 days 13 characters 423 1 week 14 characters 424 10 days 14 characters 425 2 weeks 15 characters 426 1 month 16 characters 427 +++++++++++++++++++++++++++ 428 �� In case that ECDSA key is 20 bytes long, and the reference 429 number is 8 bytes long 431 Appendix B. SignText function [WAPscriptCrypto] 433 B.1 SignText configuration 435 signedString = Crypto.signText(StringToSign, options, 436 keyIdType, keyId) 438 B.2 Parameters 440 ��stringToSign = String 441 : contents of actual message 443 ��options = Integer 444 : OR operation of several optional values is possible. 445 +++++++++++++++++++++++++++++++++++++++++++++++++ 446 value description 447 +++++++++++++++++++++++++++++++++++++++++++++++++ 448 0x0001 INCLUDE_CONTENT: Information is transferred. 449 Return value includes StringToSign. 450 0x0002 INCLUDE_KEY_HASH: Return value includes 451 the public key hash value corresponding to the signature key. 452 0x0004 INCLUDE_CERTIFICATE: Return value includes 453 the certificate or the URL of the certificate. If the Browser cannot 454 obtain the certificate, �error:noCert" value must be returned. 455 +++++++++++++++++++++++++++++++++++++++++++++++++ 457 ��KeyIdType = Integer 459 ++++++++++++++++++++++++++++++++++++++++++++++++ 460 value description 461 ++++++++++++++++++++++++++++++++++++++++++++++++ 462 0 None:Used when Key Identifier is not used. 463 1 User_Key_HASH: User public key hash value is 464 offered to the next parameter (keyId). 465 2 TRUSTED_Key_HASH: The public key hash 466 value of the Trusted CA is offered to the next parameter (keyId). 467 ++++++++++++++++++++++++++++++++++++++++++++++++ 468 ��keyId = String 469 : Hash value defined in accordance with KeyIdType. For 470 instance, SHA-1 public key hash value is 20 bytes. 472 B.3 Return value 474 ��Return value = String or Invalid 475 : If the return value is without errors, it is the base-64 476 [RFC1521] encoding of SignedContent. 478 Appendix C. Response to certification request format 480 C.1 Success 482 � MIME Type : application/vnd.wap.cert-response 483 � Content : Base64-encoded CertResponse 485 enum { cert_info(0), cert(1), referral(2), (255) } CertRespType; 487 struct { 488 CharacterSet character_set; 489 opaque displayName <1 .. 2^8 - 1>; 490 } CertDisplayName; 492 struct { 493 opaque url <0 .. 128>; 494 } UrlPoint; 496 struct { 497 unit8 version; 498 CertRespType type; 499 select (type) { 500 case cert_info: 501 CertDisplayName display_name; 502 Identifier ca_domain; 503 UrlPoint url; 504 case cert: 505 CertDisplayName display_name; 506 Identifier ca_domain; 507 X509Certificate cert; 508 case referral: 510 UrlPoint url; 511 unit32 seconds_to_wait; 512 } 513 } CertResponse; 515 C.2 Fail 517 � MIME Type : text/plain 518 � Content : Error message of ascii text value 520 Appendix D. Structure of PK(Public Key) 522 enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ; 524 struct { 525 PublicKeyType publicKeyType; 526 select (publicKeyType) { 527 case ecdh : ECPublicKey ; 528 case ecdsa : ECPublicKey ; 529 case rsa : RSAPublicKey ; 530 } ; 531 } PublicKey ; 533 struct { 534 opaque url <0 .. 128>; 535 } UrlPoint; 537 struct { 538 opaque rsa_exponent<1..2^16-1> ; 539 opaque rsa_modulus<1..2^16-1> ; 540 } RSAPublicKey ; 542 enum { ECunNamed(0), ECNamed(1), implicitlyCA(2), (255) } 543 ECNameType; 545 struct { 546 ECNameType ecNameType; 547 select (ecNameType) { 548 case ECunNamed : 549 ECParameters ecParameters; 550 case ECNamed : 551 opaque oid<1..2^8-1> ; 552 case implicitlyCA : 553 struct { }; 554 } ; 556 opaque public_key_point<1..2^8-1> ; 558 } ECPublicKey ; 560 enum { ec_prime_p(1), ec_characteristic_two(2), (255) } ECFieldID; 562 enum { ec_basis_onb(1), ec_basis_trinomial(2), 563 ec_basis_pentanomial(3), ec_basis_polynomial(4) } ECBasisType; 565 struct { 566 opaque a <1..2^8-1>; 567 opaque b <1..2^8-1>; 568 opaque seed <0..2^8-1>; 569 } ECCurve; 571 struct { 572 ECFieldID field; 573 select (field) { 574 case ec_prime_p: opaque prime_p <1..2^8-1>; 575 case ec_characteristic_two: 576 uint16 m; 577 ECBasisType basis; 578 select (basis) { 579 case ec_basis_onb: 580 struct { }; 581 case ec_trinomial: 582 uint16 k; 583 case ec_pentanomial: 584 uint16 k1; 585 uint16 k2; 586 uint16 k3; 587 case ec_basis_polynomial: 588 opaque irreducible <1..2^8-1> 589 }; 590 }; 591 ECCurve curve; 592 ECPoint base; 593 opaque order <1..2^8-1>; 594 opaque cofactor <1..2^8-1>; 595 } ECParameters; 597 Appendix E. Author Addresses: 599 Jaeil Lee 600 78, Garak-dong, Songpa-Gu, Seoul, Korea, 138-803 601 Korea Information Security Agency 602 E-Mail: jilee@kisa.or.kr 604 Young Lee 605 Korea Information Security Agency 606 E-Mail: ylee@kisa.or.kr 608 Chanju Chung 609 Korea Information Security Agency 610 E-Mail: cjchung@kisa.or.kr 612 Jaeho Yoon 613 Korea Information Security Agency 614 E-Mail: jhyoon@kisa.or.kr