RFC 3560
Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)
RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS) 🎀
okay bestie, RFC 3560 is giving standards track energy 👑. It was written by R. Housley at Vigil Security and dated July 2003. The header doesn't list any RFCs it obsoletes or updates, so it stands on its own 🦋.
Status of This Memo ✨
This is an Internet standards track protocol document for the Internet community, and it's openly asking for discussion and suggestions for improvements 💌. If you want the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌸.
Copyright Notice 🌈
Copyright (C) The Internet Society (2003). All Rights Reserved. 💅
Abstract 🦋
This doc explains how to use the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS) 🔐. CMS has the enveloped-data content type, which is basically encrypted content plus encrypted content-encryption keys for one or more recipients 📦. RSAES-OAEP can be used to encrypt those content-encryption keys for the people they're meant for 💖.
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 . . . . . . . . . . . . . . . . . . . . . 181. Introduction ✨
okay so, PKCS #1 Version 1.5 [PKCS#1v1.5] is a super widely deployed version of the RSA key transport algorithm 🌍. The problem is that it's vulnerable to adaptive chosen ciphertext attacks 😭, especially when it's used for key management in interactive applications. This is the attack everyone calls the "Million Message Attack," and it's explained in [RSALABS] and [CRYPTO98] 💀. To pull it off, you need an oracle that answers hundreds of thousands of ciphertexts, and those ciphertexts get built adaptively, based on earlier replies that tell you whether each decryption attempt worked or failed 🙈.
The attack is way less feasible in store-and-forward environments, like S/MIME 📬. RFC 3218 [MMA] talks about the countermeasures available when PKCS #1 Version 1.5 key transport is used with the Cryptographic Message Syntax (CMS) [CMS] 🛡️.
When PKCS #1 Version 1.5 key transport is applied as an intermediate encryption layer in an interactive request-response environment, exploitation could be more feasible 👀. That said, Secure Sockets Layer (SSL) [SSL] and Transport Layer Security (TLS) [TLS] implementations could include countermeasures that detect and prevent the Million Message Attack and other chosen-ciphertext attacks 🫶. Those countermeasures live at the protocol level.
For long-term security, it's smart to adopt an improved cryptographic technique instead of piling countermeasures into protocols 🧠. So an updated PKCS #1 has come out. PKCS #1 Version 2.1 [PKCS#1v2.1] supersedes RFC 2313 ✨. It keeps supporting the PKCS #1 Version 1.5 encryption padding format, and it also defines a new one. To fix the adaptive chosen ciphertext vulnerability, PKCS #1 Version 2.1 specifies and recommends Optimal Asymmetric Encryption Padding (OAEP) for RSA key transport 💜.
This document specifies how to use the RSAES-OAEP key transport algorithm in CMS 💅. CMS can be used in either a store-and-forward or an interactive request-response environment 🦋.
CMS supports a variety of architectures for certificate-based key management, especially 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, so a certified RSA public key can be used with either RSA key transport technique 🔑. Iconic compatibility, honestly.
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 words exist to make the intent of standards documents as clear as possible, and this document uses them to help implementers achieve interoperability 🤝.
2. Enveloped-data Conventions 💖
The CMS enveloped-data content type is encrypted content plus wrapped content-encryption keys for one or more recipients 🎁. RSAES-OAEP key transport 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" 📋. No skipping, bestie 🙅♀️.
A content-encryption key MUST be randomly generated for each instance of an enveloped-data content type 🎲. That key is what's used to encipher the content 🫧.
2.1. EnvelopedData Fields 🌷
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax 🧾. When RSAES-OAEP key transport is employed for one or more recipients, the fields of the EnvelopedData syntax MUST be populated as described in this section 💅.
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. Section 2.2 has more on KeyTransRecipientInfo 👀.
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm field MUST be a symmetric encryption algorithm identifier 🔑.
The EnvelopedData unprotectedAttrs MAY be present 🎀.
2.2. KeyTransRecipientInfo Fields 🦋
When RSAES-OAEP key transport is employed for one or more recipients, the fields of the KeyTransRecipientInfo syntax MUST be populated as described in this section 📝.
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 gives two ways to point at the recipient's certificate, and therefore the recipient's public key 🎯. The recipient's certificate MUST contain an RSA public key 🔑. The content-encryption key is encrypted with the recipient's RSA public key 🔐. The issuerAndSerialNumber alternative identifies the certificate by the issuer's distinguished name and the certificate serial number 📇. The subjectKeyIdentifier alternative identifies the certificate by the X.509 subjectKeyIdentifier extension value 🪪.
The KeyTransRecipientInfo keyEncryptionAlgorithm specifies RSAES-OAEP, along with 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 RSAES-OAEP 💌. The RSA public key MUST be at least 1024 bits in length 📏. When a Triple-DES [3DES] content-encryption key is used, implementations MUST adjust the parity bits so each octet of each DES key comprising the Triple-DES key has odd parity, and they MUST do this before RSAES-OAEP encryption 🫶.
3. RSAES-OAEP Algorithm Identifiers and Parameters ✨
okay so RSAES-OAEP is the key transport algorithm 🔐. It's the RSA encryption scheme from RFC 3447 [PKCS#1v2.1], and the thing being encrypted is the content-encryption key 🗝️. Its algorithm identifier is:
id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }bestie, the AlgorithmIdentifier parameters field MUST be present 💅, and the parameters field MUST contain RSAES-OAEP-params. Here's what RSAES-OAEP-params looks like:
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 }Now the fields inside RSAES-OAEP-params, and what each one means 🫶
hashFunc picks the one-way hash function 🧁. Implementations MUST support SHA-1 [SHA1], and they MAY support other one-way hash functions too. The SHA-1 identifier is made of the id-sha1 object identifier plus a parameter of NULL. If you're doing encryption, you MUST omit the hashFunc field when SHA-1 is used, which means "use the default" 💖. If you're doing decryption, you MUST recognize both the id-sha1 object identifier and a missing hashFunc field as meaning SHA-1, no cap.
maskGenFunc picks the mask generation function 🎀. Implementations MUST support MFG1 [PKCS#1v2.1]. MFG1 needs a one-way hash function, and that hash 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 made of the id-mgf1 object identifier and a parameter that holds the algorithm identifier of the one-way hash function used with MFG1. The SHA-1 identifier is made of the id-sha1 object identifier plus a parameter of NULL. If you're encrypting, you MUST omit the maskGenFunc field when MFG1 with SHA-1 is used, since that means "use the default" 🌸. If you're decrypting, you MUST recognize both the id-mgf1 and id-sha1 object identifiers, as well as a missing maskGenFunc field, as an indication that MFG1 with SHA-1 was used. Iconic behaviour 👑
pSourceFunc identifies the source (and possibly the value) of the encoding parameters, which everyone calls P 🦋. Implementations MUST represent P by the algorithm identifier id-pSpecified, which means P is explicitly provided as an OCTET STRING in the parameters. The default value for P is an empty string. In that case, pHash in EME-OAEP holds the hash of a zero length string. Implementations MUST support a zero length P value. If you're encrypting, you MUST omit the pSourceFunc field when a zero length P value is used, because that means the default value was used. If you're decrypting, you MUST recognize both the id-pSpecified object identifier and a missing pSourceFunc field as an indication that a zero length P value was used. 💅
4. Certificate Conventions
RFC 3280 [PROFILE] is the profile for using X.509 Certificates in Internet applications 📜. When a RSA public key is going to be used for RSAES-OAEP key transport, the conventions in this section add on top of RFC 3280.
Traditionally, the rsaEncryption object identifier is used to identify RSA public keys 🧁. But to implement all of the recommendations in the Security Considerations section of this document (see section 6), the certificate user needs to be able to tell what form of key transport the RSA private key owner associates with the public key 🔍. Main character energy, the certificate has to spill the tea 🫖.
The rsaEncryption object identifier still identifies the subject public key when the RSA private key owner does not want to limit the public key to RSAES-OAEP only 💜. In that 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 }For more on how the rsaEncryption object identifier is used, check RFC 3279 (see [CERTALGS], section 2.3.1) 📚.
When the RSA private key owner wants to limit the public key exclusively to RSAES-OAEP, 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 🌈.
No matter which object identifier is used, the RSA public key is encoded the same way 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 } -- eHere, 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 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 💖.
5. SMIMECapabilities Attribute Conventions
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute 💅. It's a SEQUENCE of SMIMECapability SEQUENCEs, and it's used to list a partial set of algorithms that the software announcing the SMIMECapabilities can support 🌸. When building a signedData object, compliant software MAY include the SMIMECapabilities signed attribute to announce 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 it 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 00When 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 it 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 00When 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 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 00When 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 006. Security Considerations 💀🔐
okay bestie, this part is SERIOUS. implementations must protect the RSA private key AND the content-encryption key. if the RSA private key gets compromised, every message protected with that key can be disclosed 😭. if the content-encryption key leaks, the encrypted content tied to it can be disclosed too.
generating RSA public/private key pairs relies on a random numbers. using inadequate pseudo-random number generators (PRNGs) to make crypto keys can end up with little or no security 🙈. an attacker may find it much easier to recreate the PRNG environment that made the keys and search that small set of possibilities, instead of brute forcing the whole key space. generating quality random numbers is genuinely hard. RFC 1750 [RANDOM] has important guidance on this, so go read it.
generally, good crypto practice uses a given RSA key pair in only one scheme 🎀. this avoids the risk that a vulnerability in one scheme compromises the other, and it may be essential to maintain provable security. PKCS #1 Version 1.5 [PKCS#1v1.5] has been used for both key transport and digital signatures without any known bad interactions, but combining an RSA key pair like that is not recommended in the future. so 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 ✨.
this spec requires implementations to support the SHA-1 one-way hash function for interoperability, but other one-way hash functions are permitted 🦋. at the time of 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 gets easily translated into a signature forgery 😱. so using SHA-1 in a digital signature scheme provides a security level of no more than 80 bits. if you want a greater level of security, you need a secure one-way hash function with a longer hash value. SHA-256, SHA-384, and SHA-512 are likely candidates [SHA2] 👑.
the metrics for picking a one-way hash function for digital signatures don't directly apply to the RSAES-OAEP key transport algorithm 🧚. a collision attack on the hash function doesn't 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).
still, 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 gets applied when choosing a one-way hash function for RSAES-OAEP 🍓. basically, 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 you need a security level greater than 80 bits, then you need a longer RSA public key and a secure one-way hash function with a longer hash value. again, SHA-256, SHA-384, and SHA-512 are likely candidates for that job. this is why 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 used for the hashFunc and the maskGenFunc, but it is not required. using the same one-way hash function reduces the potential for implementation errors 🫶.
7. IANA Considerations 🌸
within the CMS, algorithms get 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 on 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. it also doesn't say whether any license under those rights might or might not be available, and it doesn't represent that it has made any effort to identify any such rights. info on the IETF's procedures for rights in standards-track and standards-related documentation can be found in BCP-11. copies of claims of rights made available for publication, any assurances of licenses to be made available, or the result of an attempt to get 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 that info 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. I also 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.[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.[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.
Appendix A. ASN.1 Module 🎀
Okay bestie, this is the big ASN.1 module, the official dictionary that defines all the RSAES-OAEP identifiers and parameters we've been talking about 🧚 Every line is copied exactly, because the module is only useful if it's perfect ✨
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 }
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,
{ sha512Identifier,
mgf1SHA512Identifier,
pSpecifiedEmptyIdentifier } }
ENDAuthor's Address 💌
Here's where you can find the author, Russell Housley, over at Vigil Security, LLC 🦋
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
Okay so the legal bit, but make it cute: anyone can copy this document and share it, and people can make derivative works that comment on or explain it or help with implementing it, and they can publish and distribute those too, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph have to stay on every copy and derivative work. The document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: changes made for developing Internet standards (in which case the Internet Standards process copyright procedures must be followed), and translation into languages other than English. The limited permissions granted here are perpetual and will not be revoked by the Internet Society or its successors or assignees 💜
This document and the information in it 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 ✨
That's the whole RFC, bestie! 🌈💖
📦 where this page comes from
- ietf: rfc3560 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms