idnits 2.17.1 draft-ietf-cat-ecdh-spkm-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2025], [P1363], [ISO15946], [ECDSA], [X962], [X963]), 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 200: '... INTEGER OPTIONAL,...' RFC 2119 keyword, line 502: '... INTEGER OPTIONAL,...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (August 1999) is 9020 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-pkix-ipki-ecdsa-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO15946' -- Possible downref: Non-RFC (?) normative reference: ref. 'P1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'X962' -- Possible downref: Non-RFC (?) normative reference: ref. 'X963' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Zuccherato(Entrust Technologies) 2 CAT Working Group C. Adams(Entrust Technologies) 3 expires in six months August 1999 5 Using Elliptic Curve Diffie-Hellman in the SPKM GSS-API 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright (C) The Internet Society (1999). All Rights Reserved. 30 Abstract 32 Elliptic curve cryptography is rapidly gaining acceptance and is being 33 increasingly used in applications that are constrained in memory and 34 bandwidth. Efforts are underway to standardize the use of elliptic 35 curves for authentication [ECDSA], [X962] and key agreement [ISO15946], 36 [P1363], [X963]. However, none of these efforts describe the Elliptic 37 Curve Diffie-Hellman (ECDH) method in a form suitable for inclusion in 38 SPKM [RFC2025]. This document will define a new OID and 39 AlgorithmIdentifier which is suitable for use in SPKM and describe how 40 the ECDH algorithm is to be used in SPKM. 42 1. Introduction 44 The Simple Public-Key Mechanism (SPKM) is a GSS-API mechanism which 45 "provides authentication, key establishment, data integrity, and data 46 confidentiality in an on-line distributed application environment using 47 a public key infrastructure." The mandatory key establishment algorithm 48 in SPKM is RSA encryption as defined by the RSAEncryption OID. However, 49 any key establishment algorithm which can be specified by an 50 AlgorithmIdentifier may be used. 52 Elliptic curve cryptography uses the group of points defined on an 53 elliptic curve over a finite field to obtain variants of the 54 conventional DSA signature scheme and Diffie-Hellman key agreement 56 algorithm, for example. The security of these schemes is based on the 57 difficulty of the elliptic curve discrete logarithm problem. Unlike 58 cryptography which is based on the integer factorization problem or the 59 traditional discrete logarithm problem, no index calculus method is 60 known for solving the elliptic curve discrete logarithm problem. Thus, 61 elliptic curve cryptosystems can be used which provide similar security 62 to "conventional" public-key systems, but with a much smaller key size. 63 This is particularly useful in certain constrained devices. 65 Other efforts to standardize the use of elliptic curves for key 66 agreement exist. However, they do not provide an obvious way to include 67 their techniques within SPKM. The [P1363] and [ISO15946] drafts 68 describe the ECDH algorithm as it would be used in SPKM, but they do not 69 define OIDs and AlgorithmIdentifiers that SPKM requires in order to 70 specify the algorithm in a REQ-TOKEN, for example. The description of 71 the ECDH algorithm in this document will be consistent with the Elliptic 72 Curve Key Agreement Scheme, Diffie-Hellman version, where each party 73 contributes one key pair (ECKAS-DH1) using Elliptic Curve Secret Value 74 Derivation Primitive, Diffie-Hellman version (ECSVDP-DH) in [P1363] and 75 also with the Key agreement of Diffie-Hellman type in [ISO15946]. 77 The [X963] draft also describes the ECDH algorithm as it would be used 78 in SPKM, but requires that it be implemented in one of several schemes 79 that it describes and also mandates the use of particular key derivation 80 functions. SPKM, however, uses a different, incompatible, key 81 derivation function. The description of ECDH in this document will be 82 consistent with the Ephemeral Unified Model Scheme in [X963] except that 83 the SPKM key derivation function will be used. 85 Implementations conformant with this specification must also be 86 conformant with [RFC2025]. 88 2. Elliptic Curve Diffie-Hellman 90 This Section will describe the ECDH algorithm as it is to be used in 91 SPKM. Necessary elliptic curve background can be found in [X962]. 93 The required elliptic curve parameters will be specified in the K-ALG 94 AlgorithmIdentifier parameters. These parameters will include the curve 95 to be used, the underlying finite field and its representation, the 96 generating point (P), and the order of P (n). 98 Each party A will generate a random integer r_A in the range [1,n-1] and 99 compute the ECDH public key r_A*P. This public key will then be sent to 100 the other party in the SPKM session. 102 Upon receiving the public key r_B*P from the other party, each party 103 will then compute the shared secret point Z=r_A*(r_B*P). The point Z 104 will be used to create the context_key for use in the Subkey Derivation 105 Algorithm. 107 3. ECDH Public Keys 109 An ECDH public key, r_a*P, is a point on the elliptic curve. Elliptic 110 curve points are represented by the ASN.1 type: 112 ECPoint ::= OCTET STRING 114 The value of ECPoint shall be the octet string representation of an 115 elliptic curve point following the conversion routine in [X962, Section 116 4.3.6]. 118 Within SPKM ECDH keys are carried in the key-estb-req field of a REQ- 119 TOKEN, the key-estb-str field of a REP-TI-TOKEN and the key-estb-rep 120 field of a REP-IT-TOKEN. These fields are all BIT STRINGs. The ECDH 121 public key OCTET STRING is mapped to a BIT STRING as follows: the most 122 significant bit of the OCTET STRING becomes the most significant bit of 123 the BIT STRING, etc.; the least significant bit of the OCTET 124 STRING becomes the least significant bit of the BIT STRING. 126 4. Algorithm Identifier and Parameters 128 The negotiation of ECDH as a K-ALG in SPKM requires that an 129 AlgorithmIdentifer{{ECDHAlgorithm}} be specified in the key-estb-set 130 field of REQ-TOKEN and the key-estb-id field of REP-TI-TOKEN. The use 131 of the OID id-SPKM-ECDH and AlgorithmIdentifier{{ECDHAlgorithm}} as 132 described in this section implies the use of ECDH as described in this 133 document. 135 A reference to parameterized type AlgorithmIdentifier{} tightly binds a 136 set of algorithm object identifiers to their associated parameters 137 types. Type AlgorithmIdentifier{} is defined as: 139 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 140 Algorithm ALGORITHM.&id({IOSet}), 141 Parameters ALGORITHM.&Type({IOSet}{@algorithm}) 142 } 144 A single parameter in the reference of type AlgorithmIdentifier{}, the 145 information object set of class ALGORITHM, ECDHAlgorithm, specifies all 146 of the pairs of valid values of this type. This set contains only one 147 object ecdhspkmAlgorithm, as defined in this Standard. 149 ECDHAlgorithm ALGORITHM ::= { 150 ecdhspkmAlgorithm, 151 ... 152 } 154 ecdhspkmAlgorithm ALGORITHM ::= { 155 Parameters IDENTIFIED BY id-SPKM-ECDH 156 } 158 ALGORITHM ::= TYPE-IDENTIFIER 160 The object identifier id-SPKM-ECDH names the ECDH algorithm defined in 161 this Standard. It has the following value: 163 id-SPKM-ECDH OBJECT IDENTIFIER ::= 164 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 165 mechanisms(5) spkm(1) id-SPKM-ECDH(20) } 167 The public key Parameters are defined in this Standard as a choice of 169 two alternatives. This allows detailed specification of all required 170 values using choice ecParameters or the use of a namedCurve as an object 171 identifier substitute for a particular set of elliptic curve domain 172 parameters. 174 Parameters ::= CHOICE { 175 ecParameters ECParameters, 176 namedCurve OBJECT IDENTIFIER } 178 When parameters are specified by reference, the parameters field shall 179 contain the namedCurve choice, which is an object identifier. See 180 [X9.62,Section 6.4] and [X9.63] for OIDs that represent certain sets of 181 parameters defined by ANSI. ANSI and other standards bodies may define 182 other OIDs to represent other elliptic curve parameters which they may 183 recommend. Users are encouraged to consult relevant standards and 184 specifications to determine which OIDs (if any) they should use. 186 When the parameters are explicitly included, they shall be encoded in 187 the ASN.1 structure ECParameters: 189 ECParameters ::= SEQUENCE { 190 version INTEGER { ecpVer1(1) } (ecpVer1), 191 -- version is always 1 192 fieldID FieldID { {FieldTypes} }, 193 -- identifies the finite field over which the curve is defined 194 curve Curve, 195 -- coefficients a and b of the elliptic curve 196 base ECPoint, 197 -- specifies the base point P on the elliptic curve 198 order INTEGER, 199 -- the order n of the base point 200 cofactor INTEGER OPTIONAL, 201 ... 202 } 204 FieldElement ::= OCTET STRING 206 The value of FieldElement shall be the octet string representation of a 207 field element following the conversion routine in [X9.62,Section 4.3.3] 209 Curve ::= SEQUENCE { 210 a FieldElement, 211 b FieldElement, 212 seed BIT STRING OPTIONAL} 214 The components of type ECParameters have the following meanings: 216 * version specifies the version number of the elliptic curve parameters. 217 It shall have the value 1 for this version of the Standard. The notation 218 above creates an INTEGER named ecpVer1 and gives it a value of one. It 219 is used to constrain version to a single value. 221 * fieldID identifies the finite field over which the elliptic curve is 222 defined. Finite fields are represented by values of the parameterized 223 type FieldID, constrained to the values of the objects defined in the 224 information object set FieldTypes. Additional detail regarding fieldID 226 is provided below. 228 * curve specifies the coefficients a and b of the elliptic curve E. 229 Each coefficient shall be represented as a value of type FieldElement, 230 an OCTET STRING. seed is an optional parameter used to derive the 231 coefficients of a randomly generated elliptic curve. 233 * base specifies the base point P on the elliptic curve. The base point 234 shall be represented as a value of type ECPoint, an OCTET STRING. 236 * order specifies the order n of the base point. 238 * cofactor is the integer h = #E(Fq)/n. Note: This optional parameter is 239 not used in this version of ECDH, except in parameter validation. 240 Parameter validation is not required by this specification. 242 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 243 fieldType FIELD-ID.&id({IOSet}), 244 parameters FIELD-ID.&Type({IOSet}{@fieldType}) 245 OPTIONAL} 247 FieldTypes FIELD-ID ::= { 248 { Prime-p IDENTIFIED BY prime-field } | 249 { Characteristic-two IDENTIFIED BY characteristic-two-field }, 250 ... 251 } 253 FIELD-ID ::= TYPE-IDENTIFIER 255 FieldID is a parameterized type composed of two components, fieldType 256 and parameters. These components are specified by the fields &id and 257 &Type, which form a template for defining sets of information objects, 258 instances of the class FIELD-ID. This class is based on the useful 259 information object class TYPE-IDENTIFIER, described in X.681 Annex A. In 260 an instance of FieldID, "fieldType" will contain an object identifier 261 value that uniquely identifies the type contained in "parameters". The 262 effect of referencing "fieldType" in both components of the fieldID 263 sequence is to tightly bind the object identifier and its type. 265 The information object set FieldTypes is used as the single parameter in 266 a reference to type FieldID. FieldTypes contains two objects followed by 267 the extension marker ("..."). Each object, which represents a finite 268 field, contains a unique object identifier and its associated type. The 269 values of these objects define all of the valid values that may appear 270 in an instance of fieldID. The extension marker allows backward 271 compatibility with future versions of this standard which may define 272 objects to represent additional kinds of finite fields. 274 The object identifier id-fieldType represents the root of a tree 275 containing the object identifiers of each field type. It has the 276 following value: 278 ansi-X9-62 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 10045 } 279 id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } 281 The object identifiers prime-field and characteristic-two-field name the 283 two kinds of fields defined in this Standard. They have the following 284 values: 286 prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } 288 characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } 290 Prime-p ::= INTEGER -- Field size p (p in bits) 292 Characteristic-two ::= SEQUENCE { 293 m INTEGER, 294 -- Field size 2^m (m in bits) 295 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 296 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})} 298 BasisTypes CHARACTERISTIC-TWO::= { 299 { NULL IDENTIFIED BY gnBasis } | 300 { Trinomial IDENTIFIED BY tpBasis } | 301 { Pentanomial IDENTIFIED BY ppBasis }, 302 ... 303 } 305 Trinomial ::= INTEGER 307 Pentanomial ::= SEQUENCE { 308 k1 INTEGER, 309 k2 INTEGER, 310 k3 INTEGER } 312 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 314 The object identifier id-characteristic-two-basis represents the root of 315 a tree containing the object identifiers for each type of basis for the 316 characteristic-two finite fields. It has the following value: 318 id-characteristic-two-basis OBJECT IDENTIFIER ::= { 319 characteristic-two-field basisType(1) } 321 The object identifiers gnBasis, tpBasis and ppBasis name the three kinds 322 of basis for characteristic-two finite fields defined by [X9.62]. They 323 have the following values: 325 gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } 326 tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } 327 ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 } 329 5. Computation of the Context Key 331 After computation of the shared secret point Z (as described in Section 332 2) each party must compute a context_key, which is a bit string, for 333 input to the Subkey Derivation Algorithm. 335 The secret value Z is an elliptic curve point and thus consists of an 336 ordered pair of field elements (x,y). To obtain the context_key first 337 apply the conversion routine in [X962, Section 4.3.3] to the field 339 element x to obtain an octet string. The octet string can be converted 340 to a bit string as follows: the most significant bit of the octet 341 string becomes the most significant bit of the bit string, etc.; the 342 least significant bit of the octet string becomes the least significant 343 bit of the bit string. 345 6. Security Considerations 347 The random number r_A which is used to compute the ECDH public key 348 should be generated by a quality random number generator and be unique 349 for each session. The use of predictable random numbers voids all 350 security provided by ECDH. 352 It is recommended that only elliptic curves whose base point, P, has 353 order greater than 2^160 be used. It is generally accepted that curves 354 that do not satisfy this condition are not suitable for cryptographic 355 use. Also note that some curves are less secure than others. See 356 [X962,Section H.1] for a discussion of the difficulty of solving the 357 elliptic curve discrete logarithm problem. 359 It is recommended that before accepting any session using ECDH, both 360 parties should validate the proposed parameters. A method for 361 validating parameters can be found in [X9.62,Section 5.1]. It may also 362 be desirable to generate the elliptic curve at random using a method 363 that can be verified by others. One such method is described in [X962, 364 Section A.3.3]. However, there are no known attacks against curves not 365 generated in this way. 367 Since the key establishment in SPKM is always protected for integrity 368 third party attackers cannot alter the exchanged public keys. 369 Therefore, the only entity capable of mounting a "small-subgroup" type 370 attack [smallsubgroup] on ECDH key agreement in SPKM is the other 371 legitimate entity in the key establishment. However, this entity 372 already has access to all data being passed through the session. Thus, 373 as long as fresh keys are generated for each session, protection from 374 "small-subgroup" attacks using public key validation or any other method 375 is not required. 377 7. Intellectual Property Rights 379 The IETF takes no position regarding the validity or scope of any 380 intellectual property or other rights that might be claimed to per- 381 tain to the implementation or use of the technology described in this 382 document or the extent to which any license under such rights might 383 or might not be available; neither does it represent that it has made 384 any effort to identify any such rights. Information on the IETF's 385 procedures with respect to rights in standards-track and standards- 386 related documentation can be found in BCP-11. Copies of claims of 387 rights made available for publication and any assurances of licenses 388 to be made available, or the result of an attempt made to obtain a 389 general license or permission for the use of such proprietary rights 390 by implementors or users of this specification can be obtained from 391 the IETF Secretariat. 393 The IETF invites any interested party to bring to its attention any 394 copyrights, patents or patent applications, or other proprietary 396 rights which may cover technology that may be required to practice 397 this standard. Please address the information to the IETF Executive 398 Director. 400 8. References 402 [ECDSA] L. Bassham, D. Johnson, W. Polk, "Representation of Elliptic 403 Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in 404 Internet X.509 Public Key Infrastructure Certificates", draft-ietf-pkix- 405 ipki-ecdsa-0X.txt, work in progress, 1999. 407 [ISO15946] ISO/IEC CD 15946-3, "Information Technology - Security 408 Techniques - Cryptographic Techniques Based on Elliptic Curves - Part 3: 409 Key Establishment", Committee Draft, April 24, 1999. 411 [P1363] IEEE P1363/D11, "Standard Specifications for Public Key 412 Cryptography", Draft 11, July 29, 1999. 414 [RFC2025] C. Adams, "The Simple Public-Key GSS-API Mechanism (SPKM)", 415 RFC 2025. 417 [smallsubgroup] R. Zuccherato, "Methods for Avoiding the "Small- 418 Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for 419 S/MIME", draft-ietf-smime-small-subgroup-0X.txt, work in progress, 1999. 421 [X962] ANSI X9.62-1999, "Public Key Cryptography For The Financial 422 Service Industry: The Elliptic Curve Digital Signature Algorithm 423 (ECDSA)". 425 [X963] ANSI X9.63-199x, "Public Key Cryptography For The Financial 426 Services Industry: Key Agreement and Key Transport Using Elliptic Curve 427 Cryptography", Working Draft, April 20, 1999. 429 9. Author's Address 431 Robert Zuccherato 432 Entrust Technologies 433 750 Heron Road 434 Ottawa, Ontario 435 Canada K1V 1A7 436 robert.zuccherato@entrust.com 438 Carlisle Adams 439 Entrust Technologies 440 750 Heron Road 441 Ottawa, Ontario 442 Canada K1V 1A7 443 cadams@entrust.com 445 Appendix A. ASN.1 Module Definition 447 SpkmECDH {iso(1) identified-organization(3) dod(6) internet(1) 448 security(5) mechanisms(5) spkm(1) spkmECDH(20) } 450 DEFINITIONS IMPLICIT TAGS ::= 451 BEGIN 453 --EXPORTS ALL 455 IMPORTS 456 ECParameters 457 FROM ANSI-X9-62 { iso(1) member-body(2) us(840) 10045 module(4) 1 } 459 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 460 Algorithm ALGORITHM.&id({IOSet}), 461 Parameters ALGORITHM.&Type({IOSet}{@algorithm}) 462 } 464 ECDHPKAlgorithm ALGORITHM ::= { 465 ecdhspkmAlgorithm, 466 ... 467 } 469 ecdhspkmAlgorithm ALGORITHM ::= { 470 Parameters IDENTIFIED BY id-SPKM-ECDH 471 } 473 ALGORITHM ::= TYPE-IDENTIFIER 475 id-SPKM-ECDH OBJECT IDENTIFIER ::= 476 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 477 mechanisms(5) spkm(1) id-SPKM-ECDH(20) } 479 Parameters ::= CHOICE { 480 ecParameters ECParameters, 481 namedCurve OBJECT IDENTIFIER } 483 END 485 Appendix B. Imported Types 487 This appendix contains (for completeness) the relevant ASN.1 types 488 imported from ANSI-X9-62 ([X962] and [ECDSA]). 490 ECParameters ::= SEQUENCE { 491 version INTEGER { ecpVer1(1) } (ecpVer1), 492 -- version is always 1 493 fieldID FieldID { {FieldTypes} }, 494 -- identifies the finite field over which the curve is defined 495 curve Curve, 496 -- coefficients a and b of the elliptic curve 497 base ECPoint, 498 -- specifies the base point P on the elliptic curve 500 order INTEGER, 501 -- the order n of the base point 502 cofactor INTEGER OPTIONAL, 503 ... 504 } 506 FieldElement ::= OCTET STRING 508 ECPoint ::= OCTET STRING 510 Curve ::= SEQUENCE { 511 a FieldElement, 512 b FieldElement, 513 seed BIT STRING OPTIONAL} 515 FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 516 fieldType FIELD-ID.&id({IOSet}), 517 parameters FIELD-ID.&Type({IOSet}{@fieldType}) 518 OPTIONAL} 520 FieldTypes FIELD-ID ::= { 521 { Prime-p IDENTIFIED BY prime-field } | 522 { Characteristic-two IDENTIFIED BY characteristic-two-field }, 523 ... 524 } 526 FIELD-ID ::= TYPE-IDENTIFIER 528 ansi-X9-62 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 10045 } 529 id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } 531 prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } 533 characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } 535 Prime-p ::= INTEGER -- Field size p (p in bits) 537 Characteristic-two ::= SEQUENCE { 538 m INTEGER, 539 -- Field size 2^m (m in bits) 540 basis CHARACTERISTIC-TWO.&id({BasisTypes}), 541 parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})} 543 BasisTypes CHARACTERISTIC-TWO::= { 544 { NULL IDENTIFIED BY gnBasis } | 545 { Trinomial IDENTIFIED BY tpBasis } | 546 { Pentanomial IDENTIFIED BY ppBasis }, 547 ... 548 } 550 Trinomial ::= INTEGER 552 Pentanomial ::= SEQUENCE { 553 k1 INTEGER, 554 k2 INTEGER, 556 k3 INTEGER } 558 CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 560 id-characteristic-two-basis OBJECT IDENTIFIER ::= { 561 characteristic-two-field basisType(1) } 563 gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } 564 tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } 565 ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 } 567 Appendix C. Full Copyright Statement 569 Copyright (C) The Internet Society (date). All Rights Reserved. 570 This document and translations of it may be copied and furnished to 571 others, and derivative works that comment on or otherwise explain it 572 or assist in its implementation may be prepared, copied, published 573 and distributed, in whole or in part, without restriction of any 574 kind, provided that the above copyright notice and this paragraph are 575 included on all such copies and derivative works. In addition, the 576 ASN.1 modules presented in Appendices A and B may be used in whole or 577 in part without inclusion of the copyright notice. However, this 578 document itself may not be modified in any way, such as by removing 579 the copyright notice or references to the Internet Society or other 580 Internet organizations, except as needed for the purpose of develop- 581 ing Internet standards in which case the procedures for copyrights 582 defined in the Internet Standards process shall be followed, or as 583 required to translate it into languages other than English. 585 The limited permissions granted above are perpetual and will not be 586 revoked by the Internet Society or its successors or assigns. This 587 document and the information contained herein is provided on an "AS 588 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 589 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 590 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 591 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 592 OR FITNESS FOR A PARTICULAR PURPOSE.