doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc3560.txt b/doc/rfc/rfc3560.txt
new file mode 100644
index 0000000..9051e9b
--- /dev/null
+++ b/doc/rfc/rfc3560.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         R. Housley
+Request for Comments: 3560                                Vigil Security
+Category: Standards Track                                      July 2003
+
+
+            Use of the RSAES-OAEP Key Transport Algorithm in
+                 the Cryptographic Message Syntax (CMS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes the conventions for using the RSAES-OAEP key
+   transport algorithm with the Cryptographic Message Syntax (CMS).  The
+   CMS specifies the enveloped-data content type, which consists of an
+   encrypted content and encrypted content-encryption keys for one or
+   more recipients.  The RSAES-OAEP key transport algorithm can be used
+   to encrypt content-encryption keys for intended recipients.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Enveloped-data Conventions . . . . . . . . . . . . . . . . . .  3
+       2.1.  EnvelopedData Fields . . . . . . . . . . . . . . . . . .  3
+       2.2.  KeyTransRecipientInfo Fields . . . . . . . . . . . . . .  4
+   3.  RSAES-OAEP Algorithm Identifiers and Parameters. . . . . . . .  4
+   4.  Certificate Conventions. . . . . . . . . . . . . . . . . . . .  6
+   5.  SMIMECapabilities Attribute Conventions. . . . . . . . . . . .  8
+   6.  Security Considerations. . . . . . . . . . . . . . . . . . . .  9
+   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Intellectual Property Rights Statement . . . . . . . . . . . . 11
+   9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 11
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+       10.1.  Normative References. . . . . . . . . . . . . . . . . . 11
+       10.2.  Informative References. . . . . . . . . . . . . . . . . 12
+   Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 14
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 18
+
+
+
+Housley                     Standards Track                     [Page 1]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+1.  Introduction
+
+   PKCS #1 Version 1.5 [PKCS#1v1.5] specifies a widely deployed variant
+   of the RSA key transport algorithm.  PKCS #1 Version 1.5 key
+   transport is vulnerable to adaptive chosen ciphertext attacks,
+   especially when it is used to for key management in interactive
+   applications.  This attack is often referred to as the "Million
+   Message Attack," and it explained in [RSALABS] and [CRYPTO98].
+   Exploitation of this vulnerability, which reveals the result of a
+   particular RSA decryption, requires access to an oracle which will
+   respond to hundreds of thousands of ciphertexts, which are
+   constructed adaptively in response to previously received replies
+   that provide information on the successes or failures of attempted
+   decryption operations.
+
+   The attack is significantly less feasible in store-and-forward
+   environments, such as S/MIME.  RFC 3218 [MMA] discussed the
+   countermeasures to this attack that are available when PKCS #1
+   Version 1.5 key transport is used in conjunction with the
+   Cryptographic Message Syntax (CMS) [CMS].
+
+   When PKCS #1 Version 1.5 key transport is applied as an intermediate
+   encryption layer within an interactive request-response
+   communications environment, exploitation could be more feasible.
+   However, Secure Sockets Layer (SSL) [SSL] and Transport Layer
+   Security (TLS) [TLS] protocol implementations could include
+   countermeasures that detect and prevent the Million Message Attack
+   and other chosen-ciphertext attacks.  These countermeasures are
+   performed within the protocol level.
+
+   In the interest of long-term security assurance, it is prudent to
+   adopt an improved cryptographic technique rather than embedding
+   countermeasures within protocols.  To this end, an updated version of
+   PKCS #1 has been published.  PKCS #1 Version 2.1 [PKCS#1v2.1]
+   supersedes RFC 2313.  It preserves support for the PKCS #1 Version
+   1.5 encryption padding format, and it also defines a new one.  To
+   resolve the adaptive chosen ciphertext vulnerability, the PKCS #1
+   Version 2.1 specifies and recommends use of Optimal Asymmetric
+   Encryption Padding (OAEP) for RSA key transport.
+
+   This document specifies the use of RSAES-OAEP key transport algorithm
+   in the CMS.  The CMS can be used in either a store-and-forward or an
+   interactive request-response environment.
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 2]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   The CMS supports variety of architectures for certificate-based key
+   management, particularly the one defined by the PKIX working group
+   [PROFILE].  PKCS #1 Version 1.5 and PKCS #1 Version 2.1 require the
+   same RSA public key information.  Thus, a certified RSA public key
+   may be used with either RSA key transport technique.
+
+   The CMS uses ASN.1 [X.208-88], the Basic Encoding Rules (BER)
+   [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88].
+
+   Throughout this document, when the terms "MUST", "MUST NOT",
+   "SHOULD", and "MAY" are used in capital letters, their use conforms
+   to the definitions in RFC 2119 [STDWORDS].  These key word
+   definitions help make the intent of standards documents as clear as
+   possible.  These key words are used in this document to help
+   implementers achieve interoperability.
+
+2.  Enveloped-data Conventions
+
+   The CMS enveloped-data content type consists of an encrypted content
+   and wrapped content-encryption keys for one or more recipients.  The
+   RSAES-OAEP key transport algorithm is used to wrap the
+   content-encryption key for one recipient.
+
+   Compliant software MUST meet the requirements for constructing an
+   enveloped-data content type stated in [CMS] Section 6,
+   "Enveloped-data Content Type".
+
+   A content-encryption key MUST be randomly generated for each instance
+   of an enveloped-data content type.  The content-encryption key is
+   used to encipher the content.
+
+2.1.  EnvelopedData Fields
+
+   The enveloped-data content type is ASN.1 encoded using the
+   EnvelopedData syntax.  The fields of the EnvelopedData syntax MUST be
+   populated as described in this section when RSAES-OAEP key transport
+   is employed for one or more recipients.
+
+   The EnvelopedData version MUST be 0, 2, or 3.
+
+   The EnvelopedData originatorInfo field is not used for the RSAES-OAEP
+   key transport algorithm.  However, this field MAY be present to
+   support recipients using other key management algorithms.
+
+   The EnvelopedData recipientInfos CHOICE MUST be
+   KeyTransRecipientInfo.  See section 2.2 for further discussion of
+   KeyTransRecipientInfo.
+
+
+
+
+Housley                     Standards Track                     [Page 3]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm
+   field MUST be a symmetric encryption algorithm identifier.
+
+   The EnvelopedData unprotectedAttrs MAY be present.
+
+2.2.  KeyTransRecipientInfo Fields
+
+   The fields of the KeyTransRecipientInfo syntax MUST be populated as
+   described in this section when RSAES-OAEP key transport is employed
+   for one or more recipients.
+
+   The KeyTransRecipientInfo version MUST be 0 or 2.  If the
+   RecipientIdentifier uses the issuerAndSerialNumber alternative, then
+   the version MUST be 0.  If the RecipientIdentifier uses the
+   subjectKeyIdentifier alternative, then the version MUST be 2.
+
+   The KeyTransRecipientInfo RecipientIdentifier provides two
+   alternatives for specifying the recipient's certificate, and thereby
+   the recipient's public key.  The recipient's certificate MUST contain
+   a RSA public key.  The content-encryption key is encrypted with the
+   recipient's RSA public key.  The issuerAndSerialNumber alternative
+   identifies the recipient's certificate by the issuer's distinguished
+   name and the certificate serial number; the subjectKeyIdentifier
+   identifies the recipient's certificate by the X.509
+   subjectKeyIdentifier extension value.
+
+   The KeyTransRecipientInfo keyEncryptionAlgorithm specifies use of the
+   RSAES-OAEP algorithm, and its associated parameters, to encrypt the
+   content-encryption key for the recipient.  The key-encryption process
+   is described in [PKCS#1v2.1].  See section 3 of this document for the
+   algorithm identifier and the parameter syntax.
+
+   The KeyTransRecipientInfo encryptedKey is the result of encrypting
+   the content-encryption key in the recipient's RSA public key using
+   the RSAES-OAEP algorithm.  The RSA public key MUST be at least 1024
+   bits in length.  When using a Triple-DES [3DES] content-encryption
+   key, implementations MUST adjust the parity bits to ensure odd parity
+   for each octet of each DES key comprising the Triple-DES key prior to
+   RSAES-OAEP encryption.
+
+3.  RSAES-OAEP Algorithm Identifiers and Parameters
+
+   The RSAES-OAEP key transport algorithm is the RSA encryption scheme
+   defined in RFC 3447 [PKCS#1v2.1], where the message to be encrypted
+   is the content-encryption key.  The algorithm identifier for
+   RSAES-OAEP is:
+
+
+
+
+
+Housley                     Standards Track                     [Page 4]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
+     us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
+
+   The AlgorithmIdentifier parameters field MUST be present, and the
+   parameters field MUST contain RSAES-OAEP-params.  RSAES-OAEP-params
+   has the following syntax:
+
+   RSAES-OAEP-params  ::=  SEQUENCE  {
+     hashFunc    [0] AlgorithmIdentifier DEFAULT sha1Identifier,
+     maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier,
+     pSourceFunc [2] AlgorithmIdentifier DEFAULT
+                         pSpecifiedEmptyIdentifier  }
+
+   sha1Identifier  AlgorithmIdentifier  ::=  { id-sha1, NULL }
+
+   mgf1SHA1Identifier  AlgorithmIdentifier  ::=
+                         { id-mgf1, sha1Identifier }
+
+   pSpecifiedEmptyIdentifier  AlgorithmIdentifier ::=
+                         { id-pSpecified, nullOctetString }
+
+   nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }
+
+   id-sha1  OBJECT IDENTIFIER  ::=  { iso(1)
+                         identified-organization(3) oiw(14)
+                         secsig(3) algorithms(2) 26 }
+
+   pkcs-1  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
+                         us(840) rsadsi(113549) pkcs(1) pkcs-1(1) }
+
+   id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }
+
+   id-pSpecified  OBJECT IDENTIFIER  ::=  { pkcs-1 9 }
+
+   The fields within RSAES-OAEP-params have the following meanings:
+
+   hashFunc identifies the one-way hash function.  Implementations MUST
+   support SHA-1 [SHA1], and implementations MAY support other one-way
+   hash functions.  The SHA-1 algorithm identifier is comprised of the
+   id-sha1 object identifier and a parameter of NULL.  Implementations
+   that perform encryption MUST omit the hashFunc field when SHA-1 is
+   used, indicating that the default algorithm was used.
+   Implementations that perform decryption MUST recognize both the
+   id-sha1 object identifier and an absent hashFunc field as an
+   indication that SHA-1 was used.
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 5]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   maskGenFunc identifies the mask generation function.  Implementations
+   MUST support MFG1 [PKCS#1v2.1].  MFG1 requires a one-way hash
+   function, and it is identified in the parameter field of the MFG1
+   algorithm identifier.  Implementations MUST support SHA-1 [SHA1], and
+   implementations MAY support other one-way hash functions.  The MFG1
+   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 MFG1.  The SHA-1 algorithm identifier is
+   comprised of the id-sha1 object identifier and a parameter of NULL.
+   Implementations that perform encryption MUST omit the maskGenFunc
+   field when MFG1 with SHA-1 is used, indicating that the default
+   algorithm was used. Implementations that perform decryption MUST
+   recognize both the id-mgf1 and id-sha1 object identifiers as well as
+   an absent maskGenFunc field as an indication that MFG1 with SHA-1 was
+   used.
+
+   pSourceFunc identifies the source (and possibly the value) of the
+   encoding parameters, commonly called P.  Implementations MUST
+   represent P by the algorithm identifier, id-pSpecified, indicating
+   that P is explicitly provided as an OCTET STRING in the parameters.
+   The default value for P is an empty 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.
+
+4.  Certificate Conventions
+
+   RFC 3280 [PROFILE] specifies the profile for using X.509 Certificates
+   in Internet applications.  When a RSA public key will be used for
+   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 in the Security Considerations section of
+   this document (see section 6), the certificate user needs to be able
+   to determine the form of 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 RSAES-OAEP.  In this case, the
+
+
+
+
+
+Housley                     Standards Track                     [Page 6]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   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
+   [CERTALGS], section 2.3.1).
+
+   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 the parameters field MUST contain
+   RSAES-OAEP-params.  The id-RSAES-OAEP object identifier value and the
+   RSAES-OAEP-params syntax are fully described in section 3 of this
+   document.
+
+   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  }  -- e
+
+   Here, 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 the key
+   usage certificate extension (see [PROFILE], section 4.2.1.3).  If the
+   keyUsage extension is present in a certificate that conveys an RSA
+   public key with the id-RSAES-OAEP object identifier, then the key
+   usage extension MUST contain a combination of 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 the
+   id-RSAES-OAEP object identifier, the certificate user MUST only use
+   the certified RSA public key for RSAES-OAEP operations, and the
+   certificate user MUST perform those operations using the parameters
+   identified in the certificate.
+
+
+
+Housley                     Standards Track                     [Page 7]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+5.  SMIMECapabilities Attribute Conventions
+
+   RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed
+   attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be
+   used to specify a partial list of algorithms that the software
+   announcing the SMIMECapabilities can support.  When constructing a
+   signedData object, compliant software MAY include the
+   SMIMECapabilities signed attribute announcing that it supports the
+   RSAES-OAEP algorithm.
+
+   When all of the default settings are selected, the SMIMECapability
+   SEQUENCE representing RSAES-OAEP MUST include the id-RSAES-OAEP
+   object identifier in the capabilityID field and MUST include an empty
+   SEQUENCE in the parameters field.  In this case, RSAES-OAEP is
+   represented by the rSAES-OAEP-Default-Identifier:
+
+   rSAES-OAEP-Default-Identifier  AlgorithmIdentifier  ::=
+                         { id-RSAES-OAEP,
+                            { sha1Identifier,
+                              mgf1SHA1Identifier,
+                              pSpecifiedEmptyIdentifier } }
+
+   The SMIMECapability SEQUENCE representing rSAES-OAEP-Default-
+   Identifier MUST be DER-encoded as the following hexadecimal string:
+
+      30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00
+
+   When settings other than the defaults are selected, the
+   SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the
+   id-RSAES-OAEP object identifier in the capabilityID field and MUST
+   include the RSAES-OAEP-params SEQUENCE that identifies the
+   non-default settings in the parameters field.
+
+   When SHA-256 is used in the hashFunc and SHA-256 is used with MGF1 in
+   the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP
+   is the rSAES-OAEP-SHA256-Identifier, as specified in Appendix A.  The
+   SMIMECapability SEQUENCE representing rSAES-OAEP-SHA256-Identifier
+   MUST be DER-encoded as the following hexadecimal string:
+
+      30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30
+      0D 06 09 60 86 48 01 65 03 04 02 01 05 00 30 1A
+      06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60
+      86 48 01 65 03 04 02 01 05 00
+
+   When SHA-384 is used in the hashFunc and SHA-384 is used with MGF1 in
+   the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP
+   is the rSAES-OAEP-SHA384-Identifier, as specified in Appendix A.  The
+
+
+
+
+Housley                     Standards Track                     [Page 8]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   SMIMECapability SEQUENCE representing rSAES-OAEP-SHA384-Identifier
+   MUST be DER-encoded as the following hexadecimal string:
+
+      30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30
+      0D 06 09 60 86 48 01 65 03 04 02 02 05 00 30 1A
+      06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60
+      86 48 01 65 03 04 02 02 05 00
+
+   When SHA-512 is used in the hashFunc and SHA-512 is used with MGF1 in
+   the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP
+   is the rSAES-OAEP-SHA512-Identifier, as specified in Appendix A.  The
+   SMIMECapability SEQUENCE representing rSAES-OAEP-SHA512-Identifier
+   MUST be DER-encoded as the following hexadecimal string:
+
+      30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30
+      0D 06 09 60 86 48 01 65 03 04 02 03 05 00 30 1A
+      06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60
+      86 48 01 65 03 04 02 03 05 00
+
+6.  Security Considerations
+
+   Implementations must protect the RSA private key and the
+   content-encryption key.  Compromise of the RSA private key may result
+   in the disclosure of all messages protected with that key.
+   Compromise of the content-encryption key may result in disclosure of
+   the associated encrypted content.
+
+   The generation of RSA public/private key pairs relies on a random
+   numbers.  The use of 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 the keys, searching the resulting small set
+   of possibilities, rather than brute force searching the whole key
+   space.  The generation of quality random numbers is difficult.  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
+   [PKCS#1v1.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 RSAES-OAEP key transport should not also be used
+   for other purposes.  For similar reasons, one RSA key pair should
+   always be used with the same RSAES-OAEP parameters.
+
+
+
+
+
+Housley                     Standards Track                     [Page 9]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   This specification requires implementation to support the SHA-1
+   one-way hash function for interoperability, but support for other
+   one-way hash function is permitted.  At the time of this writing, the
+   best (known) collision attacks against SHA-1 are generic attacks with
+   complexity 2^80, where 80 is one-half the bit length of the hash
+   value.  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 of SHA-1 in a digital signature scheme
+   provides a security level of no more than 80 bits.  If a greater
+   level of security is desired, then a secure one-way hash function
+   with a longer hash value is needed.  SHA-256, SHA-384, and SHA-512
+   are likely candidates [SHA2].
+
+   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 P varies (in which case a collision
+   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 to
+   selection of a one-way hash function for use with 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.
+
+   A 1024-bit RSA public key and SHA-1 both provide a security level of
+   about 80 bits.  In [NISTGUIDE], the National Institute of Standards
+   and Technology suggests that a security level of 80 bits is adequate
+   for most applications until 2015.  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.  Again, SHA-256,
+   SHA-384, and SHA-512 are likely candidates for such a one-way hash
+   function.  For this reason, the algorithm identifiers for these
+   one-way hash functions are included in the ASN.1 module in Appendix
+   A.
+
+   The same one-way hash function should be employed for the hashFunc
+   and the maskGenFunc, but it is not required.  Using the same one-way
+   hash function reduces the potential for implementation errors.
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 10]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+7.  IANA Considerations
+
+   Within the CMS, algorithms are identified by object identifiers
+   (OIDs).  All of the OIDs 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.
+
+8.  Intellectual Property Rights Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+9.  Acknowledgments
+
+   This document is the result of contributions from many professionals.
+   I appreciate the hard work of all members of the IETF S/MIME Working
+   Group.  Further, I extend a special thanks to Burt Kaliski, Jakob
+   Jonsson, Francois Rousseau, and Jim Schaad.
+
+10.  References
+
+   This section provides normative and informative references.
+
+10.1.  Normative References
+
+   [3DES]        American National Standards Institute.  ANSI X9.52-
+                 1998, Triple Data Encryption Algorithm Modes of
+                 Operation.  1998.
+
+
+
+
+
+Housley                     Standards Track                    [Page 11]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   [CMS]         Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                 3369, August 2002.
+
+   [MSG]         Ramsdell, B., "S/MIME Version 3 Message Specification",
+                 RFC 2633, June 1999.
+
+   [PKCS#1v2.1]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+                 Standards (PKCS) #1: RSA Cryptography Specifications,
+                 Version 2.1", RFC 3447, February 2003.
+
+   [PROFILE]     Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+                 X.509 Public Key Infrastructure: Certificate and
+                 Certificate Revocation List (CRL) Profile", RFC 3280,
+                 April 2002.
+
+   [SHA1]        National Institute of Standards and Technology.  FIPS
+                 Pub 180-1: "Secure Hash Standard."  April 1995.
+
+   [STDWORDS]    Bradner, S., "Key Words for Use in RFCs to Indicate
+                 Requirement Levels", BCP 14, 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 -
+                 Authentication Framework.  1988.
+
+10.2.  Informative References
+
+   [CERTALGS]    Bassham, L., Polk, W. and R. Housley, "Algorithms and
+                 Identifiers for the Internet X.509 Public Key
+                 Infrastructure Certificate and Certificate Revocation
+                 List (CRL) Profile", RFC 3279, April 2002.
+
+   [CRYPTO98]    Bleichenbacher, D.  "Chosen Ciphertext Attacks Against
+                 Protocols Based on the RSA Encryption Standard PKCS
+                 #1", in H. Krawczyk (editor), Advances in Cryptology -
+                 CRYPTO '98 Proceedings, Lecture Notes in Computer
+                 Science 1462 (1998), Springer-Verlag, pp. 1-12.
+
+   [MMA]         Rescorla, E., "Preventing the Million Message Attack on
+                 Cryptographic Message Syntax", RFC 3218, January 2002.
+
+
+
+
+
+Housley                     Standards Track                    [Page 12]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   [NISTGUIDE]   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]
+
+   [PKCS#1v1.5]  Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5",
+                 RFC 2313, March 1998.
+
+   [RANDOM]      Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+                 Recommendations for Security", RFC 1750, December 1994.
+
+   [RSALABS]     Bleichenbacher, D., B. Kaliski, and J. Staddon.  Recent
+                 Results on PKCS #1: RSA Encryption Standard.  RSA
+                 Laboratories' Bulletin No. 7, June 26, 1998.
+                 [http://www.rsasecurity.com/rsalabs/bulletins]
+
+   [SHA2]        National Institute of Standards and Technology.  Draft
+                 FIPS Pub 180-2: "Specifications for the Secure Hash
+                 Standard."  May 2001.
+                 [http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf]
+
+   [SSL]         Freier, A., P. Karlton, and P. Kocher.  The SSL
+                 Protocol, Version 3.0.  Netscape Communications.
+                 November 1996.
+                 [http://wp.netscape.com/eng/ssl3/draft302.txt]
+
+   [TLS]         Dierks, T. and C. Allen, "The TLS Protocol Version
+                 1.0", RFC 2246, January 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 13]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+Appendix A.  ASN.1 Module
+
+   CMS-RSAES-OAEP
+      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+        pkcs-9(9) smime(16) modules(0) cms-rsaes-oaep(20) }
+
+   DEFINITIONS IMPLICIT TAGS ::= BEGIN
+
+   -- EXPORTS ALL --
+
+   IMPORTS
+      AlgorithmIdentifier
+          FROM PKIX1Explicit88 -- RFC 3280
+          { iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) mechanisms(5) pkix(7) id-mod(0)
+            id-pkix1-explicit(18) };
+
+   pkcs-1  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2) us(840)
+                         rsadsi(113549) pkcs(1) pkcs-1(1) }
+
+   rsaEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 1 }
+
+   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 }
+
+   sha1Identifier  AlgorithmIdentifier  ::=  { id-sha1, NULL }
+
+   sha256Identifier  AlgorithmIdentifier  ::=  { id-sha256, NULL }
+
+   sha384Identifier  AlgorithmIdentifier  ::=  { id-sha384, NULL }
+
+   sha512Identifier  AlgorithmIdentifier  ::=  { id-sha512, NULL }
+
+   mgf1SHA1Identifier  AlgorithmIdentifier  ::=
+                         { id-mgf1, sha1Identifier }
+
+   mgf1SHA256Identifier  AlgorithmIdentifier  ::=
+                         { id-mgf1, sha256Identifier }
+
+   mgf1SHA384Identifier  AlgorithmIdentifier  ::=
+                         { id-mgf1, sha384Identifier }
+
+
+
+
+Housley                     Standards Track                    [Page 14]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+   mgf1SHA512Identifier  AlgorithmIdentifier  ::=
+                         { id-mgf1, sha512Identifier }
+
+   pSpecifiedEmptyIdentifier  AlgorithmIdentifier ::=
+                         { id-pSpecified, nullOctetString }
+
+   nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }
+
+   id-sha1  OBJECT IDENTIFIER  ::=  { iso(1)
+                         identified-organization(3) oiw(14)
+                         secsig(3) algorithms(2) 26 }
+
+   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 }
+
+   id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }
+
+   id-pSpecified  OBJECT IDENTIFIER  ::=  { pkcs-1 9 }
+
+   rSAES-OAEP-Default-Identifier  AlgorithmIdentifier  ::=
+                         { id-RSAES-OAEP,
+                            { sha1Identifier,
+                              mgf1SHA1Identifier,
+                              pSpecifiedEmptyIdentifier } }
+
+   rSAES-OAEP-SHA256-Identifier  AlgorithmIdentifier  ::=
+                         { id-RSAES-OAEP,
+                            { sha256Identifier,
+                              mgf1SHA256Identifier,
+                              pSpecifiedEmptyIdentifier } }
+
+   rSAES-OAEP-SHA384-Identifier  AlgorithmIdentifier  ::=
+                         { id-RSAES-OAEP,
+                            { sha384Identifier,
+                              mgf1SHA384Identifier,
+                              pSpecifiedEmptyIdentifier } }
+
+   rSAES-OAEP-SHA512-Identifier  AlgorithmIdentifier  ::=
+                         { id-RSAES-OAEP,
+
+
+
+Housley                     Standards Track                    [Page 15]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+                            { sha512Identifier,
+                              mgf1SHA512Identifier,
+                              pSpecifiedEmptyIdentifier } }
+
+   END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 16]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+Author's Address
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+
+   EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 17]
+
+RFC 3560                   RSAES-OAEP in CMS                   July 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must 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 by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 18]
+