view Side-By-Side changes
Network Working Group J. Schaad(SoaringRequest for Comments: 4055 Soaring HawkConsulting) Internet DraftConsulting Updates: 3279 B. Kaliski(RSA Laboratories)Category: Standards Track RSA Laboratories R. Housley(Vigil Security) expires September 2004 March 2004Vigil Security June 2005 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile<draft-ietf-pkix-rsa-pkalgs-03.txt>Status ofthisThis Memo This documentisspecifies anInternet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents ofInternet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents validrequests discussion and suggestions fora maximumimprovements. Please refer to the current edition ofsix monthsthe "Internet Official Protocol Standards" (STD 1) for the standardization state andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The liststatus ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listthis protocol. Distribution ofInternet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html.this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document supplements RFC 3279. It describes the conventions for using theRSASSA-PSSRSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, theRSAES-OAEPRSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with thePKCSPublic-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. Schaad, et al. Standards Track [Page 1] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 Table of Contents1 Introduction.......................................................2 1.1 Terminology....................................................2 1.21. Introduction ....................................................2 1.1. Terminology ................................................3 1.2. RSA PublicKeys................................................2 2Keys ............................................3 2. CommonFunctions...................................................5 2.1Functions ................................................5 2.1. One-way HashFunctions.........................................5 2.2Functions .....................................5 2.2. Mask GenerationFunctions......................................6 3Functions ..................................6 3. RSASSA-PSS SignatureAlgorithm.....................................7 3.1Algorithm ..................................7 3.1. RSASSA-PSS PublicKeys.........................................7 3.2Keys .....................................8 3.2. RSASSA-PSS SignatureValues....................................9 3.3Values ...............................10 3.3. RSASSA-PSS Signature ParameterValidation......................9 Schaad, Kaliski & Housley Page 1 4Validation .................10 4. RSAES-OAEP Key TransportAlgorithm................................10 4.1Algorithm .............................10 4.1. RSAES-OAEP PublicKeys........................................10 5Keys ....................................11 5. PKCS #1 Version 1.5 SignatureAlgorithm...........................12 6Algorithm ........................13 6. ASN.1Module......................................................13 7 References........................................................19 7.1Module ...................................................14 7. References .....................................................20 7.1. NormativeReferences..........................................19 7.2References ......................................20 7.2. InformativeReferences........................................19 8References ....................................21 8. SecurityConsiderations...........................................20 10 Author Addresses.................................................22 11 Full Copyright Statement.........................................22 1Considerations ........................................21 9. IANA Considerations ............................................24 1. Introduction This document supplements RFC 3279 [PKALGS]. This document describes the conventions for using the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI) [PROFILE]. Both of theseRSA- basedRSA-based algorithms are specified in [P1v2.1]. The algorithm identifiers and associated parameters for subject public keys that employ either of thesealgorithms are specified,algorithms, and the encoding format for RSASSA-PSS signaturesisare specified. Also, the algorithm identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions with the PKCS #1 version 1.5 signature algorithm [P1v1.5] are specified. This specification supplements RFC 3280[PROFILE],[PROFILE] which profiles the X.509 Certificates and Certificate Revocation Lists (CRLs) for use in the Internet. This specification extends the list of algorithms discussed in RFC 3279 [PKALGS]. The X.509 Certificate and CRL definitions use ASN.1 [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)[X.509- 88].[X.509-88]. This specification defines the contents of the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509certificatesCertificates and CRLs. For each algorithm, the appropriate alternatives for the keyUsage certificate extension are provided.1.1Schaad, et al. Standards Track [Page 2] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS].1.21.2. RSA Public Keys RFC 3280 [PROFILE] specifies the profile for using X.509 Certificates in Internet applications. Whenaan RSA public keywill Schaad, Kaliski & Housley Page 2 beis used for RSASSA-PSS digital signatures or RSAES-OAEP key transport, the conventions specified in this section augment RFC 3280. Traditionally, the rsaEncryption object identifier is used to identify RSA public keys. However, to implement all of the recommendations described intheSecurity Considerationssection of this document (see section(Section 8), the certificate user needs to be able to determine the form of digital signature or key transport that the RSA private key owner associates with the public key. The rsaEncryption object identifier continues to identify the subject public key when the RSA private key owner does not wish to limit the use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. In this case, the rsaEncryption object identifier MUST be used in the algorithm field within the subject public key information, and the parameters field MUST contain NULL. rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } Further discussion of the conventions associated with use of the rsaEncryption object identifier can be found in RFC 3279 (see [PKALGS],sectionSection 2.3.1). When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object identifier MUST be used in the algorithm field within the subject public key information, and, if present, the parameters field MUST contain RSASSA-PSS-params. The id-RSASSA-PSS object identifier value and the RSASSA-PSS-params syntax are fully described insection 3 of this document.Section 3. When the RSA private key owner wishes to limit the use of the public key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object identifier MUST be used in the algorithm field within the subject public key information, and, if present, the parameters field MUST contain RSAES-OAEP-params. The id-RSAES-OAEP object identifier value and the RSAES-OAEP-params syntax are fully described insection 4 of this document.Section 4. Schaad, et al. Standards Track [Page 3] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 Note: It is not possible to restrict the use of a key toonly just twoa set ofthealgorithms(i.e.(i.e., RSASSA-PSS andRSAES-OAEP) in this document.RSAES-OAEP). Regardless of the object identifier used, the RSA public key is encoded in the same manner in the subject public key information. The RSA public key MUST be encoded using the type RSAPublicKey type: RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- eSchaad, Kaliski & Housley Page 3Here, the modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is carried in the subjectPublicKey BIT STRING within the subject public key information. The intended application for the key MAY be indicated in thekey usagekeyUsage certificate extension (see [PROFILE],sectionSection 4.2.1.3). If the keyUsage extension is present in anend entityend-entity certificate that conveys an RSA public key with the id-RSASSA-PSS object identifier, then thekey usagekeyUsage extension MUST contain one or both of the following values: nonRepudiation; and digitalSignature. If the keyUsage extension is present in a certification authority certificate that conveys an RSA public key with the id-RSASSA-PSS object identifier, then thekey usagekeyUsage extension MUST contain one or more of the following values: nonRepudiation; digitalSignature; keyCertSign; and cRLSign. When a certificatethatconveys an RSA public key with theid- RSASSA-PSSid-RSASSA-PSS object identifier, the certificate user MUST only use the certified RSA public key for RSASSA-PSS operations, and, ifRSASSA- PSS-paramsRSASSA-PSS-params is present, the certificate user MUST perform those operations using the one-way hash function, mask generation function, and trailer field identified in the subject public key algorithm identifier parameters within the certificate. Schaad, et al. Standards Track [Page 4] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 If the keyUsage extension is present in a certificatethatconveys an RSA public key with the id-RSAES-OAEP object identifier, then thekey usagekeyUsage extension MUST contain only the following values: keyEncipherment; and dataEncipherment. However, both keyEncipherment and dataEncipherment SHOULD NOT be present. When a certificate that conveys an RSA public key with theid-RSAES- OAEPid-RSAES-OAEP object identifier, the certificate user MUST only use the certified RSA public key for RSAES-OAEP operations, and, ifRSAES- OAEP-paramsRSAES-OAEP-params is present, the certificate user MUST perform those operations using the one-way hash function and mask generationSchaad, Kaliski & Housley Page 4function identified in the subject public key algorithm identifier parameters within the certificate.22. Common Functions The RSASSA-PSS signaturealgorithmand the RSAES-OAEP key transportalgorithmalgorithms make use of one-way hash functions and mask generation functions.2.12.1. One-way Hash Functions PKCS #1 version 2.1 [P1v2.1] supports four one-way hash functions for use with the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm: SHA-1, SHA-256, SHA-384, and SHA-512 [SHA2]. This document addsadditionalsupport for SHA-224 [SHA-224] with both the RSASSA-PSS and the RSAES-OAEP algorithms. While support for additional one-way hash functions could be added in the future, no other one-way hash functions are supported by this specification. These one-way hash functions are identified by the following object identifiers: id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } Schaad, et al. Standards Track [Page 5] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } There are two possible encodings for the AlgorithmIdentifier parameters field associated with these object identifiers. The two alternatives arise from thefact thatloss of the OPTIONAL associated with the algorithm identifier parameters when the 1988 syntax for AlgorithmIdentifier was translated into the 1997syntax the OPTIONAL associated with the algorithm identifier parameters got lost.syntax. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL elementandwhile others omit them entirely. The correct encoding is to omit the parameters field; however,at the time thatwhen RSASSA-PSS andSchaad, Kaliski & Housley Page 5RSAES-OAEP weredefineddefined, it was done using the NULL parameters rather than absent parameters. All implementations MUST accept both NULL and absent parameters as legal and equivalent encodings. To be clear, the following algorithm identifiers are used when a NULL parameter MUST be present: sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL } sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL } sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL } sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }2.22.2. Mask Generation Functions One mask generation function is used with the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm: MGF1 [P1v2.1]. No other mask generation functions are supported by this specification. MGF1 is identified by the following object identifier: id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } The parameters field associated with id-mgf1 MUST have a hashAlgorithmvalue,value which identifies the hash function being used with MGF1. This value MUST be sha1Identifier, sha224Identifier, sha256Identifier, sha384Identifier, or sha512Identifier, as specified insectionSection 2.1. Implementations MUST support the default value, sha1Identifier, andimplementationsMAY support the other four values. Schaad, et al. Standards Track [Page 6] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 The following algorithm identifiers have been assigned for each of these alternatives: mgf1SHA1Identifier AlgorithmIdentifier ::= { id-mgf1, sha1Identifier } mgf1SHA224Identifier AlgorithmIdentifier ::= { id-mgf1, sha224Identifier } mgf1SHA256Identifier AlgorithmIdentifier ::= { id-mgf1, sha256Identifier } mgf1SHA384Identifier AlgorithmIdentifier ::= { id-mgf1, sha384Identifier } mgf1SHA512Identifier AlgorithmIdentifier ::= { id-mgf1, sha512Identifier }Schaad, Kaliski & Housley Page 6 33. RSASSA-PSS Signature Algorithm This section describes the conventions for using the RSASSA-PSS signature algorithm with the Internet X.509certificateCertificate and CRL profile [PROFILE]. The RSASSA-PSS signature algorithm is specified in PKCS #1 version 2.1 [P1v2.1]. The five one-way hash functions discussed insectionSection 2.1 and the one mask generation function discussed insectionSection 2.2 can be used with RSASSA-PSS. CAs that issue certificates with the id-RSASSA-PSS algorithm identifier SHOULD requirethatthe presence of parametersbe presentin the publicKeyAlgorithms field if the cA boolean flag is set in the basic constraints certificate extension. CAs MAY require that the parameters be present in the publicKeyAlgorithms field for end-entity certificates. CAs that use the RSASSA-PSS algorithm for signingcertificates,certificates SHOULDhaveinclude RSASSA-PSS-params in the subjectPublicKeyInfo algorithm parameterspresentin their own certificates. CAs that use the RSASSA-PSS algorithm forsigning,signing certificatesandor CRLs MUST includeRSASSA-PSS-paramsRSASSA-PSS- params in the signatureAlgorithm parameters in thesignature algorithm field of theTBSCertificateandor TBSCertList structures. Entities that validate RSASSA-PSS signatures MUSThavesupportforSHA-1. They MAY also supporttheany otherhashing algorithmsone-way hash functions insectionSection 2.1. The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSAencryption)decryption) is performed to generate the signature value. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in thesignaturesignatureValue field. Section 3.2 specifies the format of RSASSA-PSS signature values.3.1Schaad, et al. Standards Track [Page 7] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 3.1. RSASSA-PSS Public Keys When RSASSA-PSS is used in anAlgorithmIdentifier,theAlgorithmIdentifier, the parameters MUST employ the RSASSA-PSS-params syntax. The parameters may be either absent or present when used as subject public key information. The parameters MUST be present when used in the algorithm identifier associated withfora signature value. When signing, it is RECOMMENDEDthat,that the parameters, except for possibly saltLength,the parametersremain fixed for all usages of a given RSA key pair. id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier,Schaad, Kaliski & Housley Page 7maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } The fields of type RSASSA-PSS-params have the following meanings: hashAlgorithm The hashAlgorithm field identifies the hash function. It MUST be one of the algorithm identifiers listed insectionSection 2.1, and the default hash function is SHA-1. Implementations MUST supportSHA-1,SHA-1 andimplementationsMAY support any of the other one-way hash functions listed insectionSection 2.1. Implementations that perform signature generation MUST omit the hashAlgorithm field when SHA-1 is used, indicating that the default algorithm was used. Implementations that perform signature validation MUST recognize both theid-sha1 objectsha1Identifier algorithm identifier and an absent hashAlgorithm field as an indication that SHA-1 was used. maskGenAlgorithm The maskGenAlgorithm field identifies the mask generation function. The default mask generation function is MGF1 with SHA-1. For MGF1, it is strongly RECOMMENDED that the underlying hash function be the same as the one identified by hashAlgorithm. Implementations MUST support MGF1. MGF1 requires a one-way hashfunction, and itfunction that is identified in the parameters field of the MGF1 algorithm identifier. Implementations MUST supportSHA-1,SHA-1 andimplementationsMAY support any of the Schaad, et al. Standards Track [Page 8] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 other one-way hash functions listed in section Section 2.1. The MGF1 algorithm identifier is comprised of the id-mgf1 object identifier and a parameter that contains the algorithm identifier of the one-way hash function employed with MGF1. The SHA-1 algorithm identifier is comprised of the id-sha1 object identifier and an (optional) parameter of NULL. Implementations that perform signature generation MUST omit the maskGenAlgorithm field when MGF1 with SHA-1 is used, indicating that the default algorithm was used. Although mfg1SHA1Identifier is defined as the default value for this field, implementations MUST accept both the default value encoding(i.e.(i.e., an absent field) and mfg1SHA1Identifier to be explicitly present in the encoding. saltLength The saltLength field is the octet length of the salt. For a given hashAlgorithm, theminimumrecommended value of saltLength is the number of octets in the hash value. Unlike the other fields of type RSASSA-PSS-params, saltLength does not need to beSchaad, Kaliski & Housley Page 8fixed for a given RSA key pair; a different value could be used for each RSASSA-PSS signature generated. trailerField The trailerField field is an integer. It provides compatibility withthe draftIEEEP1363a [P1363a].Std 1363a-2004 [P1363A]. The value MUST be 1, which represents the trailer field with hexadecimal value 0xBC. Other trailer fields, including the trailer field composed of HashID concatenated with 0xCC that is specified in IEEEP1363a,Std 1363a, are not supported. Implementations that perform signature generation MUST omit the trailerField field, indicating that the default trailer field value was used. Implementations that perform signature validation MUST recognize both a present trailerField field with value 1 and an absent trailerField field. If the default values of the hashAlgorithm, maskGenAlgorithm, and trailerField fields of RSASSA-PSS-params are used, then the algorithm identifier will have the following value: rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= { id-RSASSA-PSS, rSASSA-PSS-Default-Params } rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= { sha1Identifier, mgf1SHA1Identifier, 20, 1}3.2Schaad, et al. Standards Track [Page 9] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 3.2. RSASSA-PSS Signature Values The output of the RSASSA-PSS signature algorithm is an octet string, which has the same length in octets as the RSA modulus n. Signature values in CMS [CMS] are represented as octet strings, and the output is used directly. However, signature values in certificates and CRLs [PROFILE] are represented as bit strings, and conversion is needed. To convert a signature value to a bit string, the most significant bit of the first octet of the signature value SHALL become the first bit of the bit string, and so on through the least significant bit of the last octet of the signature value, which SHALL become the last bit of the bit string.3.33.3. RSASSA-PSS Signature Parameter Validation Three possible parameter validation scenarios exist for RSASSA-PSS signature values. 1. The key is identified by the rsaEncryption algorithm identifier. In this case no parameter validation is needed.Schaad, Kaliski & Housley Page 92. The key is identified by the id-RSASSA-PSS signature algorithm identifier, but the parameters field is absent. In this case no parameter validation is needed. 3. The key is identified by the id-RSASSA-PSS signature algorithm identifier and the parameters are present. In this case all parameters in the signature structure algorithm identifier MUST match the parameters in the key structure algorithm identifier except the saltLength field. The saltLength field in the signature parameters MUST be greater or equal to that in the key parameters field.44. RSAES-OAEP Key Transport Algorithm This section describes the conventions for using the RSAES-OAEP key transport algorithm with the Internet X.509certificateCertificate and CRL profile [PROFILE]. RSAES-OAEP is specified in PKCS #1 version 2.1 [P1v2.1]. The five one-way hash functions discussed insectionSection 2.1 and the one mask generation function discussed insectionSection 2.2 can be used with RSAES-OAEP. Conforming CAs and applications MUST support RSAES-OAEP key transport algorithm using SHA-1. The otherthree one-wayfour one- way hash functions MAY also be supported. Schaad, et al. Standards Track [Page 10] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 CAs that issue certificates with the id-RSAES-OAEP algorithm identifier SHOULD requirethatthe presence of parametersbe presentin the publicKeyAlgorithms field for all certificates. Entities that use a certificate with a publicKeyAlgorithm value of id-RSA-OAEP where the parameters are absent SHOULD use the default set of parameters for RSAES-OAEP-params. Entities that use a certificate with a publicKeyAlgorithm value of rsaEncryption SHOULD use the default set of parameters forRSAES-OAEP-params 4.1RSAES-OAEP-params. 4.1. RSAES-OAEP Public Keys When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters MUST employ the RSAES-OAEP-params syntax. The parameters may be either absent or present when used as subject public key information. The parameters MUST be present when used in the algorithm identifier associated with anencryptionencrypted value. id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } RSAES-OAEP-params ::= SEQUENCE { hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, pSourceFunc [2] AlgorithmIdentifier DEFAULT pSpecifiedEmptyIdentifier }Schaad, Kaliski & Housley Page 10pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= { id-pSpecified, nullOctetString } nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } The fields of type RSAES-OAEP-params have the following meanings: hashFunc The hashFunc field identifies the one-way hash function. It MUST be one of the algorithm identifiers listed insectionSection 2.1, and the default hash function is SHA-1. Implementations MUST supportSHA-1,SHA-1 andimplementationsMAY support otherone- wayone-way hash functions listed insectionSection 2.1. Implementations that perform encryption MUST omit the hashFunc field whenSHA- 1SHA-1 is used, indicating that the default algorithm was used. Implementations that perform decryption MUST recognize both theid-sha1 objectsha1Identifier algorithm identifier and an absent hashFunc field as an indication that SHA-1 was used. Schaad, et al. Standards Track [Page 11] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 maskGenFunc The maskGenFunc field identifies the mask generation function. The default mask generation function is MGF1 with SHA-1. For MGF1, it is strongly RECOMMENDED that the underlying hash function be the same as the one identified by hashFunc. Implementations MUST support MGF1. MGF1 requires a one-way hashfunction, and itfunction that is identified in the parameter field of the MGF1 algorithm identifier. Implementations MUST supportSHA-1,SHA-1 andimplementationsMAY support any of the other one-way hash functions listed insectionSection 2.1. The MGF1 algorithm identifier is comprised of the id-mgf1 object identifier and a parameter that contains the algorithm identifier of theone- wayone-way hash function employed with MGF1. The SHA-1 algorithm identifier is comprised of theid-sha1id- sha1 object identifier and an (optional) parameter of NULL. Implementations that perform encryption MUST omit the maskGenFunc field when MGF1 withSHA- 1SHA-1 is used, indicating that the default algorithm was used. Although mfg1SHA1Identifier is defined as the default value for this field, implementations MUST accept both the default value encoding(i.e.(i.e., an absent field) and the mfg1SHA1Identifier to be explicitly present in the encoding. pSourceFunc The pSourceFunc field identifies the source (and possibly the value) of the encoding parameters, commonly called P. Implementations MUST represent P by an algorithm identifier, id-pSpecified, indicating that P is explicitly provided as an OCTET STRING in the parameters. The default value for P is anSchaad, Kaliski & Housley Page 11empty string. In this case, pHash in EME-OAEP contains the hash of a zero length string. Implementations MUST support a zero length P value. Implementations that perform encryption MUST omit the pSourceFunc field when a zero length P value is used, indicating that the default value was used. Implementations that perform decryption MUST recognize both the id-pSpecified object identifier and an absent pSourceFunc field as an indication that a zero length P value was used. Implementations that perform decryption MUST support a zero length Pvalue,value andtheyMAY support other values. Compliant implementations MUST NOT use any value other thanid- pSpecifieidid-pSpecified for pSourceFunc. Schaad, et al. Standards Track [Page 12] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 If the default values of the hashFunc, maskGenFunc, and pSourceFunc fields of RSAES-OAEP-params are used, then the algorithm identifier will have the following value: rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= { id-RSAES-OAEP, rSAES-OAEP-Default-Params } rSAES-OAEP-Default-Params RSASSA-OAEP-params ::= { sha1Identifier, mgf1SHA1Identifier, pSpecifiedEmptyIdentifier }55. PKCS #1 Version 1.5 Signature Algorithm RFC 2313 [P1v1.5] specifies the PKCS #1 Version 1.5 signature algorithm. This specification is also included in PKCS #1 Version 2.1 [P1v2.1]. RFC 3279 [PKALGS] specifies the use of the PKCS #1 Version 1.5 signature algorithm with the MD2, MD5, and the SHA-1 one-way hash functions. This section specifies the algorithm identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions with the PKCS #1 version 1.5 signature algorithm. The RSASSA-PSS signature algorithm is preferred over the PKCS #1 Version 1.5 signature algorithm. Although no attacks are known against PKCS #1 Version 1.5 signature algorithm, in the interest of increased robustness, RSASSA-PSS signature algorithm is recommended for eventual adoption, especially by new applications. This section is included for compatibility with existing applications, and while still appropriate for new applications, a gradual transition to the RSASSA-PSS signature algorithm is encouraged. The PKCS #1 Version 1.5 signature algorithm with these one-way hash functions and the RSAencryption algorithmcryptosystem is implemented using the padding and encoding conventions described in RFC 2313 [P1v1.5].Schaad, Kaliski & Housley Page 12The message digest is computed using the SHA-224, SHA-256, SHA-384, or SHA-512 one-way hash function. The PKCS #1 version 1.5 signature algorithm, as specified in RFC23132313, includes a data encoding step. In this step, the message digest and the object identifier for the one-way hash function used to compute the message digest are combined. When performing the data encoding step, the id-sha224, id-sha256, id-sha384, andid- sha512id-sha512 object identifiers (seesectionSection 2.1) MUST be used to specify the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions, respectively. Schaad, et al. Standards Track [Page 13] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-224 is: sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 } The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-256 is: sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-384 is: sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-512 is: sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } When any of thesethreefour object identifiers appears within an AlgorithmIdentifier, the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present. The RSA signature generation process and the encoding of the resultisare described in detail in RFC 2313 [P1v1.5].66. ASN.1 Module PKIX1-PSS-OAEP-Algorithms { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-rsa-pkalgs(33) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All; IMPORTSSchaad, Kaliski & Housley Page 13AlgorithmIdentifier FROM PKIX1Explicit88 -- Found in [PROFILE] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; Schaad, et al. Standards Track [Page 14] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 -- ============================ -- Basic object identifiers -- ============================ pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } -- When rsaEncryption is used in an AlgorithmIdentifier the -- parameters MUST be present and MUST be NULL. rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } -- When id-RSAES-OAEP is used in an AlgorithmIdentifier, -- and the parameters field is present, it MUST be -- RSAES-OAEP-params id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } -- When id-pSpecified is used in an AlgorithmIdentifier the -- parameters MUST be an OCTET STRING. id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the -- parameters field is present, it MUST be RSASSA-PSS-params. id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } -- When id-mgf1 is used in an AlgorithmIdentifier the parameters -- MUST be present and MUST be a HashAlgorithm. id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } -- When the following OIDs are used in an AlgorithmIdentifier, the -- parameters MUST be present and MUST be NULL. sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 } sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } Schaad, et al. Standards Track [Page 15] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 -- When the following OIDs are used in an AlgorithmIdentifier theSchaad, Kaliski & Housley Page 14-- parameters SHOULD be absent, but if the parameters are present, -- they MUST be NULL. id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } -- ============= -- Constants -- ============= nullOctetString OCTET STRING (SIZE (0)) ::= ''H nullParameters NULL ::= NULL -- ========================= -- Algorithm Identifiers -- ========================= sha1Identifier AlgorithmIdentifier ::= { algorithm id-sha1, parameters nullParameters } sha224Identifier AlgorithmIdentifier ::= { algorithm id-sha224, parameters nullParameters } sha256Identifier AlgorithmIdentifier ::= { algorithm id-sha256, parameters nullParameters } Schaad, et al. Standards Track [Page 16] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 sha384Identifier AlgorithmIdentifier ::= { algorithm id-sha384, parameters nullParameters }Schaad, Kaliski & Housley Page 15sha512Identifier AlgorithmIdentifier ::= { algorithm id-sha512, parameters nullParameters } mgf1SHA1Identifier AlgorithmIdentifier ::= { algorithm id-mgf1, parameters sha1Identifier } mgf1SHA224Identifier AlgorithmIdentifier ::= { algorithm id-mgf1, parameters sha224Identifier } mgf1SHA256Identifier AlgorithmIdentifier ::= { algorithm id-mgf1, parameters sha256Identifier } mgf1SHA384Identifier AlgorithmIdentifier ::= { algorithm id-mgf1, parameters sha384Identifier } mgf1SHA512Identifier AlgorithmIdentifier ::= { algorithm id-mgf1, parameters sha512Identifier } pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= { algorithm id-pSpecified, parameters nullOctetString } rSASSA-PSS-Default-Params RSASSA-PSS-params ::= { hashAlgorithm sha1Identifier, maskGenAlgorithm mgf1SHA1Identifier, saltLength 20, trailerField 1 } rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters rSASSA-PSS-Default-Params } rSASSA-PSS-SHA224-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters rSASSA-PSS-SHA224-Params } Schaad, et al. Standards Track [Page 17] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 rSASSA-PSS-SHA224-Params RSASSA-PSS-params ::= { hashAlgorithm sha224Identifier, maskGenAlgorithm mgf1SHA224Identifier, saltLength 20, trailerField 1 } rSASSA-PSS-SHA256-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters rSASSA-PSS-SHA256-Params }Schaad, Kaliski & Housley Page 16rSASSA-PSS-SHA256-Params RSASSA-PSS-params ::= { hashAlgorithm sha256Identifier, maskGenAlgorithm mgf1SHA256Identifier, saltLength 20, trailerField 1 } rSASSA-PSS-SHA384-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters rSASSA-PSS-SHA384-Params } rSASSA-PSS-SHA384-Params RSASSA-PSS-params ::= { hashAlgorithm sha384Identifier, maskGenAlgorithm mgf1SHA384Identifier, saltLength 20, trailerField 1 } rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters rSSASSA-PSS-SHA512-params } rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { hashAlgorithm sha512Identifier, maskGenAlgorithm mgf1SHA512Identifier, saltLength 20, trailerField 1 } rSAES-OAEP-Default-Params RSAES-OAEP-params ::= { hashFunc sha1Identifier, maskGenFunc mgf1SHA1Identifier, pSourceFunc pSpecifiedEmptyIdentifier } rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= { algorithm id-RSAES-OAEP, parameters rSAES-OAEP-Default-Params } rSAES-OAEP-SHA224-Identifier AlgorithmIdentifier ::= { algorithm id-RSAES-OAEP, parameters rSAES-OAEP-SHA224-Params } Schaad, et al. Standards Track [Page 18] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 rSAES-OAEP-SHA224-Params RSAES-OAEP-params ::= { hashFunc sha224Identifier, maskGenFunc mgf1SHA224Identifier, pSourceFunc pSpecifiedEmptyIdentifier } rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::= { algorithm id-RSAES-OAEP, parameters rSAES-OAEP-SHA256-Params } rSAES-OAEP-SHA256-Params RSAES-OAEP-params ::= { hashFunc sha256Identifier,Schaad, Kaliski & Housley Page 17maskGenFunc mgf1SHA256Identifier, pSourceFunc pSpecifiedEmptyIdentifier } rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::= { algorithm id-RSAES-OAEP, parameters rSAES-OAEP-SHA384-Params } rSAES-OAEP-SHA384-Params RSAES-OAEP-params ::= { hashFunc sha384Identifier, maskGenFunc mgf1SHA384Identifier, pSourceFunc pSpecifiedEmptyIdentifier } rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::= { algorithm id-RSAES-OAEP, parameters rSAES-OAEP-SHA512-Params } rSAES-OAEP-SHA512-Params RSAES-OAEP-params ::= { hashFunc sha512Identifier, maskGenFunc mgf1SHA512Identifier, pSourceFunc pSpecifiedEmptyIdentifier } -- =================== -- Main structures -- =================== -- Used in SubjectPublicKeyInfo of X.509 Certificate. RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e Schaad, et al. Standards Track [Page 19] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 -- AlgorithmIdentifier parameters for id-RSASSA-PSS. -- Note that the tags in this Sequence are explicit. RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } HashAlgorithm ::= AlgorithmIdentifier MaskGenAlgorithm ::= AlgorithmIdentifier -- AlgorithmIdentifier parameters for id-RSAES-OAEP. -- Note that the tags in this Sequence are explicit. RSAES-OAEP-params ::= SEQUENCE {Schaad, Kaliski & Housley Page 18hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, pSourceFunc [2] AlgorithmIdentifier DEFAULT pSpecifiedEmptyIdentifier } END77. ReferencesThis section provides normative and informative references. 7.17.1. Normative References [P1v1.5] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998. [P1v2.1] Jonsson,J.,J. and B. Kaliski, "PKCS #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [PROFILE] Housley, R., Polk, W., Ford,W.W., and D. Solo, "Internet X.509 Public KeyInfrastructure:Infrastructure Certificate andCRLCertificate Revocation List (CRL) Profile", RFC 3280, April 2002. [SHA2] National Institute of Standards and Technology (NIST), FIPS 180-2: Secure Hash Standard, 1 August 2002. [SHA224] Housley,R,R., "A 224-bit One-way Hash Function:SHA-224", draft-ietf-pkix-sha224-00.txt, December 2003.SHA- 224", RFC 3874, September 2004. Schaad, et al. Standards Track [Page 20] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 [STDWORDS]S.Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [X.208-88] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988. [X.209-88] CCITT Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), 1988. [X.509-88] CCITT Recommendation X.509: The Directory - AuthenticationFramework.Framework, 1988.7.27.2. Informative References [CMS] Housley,R,R., "Cryptographic MessageSyntax",Syntax (CMS)", RFC3369, August 2002. Schaad, Kaliski & Housley Page 193852, July 2004. [GUIDE] National Institute of Standards and Technology, Second Draft: "Key Management Guideline, Part 1: General Guidance." June 2002. [http://csrc.nist.gov/encryption/kms/guideline-1.pdf][P1363a] IEEE P1363 working group,[P1363A] IEEEP1363a D11:Std 1363a-2004, Standard Specifications for Public KeyCryptography:Cryptography - Amendment 1: Additional Techniques,December 16, 2002 Available from http://grouper.ieee.org/groups/1363/.2004. [PKALGS] Bassham, L., Polk, W.,Housley, R.,andL. Bassham,R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate RevocationListsList (CRL) Profile", RFC 3279, April 2002. [RANDOM]Eastlake,Eastlake 3rd, D., Crocker,S.S., and J. Schiller, "Randomness Recommendations forSecurity,Security", RFC 1750, December 1994.8[SHA-1-ATTACK] Wang, X., Yin, Y.L., and H. Yu, "Finding Collisions in the Full SHA1", to appear, CRYPTO 2005. Preprint available at http://theory.csail.mit.edu/~yiqun/shanote.pdf. 8. Security Considerations This specification supplements RFC 3280 [PROFILE]. Thesecurity considerationsSecurity Considerations section of that document applies to this specification as well. Schaad, et al. Standards Track [Page 21] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 Implementations must protect the RSA private key.Compromise ofCompromising the RSA private key may result in the disclosure of all messages protected with that key. The generation of RSA public/private key pairs relies on a random numbers.The use ofUsing inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced thekeys, searchingkeys and search the resulting small set of possibilities,ratherthan to brute forcesearchingsearch the whole key space. The generation of quality random numbers isdifficult.difficult and RFC 1750 [RANDOM] offers important guidance in this area. Generally, good cryptographic practice employs a given RSA key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security. While PKCS #1 Version 1.5 [P1v1.5] has been employed for both key transport and digital signature without any known bad interactions, such a combined use of an RSA key pair is not recommended in the future. Therefore, an RSA key pair used for RSASSA-PSS signature generation should notalsobe used for other purposes. For similar reasons, one RSA key pair should always be used with the same RSASSA-PSSparameters.parameters (except possibly for the salt length). Likewise, an RSA key pair used forRSAES- OAEPRSAES-OAEP key transport should notalsobe used for other purposes. For similar reasons, one RSA key pair should always be used with the sameRSAES-OAEPRSAES- OAEP parameters.Schaad, Kaliski & Housley Page 20This specification requires implementations to support the SHA-1 one-way hash function for interoperability, but support for other one-way hashfunctionfunctions is permitted.At the time of this writing, the best (known)Wang et al. [SHA-1-ATTACK] have recently discovered a collisionattacksattack against SHA-1are generic attackswith complexity2^80, where 80 is one-half2^69. This attack, which can produce two new messages with the same hash value, is the first attack on SHA-1 faster than the generic attack with complexity 2^80, where 80 is one-half the bit length of the hash value. In general, when a one-way hash function is used with a digital signature scheme, a collision attack is easily translated into a signature forgery. Therefore,the use ofusing SHA-1 in a digital signature scheme provides a security level of no more than 69 bits if the attacker can persuade the signer to sign a message resulting from a collision attack. If the attacker can't persuade the signer to sign such a message, however, then SHA-1 still provides a security level of at least 80bits.bits since the best (known) inversion attack (which produces a new message with a previous hash value) is the generic attack with complexity 2^160. If a greater level of security is desired, then a secure one-way hash function with a longer hash value Schaad, et al. Standards Track [Page 22] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 is needed. SHA-256, SHA-384, and SHA-512 are reasonable choices[SHA2].[SHA2], although their security needs to be reconfirmed in light of the SHA-1 results. The metrics for choosing a one-way hash function for use in digital signatures do not directly apply to the RSAES-OAEP key transport algorithm, since a collision attack on the one-way hash function does not directly translate into an attack on the key transport algorithm, unless the encoding parameters Pvariesvary (in which case a collision of the hash value for different encoding parameters might be exploited). Nevertheless, for consistency with the practice for digital signature schemes, and in case the encoding parameters P is not the empty string, it is recommended that the same rule of thumb be applied toselection ofselecting a one-way hash function for use withRSAES- OAEP.RSAES-OAEP. That is, the one-way hash function should be selected so that the bit length of the hash value is at least twice as long as the desired security level in bits. The key size selected impacts the strength achieved when implementing cryptographic services. Thus,selection ofselecting appropriate key sizes is critical to implementing appropriate security. A1024- bit1024-bit RSA public keyand SHA-1 bothis considered to provide a security level of about 80 bits. In [GUIDE], the National Institute of Standards and Technology (NIST)suggestsuggests that a security level of 80 bits is adequate for the protection of sensitive information until 2015. This recommendation is likely to be revised based on recent advances, andthe revised recommendationis expected to be more conservative, suggesting that a security level of 80 bits is adequatefor theprotection of sensitive information until 2010. If a security level greater than 80 bits is needed, then a longer RSA public key and a secure one-way hash function with a longer hash value are needed. SHA-224, SHA-256, SHA-384, and SHA-512 are reasonable choices for such a one-way hashfunction and, forfunction, modulo the reconfirmation noted above. For this reason, the algorithm identifiers for these one-way hash functions are included in the ASN.1 module insectionSection 6. Current implementations MUST support 1024-bit RSA public key sizes. Before the end of 2007, implementations SHOULD support RSA public key sizes of at least 2048 bits and SHOULD support SHA-256. ThisSchaad, Kaliski & Housley Page 21requirement is intended to allow adequate time for users to deploy the stronger digital signature capability by 2010. When using RSASSA-PSS, the same one-way hash function should be employed for the hashAlgorithm and the maskGenAlgorithm, but it is not required.Using the same one-way hash function helps with security analysis, and it reduces implementation complexity.When using RSAES-OAEP, the same one-way hash function Schaad, et al. Standards Track [Page 23] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 should be employed for the hashFunc and the maskGenFunc, but it is not required. In each case, using the same one-way hash function helps with securityanalysis,analysis anditreduces implementation complexity.99. IANA Considerations Within the certificates and CRLs, algorithms are identified by object identifiers. Allof theobject identifiers used in this document were assigned in Public-Key Cryptography Standards (PKCS) documents or by the National Institute of Standards and Technology (NIST). No further action by the IANA is necessary for this document or any anticipated updates.10 AuthorAuthors' Addresses Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Burt Kaliski RSA Laboratories 174 Middlesex Turnpike Bedford, MA 01730 USA EMail: bkaliski@rsasecurity.com Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251 USA EMail: jimsch@exmsft.com11Schaad, et al. Standards Track [Page 24] RFC 4055 Additional RSA Algorithms and Identifiers June 2005 Full Copyright Statement Copyright (C) The Internet Society(2004). All Rights Reserved.(2005). This documentand translations of it may be copied and furnishedis subject toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published Schaad, Kaliski & Housley Page 22 and distributed, in whole or in part, without restriction of any kind, provided thattheabove copyright notice and this paragraph are included on all such copiesrights, licenses andderivative works. In addition, the ASN.1 modules presented in Section 5 may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modifiedrestrictions contained inany way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,BCP 78, and except asneeded for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked byset forth therein, theInternet Society or its successors or assigns.authors retain all their rights. This document and the information contained hereinisare provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCEDISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schaad,Kaliski & Housley Page 23et al. Standards Track [Page 25] ----