idnits 2.17.1 draft-ietf-pkix-rsa-pkalgs-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (November 2003) is 7467 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) == Missing Reference: 'SHA-224' is mentioned on line 212, but not defined -- Looks like a reference, but probably isn't: '0' on line 859 -- Looks like a reference, but probably isn't: '1' on line 861 -- Looks like a reference, but probably isn't: '2' on line 863 -- Looks like a reference, but probably isn't: '3' on line 851 == Unused Reference: 'SHA224' is defined on line 888, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2' == Outdated reference: A later version (-01) exists of draft-ietf-pkix-sha224-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-sha224 (ref. 'SHA224') -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group J. Schaad (Soaring Hawk Consulting) 2 Internet Draft B. Kaliski (RSA Laboratories) 3 R. Housley (Vigil Security) 4 expires May 2004 November 2003 6 Additional Algorithms and Identifiers for RSA Cryptography 7 for use in the Internet X.509 Public Key Infrastructure 8 Certificate and Certificate Revocation List (CRL) Profile 9 11 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Drafts Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document supplements RFC 3279. It describes the conventions 32 for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 33 transport algorithm and additional one-way hash functions with the 34 PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public 35 Key Infrastructure (PKI). Encoding formats, algorithm identifiers, 36 and parameter formats are specified. 38 Table of Contents 40 1 Introduction.......................................................2 41 1.1 Terminology....................................................2 42 1.2 RSA Public Keys................................................2 43 2 Common Functions...................................................5 44 2.1 One-way Hash Functions.........................................5 45 2.2 Mask Generation Functions......................................6 46 3 RSASSA-PSS Signature Algorithm.....................................7 47 3.1 RSASSA-PSS Public Keys.........................................7 48 3.2 RSASSA-PSS Signature Values....................................9 49 3.3 RSASSA-PSS Signature Parameter Validation......................9 50 4 RSAES-OAEP Key Transport Algorithm................................10 51 4.1 RSAES-OAEP Public Keys........................................10 52 5 PKCS #1 Version 1.5 Signature Algorithm...........................12 53 6 ASN.1 Module......................................................13 54 7 References........................................................18 55 7.1 Normative References..........................................18 56 7.2 Informative References........................................19 57 8 Security Considerations...........................................19 58 10 Author Addresses.................................................21 59 11 Full Copyright Statement.........................................21 61 1 Introduction 63 This document supplements RFC 3279 [PKALGS]. This document 64 describes the conventions for using the RSASSA-PSS signature 65 algorithm and the RSAES-OAEP key transport algorithm in the Internet 66 X.509 Public Key Infrastructure (PKI) [PROFILE]. Both of these RSA- 67 based algorithms are specified in [P1v2.1]. The algorithm 68 identifiers and associated parameters for subject public keys that 69 employ either of these algorithms are specified, and the encoding 70 format for RSASSA-PSS signatures is specified. Also, the algorithm 71 identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 72 one-way hash functions with the PKCS #1 version 1.5 signature 73 algorithm [P1v1.5] are specified. 75 This specification supplements RFC 3280 [PROFILE], which profiles 76 the X.509 Certificates and Certificate Revocation Lists (CRLs) for 77 use in the Internet. This specification extends the list of 78 algorithms discussed in RFC 3279 [PKALGS]. The X.509 Certificate 79 and CRL definitions use ASN.1 [X.208-88], the Basic Encoding Rules 80 (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509- 81 88]. 83 This specification defines the contents of the signatureAlgorithm, 84 signatureValue, signature, and subjectPublicKeyInfo fields within 85 Internet X.509 certificates and CRLs. For each algorithm, the 86 appropriate alternatives for the keyUsage extension are provided. 88 1.1 Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [STDWORDS]. 94 1.2 RSA Public Keys 96 RFC 3280 [PROFILE] specifies the profile for using X.509 97 Certificates in Internet applications. When a RSA public key will 98 be used for RSASSA-PSS digital signatures or RSAES-OAEP key 99 transport, the conventions specified in this section augment RFC 100 3280. 102 Traditionally, the rsaEncryption object identifier is used to 103 identify RSA public keys. However, to implement all of the 104 recommendations described in the Security Considerations section of 105 this document (see section 8), the certificate user needs to be able 106 to determine the form of digital signature or key transport that the 107 RSA private key owner associates with the public key. 109 The rsaEncryption object identifier continues to identify the 110 subject public key when the RSA private key owner does not wish to 111 limit the use of the public key exclusively to either RSASSA-PSS or 112 RSAES-OAEP. In this case, the rsaEncryption object identifier MUST 113 be used in the algorithm field within the subject public key 114 information, and the parameters field MUST contain NULL. 116 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 118 Further discussion of the conventions associated with use of the 119 rsaEncryption object identifier can be found in RFC 3279 (see 120 [PKALGS], section 2.3.1). 122 When the RSA private key owner wishes to limit the use of the public 123 key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object 124 identifier MUST be used in the algorithm field within the subject 125 public key information, and, if present, the parameters field MUST 126 contain RSASSA-PSS-params. The id-RSASSA-PSS object identifier 127 value and the RSASSA-PSS-params syntax are fully described in 128 section 3 of this document. 130 When the RSA private key owner wishes to limit the use of the public 131 key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object 132 identifier MUST be used in the algorithm field within the subject 133 public key information, and, if present, the parameters field MUST 134 contain RSAES-OAEP-params. The id-RSAES-OAEP object identifier 135 value and the RSAES-OAEP-params syntax are fully described in 136 section 4 of this document. 138 Note: It is not possible to restrict the use of a key to only just 139 two of the algorithms (i.e. RSASSA-PSS and RSAES-OAEP) in this 140 document. 142 Regardless of the object identifier used, the RSA public key is 143 encoded in the same manner in the subject public key information. 144 The RSA public key MUST be encoded using the type RSAPublicKey type: 146 RSAPublicKey ::= SEQUENCE { 147 modulus INTEGER, -- n 148 publicExponent INTEGER } -- e 149 Here, the modulus is the modulus n, and publicExponent is the public 150 exponent e. The DER encoded RSAPublicKey is carried in the 151 subjectPublicKey BIT STRING within the subject public key 152 information. 154 The intended application for the key MAY be indicated in the key 155 usage certificate extension (see [PROFILE], section 4.2.1.3). 157 If the keyUsage extension is present in an end entity certificate 158 that conveys an RSA public key with the id-RSASSA-PSS object 159 identifier, then the key usage extension MUST contain one or both of 160 the following values: 162 nonRepudiation; and 163 digitalSignature. 165 If the keyUsage extension is present in a certification authority 166 certificate that conveys an RSA public key with the id-RSASSA-PSS 167 object identifier, then the key usage extension MUST contain one or 168 more of the following values: 170 nonRepudiation; 171 digitalSignature; 172 keyCertSign; and 173 cRLSign. 175 When a certificate that conveys an RSA public key with the id- 176 RSASSA-PSS object identifier, the certificate user MUST only use the 177 certified RSA public key for RSASSA-PSS operations, and, if RSASSA- 178 PSS-params is present, the certificate user MUST perform those 179 operations using the one-way hash function, mask generation 180 function, and trailer field identified in the subject public key 181 algorithm identifier parameters within the certificate. 183 If the keyUsage extension is present in a certificate that conveys 184 an RSA public key with the id-RSAES-OAEP object identifier, then the 185 key usage extension MUST contain only the following values: 187 keyEncipherment; and 188 dataEncipherment. 190 However, both keyEncipherment and dataEncipherment SHOULD NOT be 191 present. 193 When a certificate that conveys an RSA public key with the id-RSAES- 194 OAEP object identifier, the certificate user MUST only use the 195 certified RSA public key for RSAES-OAEP operations, and, if RSAES- 196 OAEP-params is present, the certificate user MUST perform those 197 operations using the one-way hash function and mask generation 198 function identified in the subject public key algorithm identifier 199 parameters within the certificate. 201 2 Common Functions 203 The RSASSA-PSS signature algorithm and the RSAES-OAEP key transport 204 algorithm make use of one-way hash functions and mask generation 205 functions. 207 2.1 One-way Hash Functions 209 PKCS #1 version 2.1 [P1v2.1] supports four one-way hash functions 210 for use with the RSASSA-PSS signature algorithm and the RSAES-OAEP 211 key transport algorithm: SHA-1, SHA-256, SHA-384, and SHA-512 212 [SHA2]. This document adds additional support for SHA-224 [SHA-224] 213 with both the RSASSA-PSS and the RSAES-OAEP algorithms. While 214 support for additional one-way hash functions could be added in the 215 future, no other one-way hash functions are supported by this 216 specification. 218 These one-way hash functions are identified by the following object 219 identifiers: 221 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 222 identified-organization(3) oiw(14) 223 secsig(3) algorithms(2) 26 } 224 id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) 225 country(16) us(840) organization(1) gov(101) 226 csor(3) nistalgorithm(4) hashalgs(2) 4 } 227 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 228 country(16) us(840) organization(1) gov(101) 229 csor(3) nistalgorithm(4) hashalgs(2) 1 } 230 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 231 country(16) us(840) organization(1) gov(101) 232 csor(3) nistalgorithm(4) hashalgs(2) 2 } 233 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 234 country(16) us(840) organization(1) gov(101) 235 csor(3) nistalgorithm(4) hashalgs(2) 3 } 237 There are two possible encodings for the AlgorithmIdentifier 238 parameters field associated with these object identifiers. The two 239 alternatives arise from the fact that when the 1988 syntax for 240 AlgorithmIdentifier was translated into the 1997 syntax the OPTIONAL 241 associated with the algorithm identifier parameters got lost. Later 242 the OPTIONAL was recovered via a defect report, but by then many 243 people thought that algorithm parameters were mandatory. Because of 244 this history some implementations encode parameters as a NULL 245 element and others omit them entirely. The correct encoding is to 246 omit the parameters field; however, at the time that RSASSA-PSS and 247 RSAES-OAEP were defined it was done using the NULL parameters rather 248 than absent parameters. 250 All implementations MUST accept both NULL and absent parameters as 251 legal and equivalent encodings. 253 To be clear, the following algorithm identifiers are used when a 254 NULL parameter MUST be present: 256 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 258 sha224Identifier AlgorithmIdentifier ::= { id-sha256, NULL } 259 sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL } 260 sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL } 261 sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL } 263 2.2 Mask Generation Functions 265 One mask generation function is used with the RSASSA-PSS signature 266 algorithm and the RSAES-OAEP key transport algorithm: MGF1 [P1v2.1]. 268 No other mask generation functions are supported by this 269 specification. 271 MGF1 is identified by the following object identifier: 273 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 275 The parameters field associated with id-mgf1 MUST have a 276 hashAlgorithm value, which identifies the hash function being used 277 with MGF1. This value MUST be sha1Identifier, sha224Identifier, 278 sha256Identifier, sha384Identifier, or sha512Identifier, as 279 specified in section 2.1. Implementations MUST support the default 280 value, sha1Identifier, and implementations MAY support the other 281 four values. 283 The following algorithm identifiers have been assigned for each of 284 these alternatives: 286 mgf1SHA1Identifier AlgorithmIdentifier ::= 287 { id-mgf1, sha1Identifier } 288 mgf1SHA224Identifier AlgorithmIdentifier ::= 289 { id-mgf1, sha224Identifier } 290 mgf1SHA256Identifier AlgorithmIdentifier ::= 291 { id-mgf1, sha256Identifier } 292 mgf1SHA384Identifier AlgorithmIdentifier ::= 293 { id-mgf1, sha384Identifier } 294 mgf1SHA512Identifier AlgorithmIdentifier ::= 295 { id-mgf1, sha512Identifier } 296 3 RSASSA-PSS Signature Algorithm 298 This section describes the conventions for using the RSASSA-PSS 299 signature algorithm with the Internet X.509 certificate and CRL 300 profile [PROFILE]. The RSASSA-PSS signature algorithm is specified 301 in PKCS #1 version 2.1 [P1v2.1]. The five one-way hash functions 302 discussed in section 2.1 and the one mask generation function 303 discussed in section 2.2 can be used with RSASSA-PSS. 305 CAs that issue certificates with the id-RSASSA-PSS algorithm 306 identifier SHOULD require that the parameters be present in the 307 publicKeyAlgorithms field if the cA boolean flag is set in the basic 308 constraints extension. CAs MAY require that the parameters be 309 present in the publicKeyAlgorithms field for end-entity 310 certificates. 312 CAs that use the RSASSA-PSS algorithm for signing certificates, 313 SHOULD have RSASSA-PSS-params the parameters present in their own 314 certificates. CAs that use the RSASSA-PSS algorithm for signing, 315 certificates and CRLs MUST include RSASSA-PSS-params the parameters 316 in the signature algorithm field of the TBSCertificate and 317 TBSCertList structures. 319 Entities that validate RSASSA-PSS signatures MUST have support for 320 SHA-1. They MAY also support the other hashing algorithms in 321 section 2.1. 323 The data to be signed (e.g., the one-way hash function output value) 324 is formatted for the signature algorithm to be used. Then, a 325 private key operation (e.g., RSA encryption) is performed to 326 generate the signature value. This signature value is then ASN.1 327 encoded as a BIT STRING and included in the Certificate or 328 CertificateList in the signature field. Section 3.2 specifies the 329 format of RSASSA-PSS signature values. 331 3.1 RSASSA-PSS Public Keys 333 When RSASSA-PSS is used in an AlgorithmIdentifier,the parameters 334 MUST employ the RSASSA-PSS-params syntax. The parameters may be 335 either absent or present when used as subject public key 336 information. The parameters MUST be present when used in the 337 algorithm identifier associated with for a signature value. 339 When signing, it is RECOMMENDED that, except for saltLength, the 340 parameters remain fixed for all usages of a given RSA key pair. 342 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 344 RSASSA-PSS-params ::= SEQUENCE { 345 hashAlgorithm [0] HashAlgorithm DEFAULT 346 sha1Identifier, 347 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT 348 mgf1SHA1Identifier, 349 saltLength [2] INTEGER DEFAULT 20, 350 trailerField [3] INTEGER DEFAULT 1 } 352 The fields of type RSASSA-PSS-params have the following meanings: 354 hashAlgorithm 356 The hashAlgorithm field identifies the hash function. It MUST 357 be one of the algorithm identifiers listed in section 2.1, and 358 the default hash function is SHA-1. Implementations MUST 359 support SHA-1, and implementations MAY support other one-way 360 hash functions listed in section 2.1. Implementations that 361 perform signature generation MUST omit the hashAlgorithm field 362 when SHA-1 is used, indicating that the default algorithm was 363 used. Implementations that perform signature validation MUST 364 recognize both the id-sha1 object identifier and an absent 365 hashAlgorithm field as an indication that SHA-1 was used. 367 maskGenAlgorithm 369 The maskGenAlgorithm field identifies the mask generation 370 function. The default mask generation function is MGF1 with 371 SHA-1. For MGF1, it is strongly RECOMMENDED that the 372 underlying hash function be the same as the one identified by 373 hashAlgorithm. Implementations MUST support MGF1. MGF1 374 requires a one-way hash function, and it is identified in the 375 parameters field of the MGF1 algorithm identifier. 376 Implementations MUST support SHA-1, and implementations MAY 377 support other one-way hash functions listed in section 2.1. 378 The MGF1 algorithm identifier is comprised of the id-mgf1 379 object identifier and a parameter that contains the algorithm 380 identifier of the one-way hash function employed with MGF1. 381 The SHA-1 algorithm identifier is comprised of the id-sha1 382 object identifier and an (optional) parameter of NULL. 383 Implementations that perform signature generation MUST omit 384 the maskGenAlgorithm field when MGF1 with SHA-1 is used, 385 indicating that the default algorithm was used. 387 Although mfg1SHA1Identifier is defined as the default value 388 for this field, implementations MUST accept both the default 389 value encoding (i.e. an absent field) and mfg1SHA1Identifier 390 to be explicitly present in the encoding. 392 saltLength 394 The saltLength field is the octet length of the salt. For a 395 given hashAlgorithm, the minimum value of saltLength is the 396 number of octets in the hash value. Unlike the other fields 397 of type RSASSA-PSS-params, saltLength does not need to be 398 fixed for a given RSA key pair; a different value could be 399 used for each RSASSA-PSS signature generated. 401 trailerField 403 The trailerField field is an integer. It provides 404 compatibility with the draft IEEE P1363a [P1363a]. The value 405 MUST be 1, which represents the trailer field with hexadecimal 406 value 0xBC. Other trailer fields, including the trailer field 407 composed of HashID concatenated with 0xCC that is specified in 408 IEEE P1363a, are not supported. Implementations that perform 409 signature generation MUST omit the trailerField field, 410 indicating that the default trailer field value was used. 411 Implementations that perform signature validation MUST 412 recognize both a present trailerField field with value 1 and 413 an absent trailerField field. 415 If the default values of the hashAlgorithm, maskGenAlgorithm, and 416 trailerField fields of RSASSA-PSS-params are used, then the 417 algorithm identifier will have the following value: 419 rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= { 420 id-RSASSA-PSS, rSASSA-PSS-Default-Params } 422 rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= { 423 sha1Identifier, mgf1SHA1Identifier, 20, 1} 425 3.2 RSASSA-PSS Signature Values 427 The output of the RSASSA-PSS signature algorithm is an octet string, 428 which has the same length in octets as the RSA modulus n. 430 Signature values in CMS [CMS] are represented as octet strings, and 431 the output is used directly. However, signature values in 432 certificates and CRLs [PROFILE] are represented as bit strings, and 433 conversion is needed. 435 To convert a signature value to a bit string, the most significant 436 bit of the first octet of the signature value SHALL become the first 437 bit of the bit string, and so on through the least significant bit 438 of the last octet of the signature value, which SHALL become the 439 last bit of the bit string. 441 3.3 RSASSA-PSS Signature Parameter Validation 443 Three possible parameter validation scenarios exist for RSASSA-PSS 444 signature values. 446 1. The key is identified by the rsaEncryption algorithm identifier. 447 In this case no parameter validation is needed. 449 2. The key is identified by the id-RSASSA-PSS signature algorithm 450 identifier, but the parameters field is absent. In this case no 451 parameter validation is needed. 453 3. The key is identified by the id-RSASSA-PSS signature algorithm 454 identifier and the parameters are present. In this case all 455 parameters in the signature structure algorithm identifier MUST 456 match the parameters in the key structure algorithm identifier 457 except the saltLength field. The saltLength field in the signature 458 parameters MUST be greater or equal to that in the key parameters 459 field. 461 4 RSAES-OAEP Key Transport Algorithm 463 This section describes the conventions for using the RSAES-OAEP key 464 transport algorithm with the Internet X.509 certificate and CRL 465 profile [PROFILE]. RSAES-OAEP is specified in PKCS #1 version 2.1 466 [P1v2.1]. The five one-way hash functions discussed in section 2.1 467 and the one mask generation function discussed in section 2.2 can be 468 used with RSAES-OAEP. Conforming CAs and applications MUST support 469 RSAES-OAEP key transport algorithm using SHA-1. The other three 470 one-way hash functions MAY also be supported. 472 CAs that issue certificates with the id-RSAES-OAEP algorithm 473 identifier SHOULD require that the parameters be present in the 474 publicKeyAlgorithms field for all certificates. 475 Entities that use a certificate with a publicKeyAlgorithm value of 476 id-RSA-OAEP where the parameters are absent SHOULD use the default 477 set of parameters for RSAES-OAEP-params. Entities that use a 478 certificate with a publicKeyAlgorithm value of rsaEncryption SHOULD 479 use the default set of parameters for RSAES-OAEP-params 481 4.1 RSAES-OAEP Public Keys 483 When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters 484 MUST employ the RSAES-OAEP-params syntax. The parameters may be 485 either absent or present when used as subject public key 486 information. The parameters MUST be present when used in the 487 algorithm identifier associated with an encryption value. 489 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 491 RSAES-OAEP-params ::= SEQUENCE { 492 hashFunc [0] AlgorithmIdentifier DEFAULT 493 sha1Identifier, 494 maskGenFunc [1] AlgorithmIdentifier DEFAULT 496 mgf1SHA1Identifier, 497 pSourceFunc [2] AlgorithmIdentifier DEFAULT 498 pSpecifiedEmptyIdentifier } 499 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 500 { id-pSpecified, nullOctetString } 502 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 504 The fields of type RSAES-OAEP-params have the following meanings: 506 hashFunc 508 The hashFunc field identifies the one-way hash function. It 509 MUST be one of the algorithm identifiers listed in section 510 2.1, and the default hash function is SHA-1. Implementations 511 MUST support SHA-1, and implementations MAY support other one- 512 way hash functions listed in section 2.1. Implementations 513 that perform encryption MUST omit the hashFunc field when SHA- 514 1 is used, indicating that the default algorithm was used. 515 Implementations that perform decryption MUST recognize both 516 the id-sha1 object identifier and an absent hashFunc field as 517 an indication that SHA-1 was used. 519 maskGenFunc 521 The maskGenFunc field identifies the mask generation function. 522 The default mask generation function is MGF1 with SHA-1. For 523 MGF1, it is strongly RECOMMENDED that the underlying hash 524 function be the same as the one identified by hashFunc. 525 Implementations MUST support MGF1. MGF1 requires a one-way 526 hash function, and it is identified in the parameter field of 527 the MGF1 algorithm identifier. Implementations MUST support 528 SHA-1, and implementations MAY support other one-way hash 529 functions listed in section 2.1. The MGF1 algorithm 530 identifier is comprised of the id-mgf1 object identifier and a 531 parameter that contains the algorithm identifier of the one- 532 way hash function employed with MGF1. The SHA-1 algorithm 533 identifier is comprised of the id-sha1 object identifier and 534 an (optional) parameter of NULL. Implementations that perform 535 encryption MUST omit the maskGenFunc field when MGF1 with SHA- 536 1 is used, indicating that the default algorithm was used. 538 Although mfg1SHA1Identifier is defined as the default value 539 for this field, implementations MUST accept both the default 540 value encoding (i.e. an absent field) and the 541 mfg1SHA1Identifier to be explicitly present in the encoding. 543 pSourceFunc 545 The pSourceFunc field identifies the source (and possibly the 546 value) of the encoding parameters, commonly called P. 547 Implementations MUST represent P by an algorithm identifier, 548 id-pSpecified, indicating that P is explicitly provided as an 549 OCTET STRING in the parameters. The default value for P is an 550 empty string. In this case, pHash in EME-OAEP contains the 551 hash of a zero length string. Implementations MUST support a 552 zero length P value. Implementations that perform encryption 553 MUST omit the pSourceFunc field when a zero length P value is 554 used, indicating that the default value was used. 555 Implementations that perform decryption MUST recognize both 556 the id-pSpecified object identifier and an absent pSourceFunc 557 field as an indication that a zero length P value was used. 558 Implementations that perform decryption MUST support a zero 559 length P value, and they MAY support other values. Compliant 560 implementations MUST NOT use any value other than id- 561 pSpecifieid for pSourceFunc. 563 If the default values of the hashFunc, maskGenFunc, and pSourceFunc 564 fields of RSAES-OAEP-params are used, then the algorithm identifier 565 will have the following value: 567 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 568 { id-RSAES-OAEP, 569 rSAES-OAEP-Default-Params } 571 rSAES-OAEP-Default-Params RSASSA-OAEP-params ::= 572 { sha1Identifier, 573 mgf1SHA1Identifier, 574 pSpecifiedEmptyIdentifier } 576 5 PKCS #1 Version 1.5 Signature Algorithm 578 RFC 2313 [P1v1.5] specifies the PKCS #1 Version 1.5 signature 579 algorithm. This specification is also included in PKCS #1 Version 580 2.1 [P1v2.1]. RFC 3279 [PKALGS] specifies the use of the PKCS #1 581 Version 1.5 signature algorithm with the MD2, MD5, and the SHA-1 582 one-way hash functions. This section specifies the algorithm 583 identifiers for using the SHA_224, SHA-256, SHA-384, and SHA-512 584 one-way hash functions with the PKCS #1 version 1.5 signature 585 algorithm. 587 The RSASSA-PSS signature algorithm is preferred over the PKCS #1 588 Version 1.5 signature algorithm. Although no attacks are known 589 against PKCS #1 Version 1.5 signature algorithm, in the interest of 590 increased robustness, RSASSA-PSS signature algorithm is recommended 591 for eventual adoption, especially by new applications. This section 592 is included for compatibility with existing applications, and while 593 still appropriate for new applications, a gradual transition to the 594 RSASSA-PSS signature algorithm is encouraged. 596 The PKCS #1 Version 1.5 signature algorithm with these one-way hash 597 functions and the RSA encryption algorithm is implemented using the 598 padding and encoding conventions described in RFC 2313 [P1v1.5]. 600 The message digest is computed using the SHA-224, SHA-256, SHA-384, 601 or SHA-512 one-way hash function. 603 The PKCS #1 version 1.5 signature algorithm, as specified in RFC 604 2313 includes a data encoding step. In this step, the message 605 digest and the object identifier for the one-way hash function used 606 to compute the message digest are combined. When performing the 607 data encoding step, the id-sha224, id-sha256, id-sha384, and id- 608 sha512 object identifiers (see section 2.1) MUST be used to specify 609 the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions, 610 respectively. 612 The object identifier used to identify the PKCS #1 version 1.5 613 signature algorithm with SHA-2224 is: 615 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 XX } 617 The object identifier used to identify the PKCS #1 version 1.5 618 signature algorithm with SHA-256 is: 620 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 622 The object identifier used to identify the PKCS #1 version 1.5 623 signature algorithm with SHA-384 is: 625 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 627 The object identifier used to identify the PKCS #1 version 1.5 628 signature algorithm with SHA-512 is: 630 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 632 When any of these three object identifiers appears within an 633 AlgorithmIdentifier, the parameters MUST be NULL. Implementations 634 MUST accept the parameters being absent as well as present. 636 The RSA signature generation process and the encoding of the result 637 is described in detail in RFC 2313 [P1v1.5]. 639 6 ASN.1 Module 641 PKIX1-PSS-OAEP-Algorithms 642 { iso(1) identified-organization(3) dod(6) 643 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 644 id-mod-pkix1-rsa-pkalgs(33) } 645 DEFINITIONS EXPLICIT TAGS ::= BEGIN 646 -- EXPORTS All; 648 IMPORTS 649 AlgorithmIdentifier 650 FROM PKIX1Explicit88 -- Found in [PROFILE] 651 { iso(1) identified-organization(3) dod(6) internet(1) 652 security(5) mechanisms(5) pkix(7) id-mod(0) 653 id-pkix1-explicit(18) }; 655 -- ============================ 656 -- Basic object identifiers 657 -- ============================ 659 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 660 us(840) rsadsi(113549) pkcs(1) 1 } 662 -- When rsaEncryption is used in an AlgorithmIdentifier the 663 -- parameters MUST be present and MUST be NULL. 665 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 667 -- When id-RSAES-OAEP is used in an AlgorithmIdentifier, 668 -- and the parameters field is present, it MUST be RSAES-OAEP-params 670 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 672 -- When id-pSpecified is used in an AlgorithmIdentifier the 673 -- parameters MUST be an OCTET STRING. 675 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 677 -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the 678 -- parameters field is present, it MUST be RSASSA-PSS-params. 680 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 682 -- When id-mgf1 is used in an AlgorithmIdentifier the parameters 683 -- MUST be present and MUST be a HashAlgorithm. 685 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 687 -- When the following OIDs are used in an AlgorithmIdentifier 2the 688 -- parameters MUST be present and MUST be NULL. 690 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 XX } 692 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 694 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 696 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 698 -- When the following OIDs are used in an AlgorithmIdentifier the 699 -- parameters SHOULD be absent, but if the parameters are present, 700 -- they MUST be NULL. 702 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 703 identified-organization(3) oiw(14) 704 secsig(3) algorithms(2) 26 } 705 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 706 country(16) us(840) organization(1) gov(101) 707 csor(3) nistalgorithm(4) hashalgs(2) 4 } 709 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 710 country(16) us(840) organization(1) gov(101) 711 csor(3) nistalgorithm(4) hashalgs(2) 1 } 713 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 714 country(16) us(840) organization(1) gov(101) 715 csor(3) nistalgorithm(4) hashalgs(2) 2 } 717 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 718 country(16) us(840) organization(1) gov(101) 719 csor(3) nistalgorithm(4) hashalgs(2) 3 } 721 -- ============= 722 -- Constant 723 -- ============= 725 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 727 -- ========================= 728 -- Algorithm Identifiers 729 -- ========================= 731 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 732 sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL } 733 sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL } 734 sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL } 735 sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL } 736 mgf1SHA1Identifier AlgorithmIdentifier ::= 737 { id-mgf1, sha1Identifier } 738 mgf1SHA224Identifier AlgorithmIdentifier ::= 739 { id-mgf1, sha224Identifier } 740 mgf1SHA256Identifier AlgorithmIdentifier ::= 741 { id-mgf1, sha256Identifier } 742 mgf1SHA384Identifier AlgorithmIdentifier ::= 743 { id-mgf1, sha384Identifier } 744 mgf1SHA512Identifier AlgorithmIdentifier ::= 745 { id-mgf1, sha512Identifier } 746 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 747 { id-pSpecified, nullOctetString } 748 rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= { 749 id-RSASSA-PSS, rSASSA-PSS-Default-Params } 751 rSASSA-PSS-Default-Params RSASSA-PSS-params ::= { 752 sha1Identifier, 753 mgf1SHA1Identifier, 754 20, 755 1 } 757 rSASSA-PSS-SHA224-Identifier AlgorithmIdentifier ::= { 758 id-RSASSA-PSS, rSASSA-PSS-SHA224-Params } 760 rSASSA-PSS-SHA224-Params RSASSA-PSS-params ::={ 761 sha224Identifier, 762 mgf1SHA224Identifier, 763 20, 764 1 } 766 rSASSA-PSS-SHA256-Identifier AlgorithmIdentifier ::= { 767 id-RSASSA-PSS, rSASSA-PSS-SHA256-Params } 769 rSASSA-PSS-SHA256-Params RSASSA-PSS-params ::={ 770 sha256Identifier, 771 mgf1SHA256Identifier, 772 20, 773 1 } 775 rSASSA-PSS-SHA384-Identifier AlgorithmIdentifier ::= { 776 id-RSASSA-PSS, rSASSA-PSS-SHA384-Params } 778 rSASSA-PSS-SHA384-Params RSASSA-PSS-params ::= { 779 sha384Identifier, 780 mgf1SHA384Identifier, 781 20, 782 1 } 784 rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= { 785 id-RSASSA-PSS, rSSASSA-PSS-SHA512-params } 787 rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { 788 sha512Identifier, 789 mgf1SHA512Identifier, 790 20, 791 1 } 793 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 794 { id-RSAES-OAEP, rSAES-OAEP-Default-Params } 796 rSAES-OAEP-Default-Params RSAES-OAEP-params ::= 797 { sha1Identifier, 798 mgf1SHA1Identifier, 799 pSpecifiedEmptyIdentifier } 801 rSAES-OAEP-SHA224-Identifier AlgorithmIdentifier ::= 802 { id-RSAES-OAEP, rSAES-OAEP-SHA224-Params } 803 rSAES-OAEP-SHA224-Params RSAES-OAEP-params ::= 804 { sha224Identifier, 805 mgf1SHA224Identifier, 806 pSpecifiedEmptyIdentifier } 808 rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::= 809 { id-RSAES-OAEP, rSAES-OAEP-SHA256-Params } 811 rSAES-OAEP-SHA256-Params RSAES-OAEP-params ::= 812 { sha256Identifier, 813 mgf1SHA256Identifier, 814 pSpecifiedEmptyIdentifier } 816 rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::= 817 { id-RSAES-OAEP, rSAES-OAEP-SHA384-Params } 819 rSAES-OAEP-SHA384-Params RSAES-OAEP-params ::= 820 { sha384Identifier, 821 mgf1SHA384Identifier, 822 pSpecifiedEmptyIdentifier } 824 rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::= 825 { id-RSAES-OAEP, rSAES-OAEP-SHA512-Params} 827 rSAES-OAEP-SHA512-Params RSAES-OAEP-params ::= 828 { sha512Identifier, 829 mgf1SHA512Identifier, 830 pSpecifiedEmptyIdentifier } 832 -- =================== 833 -- Main structures 834 -- =================== 836 -- Used in SubjectPublicKeyInfo of X.509 Certificate. 838 RSAPublicKey ::= SEQUENCE { 839 modulus INTEGER, -- n 840 publicExponent INTEGER } -- e 842 -- AlgorithmIdentifier parameters for id-RSASSA-PSS. 843 -- Note that the tags in this Sequence are explicit. 845 RSASSA-PSS-params ::= SEQUENCE { 846 hashAlgorithm [0] HashAlgorithm DEFAULT 847 sha1Identifier, 848 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT 849 mgf1SHA1Identifier, 850 saltLength [2] INTEGER DEFAULT 20, 851 trailerField [3] INTEGER DEFAULT 1 } 852 HashAlgorithm ::= AlgorithmIdentifier 853 MaskGenAlgorithm ::= AlgorithmIdentifier 855 -- AlgorithmIdentifier parameters for id-RSAES-OAEP. 856 -- Note that the tags in this Sequence are explicit. 858 RSAES-OAEP-params ::= SEQUENCE { 859 hashFunc [0] AlgorithmIdentifier DEFAULT 860 sha1Identifier, 861 maskGenFunc [1] AlgorithmIdentifier DEFAULT 862 mgf1SHA1Identifier, 863 pSourceFunc [2] AlgorithmIdentifier DEFAULT 864 pSpecifiedEmptyIdentifier } 866 END 868 7 References 870 This section provides normative and informative references. 872 7.1 Normative References 874 [P1v1.5] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 875 RFC 2313, March 1998. 877 [P1v2.1] Jonsson, J., and B. Kaliski, "PKCS #1: RSA 878 Cryptography Specifications Version 2.1", Internet-Draft, 879 August 2002. 881 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 882 X.509 Public Key Infrastructure: Certificate and CRL 883 Profile", RFC 3280, April 2002. 885 [SHA2] National Institute of Standards and Technology (NIST), 886 FIPS 180-2: Secure Hash Standard, 1 August 2002. 888 [SHA224] Housley, R, "A 224-bit One-way Hash Function: SHA-224", 889 draft-ietf-pkix-sha224-00.txt, November 2003. 891 [STDWORDS] S. Bradner, "Key Words for Use in RFCs to Indicate 892 Requirement Levels", RFC 2119, March 1997. 894 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 895 Syntax Notation One (ASN.1), 1988. 897 [X.209-88] CCITT Recommendation X.209: Specification of Basic 898 Encoding Rules for Abstract Syntax Notation One (ASN.1), 899 1988. 901 [X.509-88] CCITT Recommendation X.509: The Directory - 902 Authentication Framework. 1988. 904 7.2 Informative References 906 [CMS] Housley, R, "Cryptographic Message Syntax", RFC 3369, 907 August 2002. 909 [GUIDE] National Institute of Standards and Technology, 910 Second Draft: "Key Management Guideline, Part 1: 911 General Guidance." June 2002. 912 [http://csrc.nist.gov/encryption/kms/guideline-1.pdf] 914 [P1363a] IEEE P1363 working group, IEEE P1363a D11: Standard 915 Specifications for Public Key Cryptography: Additional 916 Techniques, December 16, 2002 917 Available from http://grouper.ieee.org/groups/1363/. 919 [PKALGS] Polk, W., Housley, R., and L. Bassham, "Algorithms and 920 Identifiers for the Internet X.509 Public Key 921 Infrastructure Certificate and Certificate Revocation 922 Lists (CRL) Profile", RFC 3279, April 2002. 924 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 925 Recommendations for Security, RFC 1750, December 1994. 927 8 Security Considerations 929 This specification supplements RFC 3280 [PROFILE]. The security 930 considerations section of that document applies to this 931 specification as well. 933 Implementations must protect the RSA private key. Compromise of the 934 RSA private key may result in the disclosure of all messages 935 protected with that key. 937 The generation of RSA public/private key pairs relies on a random 938 numbers. The use of inadequate pseudo-random number generators 939 (PRNGs) to generate cryptographic keys can result in little or no 940 security. An attacker may find it much easier to reproduce the PRNG 941 environment that produced the keys, searching the resulting small 942 set of possibilities, rather than brute force searching the whole 943 key space. The generation of quality random numbers is difficult. 944 RFC 1750 [RANDOM] offers important guidance in this area. 946 Generally, good cryptographic practice employs a given RSA key pair 947 in only one scheme. This practice avoids the risk that 948 vulnerability in one scheme may compromise the security of the 949 other, and may be essential to maintain provable security. While 950 PKCS #1 Version 1.5 [P1v1.5] has been employed for both key 951 transport and digital signature without any known bad interactions, 952 such a combined use of an RSA key pair is not recommended in the 953 future. Therefore, an RSA key pair used for RSASSA-PSS signature 954 generation should not also be used for other purposes. For similar 955 reasons, one RSA key pair should always be used with the same 956 RSASSA-PSS parameters. Likewise, an RSA key pair used for RSAES- 957 OAEP key transport should not also be used for other purposes. For 958 similar reasons, one RSA key pair should always be used with the 959 same RSAES-OAEP parameters. 961 This specification requires implementations to support the SHA-1 962 one-way hash function for interoperability, but support for other 963 one-way hash function is permitted. At the time of this writing, 964 the best (known) collision attacks against SHA-1 are generic attacks 965 with complexity 2^80, where 80 is one-half the bit length of the 966 hash value. In general, when a one-way hash function is used with a 967 digital signature scheme, a collision attack is easily translated 968 into a signature forgery. Therefore, the use of SHA-1 in a digital 969 signature scheme provides a security level of no more than 80 bits. 970 If a greater level of security is desired, then a secure one-way 971 hash function with a longer hash value is needed. SHA-256, SHA-384, 972 and SHA-512 are reasonable choices [SHA2]. 974 The metrics for choosing a one-way hash function for use in digital 975 signatures do not directly apply to the RSAES-OAEP key transport 976 algorithm, since a collision attack on the one-way hash function 977 does not directly translate into an attack on the key transport 978 algorithm, unless the encoding parameters P varies (in which case a 979 collision the hash value for different encoding parameters might be 980 exploited). 982 Nevertheless, for consistency with the practice for digital 983 signature schemes, and in case the encoding parameters P is not the 984 empty string, it is recommended that the same rule of thumb be 985 applied to selection of a one-way hash function for use with RSAES- 986 OAEP. That is, the one-way hash function should be selected so that 987 the bit length of the hash value is at least twice as long as the 988 desired security level in bits. 990 This specification does not constrain the size of public keys or 991 their parameters for use in the Internet PKI. However, the key size 992 selected impacts the strength achieved when implementing 993 cryptographic services. Selection of appropriate key sizes is 994 critical to implementing appropriate security. However, a 1024-bit 995 RSA public key and SHA-1 both provide a security level of about 80 996 bits. In [GUIDE], the National Institute of Standards and 997 Technology (NIST) suggests that a security level of 80 bits is 998 adequate for the protection of sensitive information until 2015. 999 This recommendation is likely to be revised based on recent 1000 advances, and the revised recommendation is expected to be more 1001 conservative, suggesting that a security level of 80 bits is 1002 adequate for the protection of sensitive information until 2010 1003 currently being brought in to the year 2010 as a more conservative 1004 measure. If a security level greater than 80 bits is needed, then a 1005 longer RSA public key and a secure one-way hash function with a 1006 longer hash value are needed. Again, SHA-256, SHA-384, and SHA-512 1007 are reasonable choices for such a one-way hash function. For this 1008 reason, the algorithm identifiers for these one-way hash functions 1009 are included in the ASN.1 module in section 5. 1011 When using RSASSA-PSS, the same one-way hash function should be 1012 employed for the hashAlgorithm and the maskGenAlgorithm, but it is 1013 not required. Using the same one-way hash function helps with 1014 security analysis, and it reduces implementation complexity. 1015 When using RSAES-OAEP, the same one-way hash function should be 1016 employed for the hashFunc and the maskGenFunc, but it is not 1017 required. In each case, using the same one-way hash function helps 1018 with security analysis, and it reduces implementation complexity. 1020 9 IANA Considerations 1022 Within the certificates and CRLs, algorithms are identified by 1023 object identifiers. All of the object identifiers used in this 1024 document were assigned in Public-Key Cryptography Standards (PKCS) 1025 documents or by the National Institute of Standards and Technology 1026 (NIST). No further action by the IANA is necessary for this 1027 document or any anticipated updates. 1029 10 Author Addresses 1031 Russell Housley 1032 Vigil Security, LLC 1033 918 Spring Knoll Drive 1034 Herndon, VA 20170 1035 USA 1036 rhousley@vigilsec.com 1038 Burt Kaliski 1039 RSA Laboratories 1040 174 Middlesex Turnpike 1041 Bedford, MA 01730 1042 USA 1043 bkaliski@rsasecurity.com 1045 Jim Schaad 1046 Soaring Hawk Consulting 1047 PO Box 675 1048 Gold Bar, WA 98251 1049 USA 1050 jimsch@exmsft.com 1052 11 Full Copyright Statement 1054 Copyright (C) The Internet Society (2003). All Rights Reserved. 1056 This document and translations of it may be copied and furnished to 1057 others, and derivative works that comment on or otherwise explain it 1058 or assist in its implementation may be prepared, copied, published 1059 and distributed, in whole or in part, without restriction of any 1060 kind, provided that the above copyright notice and this paragraph 1061 are included on all such copies and derivative works. 1062 In addition, the ASN.1 modules presented in Section 5 may be used in 1063 whole or in part without inclusion of the copyright notice. However, 1064 this document itself may not be modified in any way, such as by 1065 removing the copyright notice or references to the Internet Society 1066 or other Internet organizations, except as needed for the purpose of 1067 developing Internet standards in which case the procedures for 1068 copyrights defined in the Internet Standards process shall be 1069 followed, or as required to translate it into languages other than 1070 English. 1071 The limited permissions granted above are perpetual and will not be 1072 revoked by the Internet Society or its successors or assigns. This 1073 document and the information contained herein is provided on an "AS 1074 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1075 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1076 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1077 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1078 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.