diff options
Diffstat (limited to 'doc/rfc/rfc9629.txt')
| -rw-r--r-- | doc/rfc/rfc9629.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc9629.txt b/doc/rfc/rfc9629.txt new file mode 100644 index 0000000..6508494 --- /dev/null +++ b/doc/rfc/rfc9629.txt @@ -0,0 +1,787 @@ + + + + +Internet Engineering Task Force (IETF) R. Housley +Request for Comments: 9629 Vigil Security +Updates: 5652 J. Gray +Category: Standards Track Entrust +ISSN: 2070-1721 大久保 智史 (T. Okubo) + Penguin Securities Pte. Ltd. + August 2024 + + +Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic + Message Syntax (CMS) + +Abstract + + The Cryptographic Message Syntax (CMS) supports key transport and key + agreement algorithms. In recent years, cryptographers have been + specifying Key Encapsulation Mechanism (KEM) algorithms, including + quantum-secure KEM algorithms. This document defines conventions for + the use of KEM algorithms by the originator and recipients to encrypt + and decrypt CMS content. This document updates RFC 5652. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9629. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Terminology + 1.2. ASN.1 + 1.3. CMS Version Numbers + 2. KEM Processing Overview + 3. KEM Recipient Information + 4. KEM Algorithm Identifier + 5. Key Derivation + 6. ASN.1 Modules + 6.1. KEMAlgorithmInformation-2023 ASN.1 Module + 6.2. CMS-KEMRecipientInfo-2023 ASN.1 Module + 7. Security Considerations + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + This document updates "Cryptographic Message Syntax (CMS)" [RFC5652]. + + The CMS enveloped-data content type [RFC5652] and the CMS + authenticated-enveloped-data content type [RFC5083] support both key + transport and key agreement algorithms to establish the key used to + encrypt and decrypt the content. In recent years, cryptographers + have been specifying Key Encapsulation Mechanism (KEM) algorithms, + including quantum-secure KEM algorithms. This document defines + conventions for the use of KEM algorithms for the CMS enveloped-data + content type and the CMS authenticated-enveloped-data content type. + + A KEM algorithm is a one-pass (store-and-forward) mechanism for + transporting random keying material to a recipient using the + recipient's public key. This means that the originator and the + recipients do not need to be online at the same time. The + recipient's private key is needed to recover the random keying + material, which is then treated as a pairwise shared secret (ss) + between the originator and recipient. + + The KEMRecipientInfo structure defined in this document uses the + pairwise shared secret as an input to a key derivation function (KDF) + to produce a pairwise key-encryption key (KEK). Then, the pairwise + KEK is used to encrypt a content-encryption key (CEK) or a content- + authenticated-encryption key (CAEK) for that recipient. All of the + recipients receive the same CEK or CAEK. + + In this environment, security depends on three things. First, the + KEM algorithm must be secure against adaptive chosen ciphertext + attacks. Second, the key-encryption algorithm must provide + confidentiality and integrity protection. Third, the choices of the + KDF and the key-encryption algorithm need to provide the same level + of security as the KEM algorithm. + + A KEM algorithm provides three functions: + + KeyGen() -> (pk, sk): + Generate the public key (pk) and a private key (sk). + + Encapsulate(pk) -> (ct, ss): + Given the recipient's public key (pk), produce a ciphertext (ct) + to be passed to the recipient and shared secret (ss) for the + originator. + + Decapsulate(sk, ct) -> ss: + Given the private key (sk) and the ciphertext (ct), produce the + shared secret (ss) for the recipient. + + To support a particular KEM algorithm, the CMS originator MUST + implement the KEM Encapsulate() function. + + To support a particular KEM algorithm, the CMS recipient MUST + implement the KEM KeyGen() function and the KEM Decapsulate() + function. The recipient's public key is usually carried in a + certificate [RFC5280]. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +1.2. ASN.1 + + CMS values are generated using ASN.1 [X.680], which uses the Basic + Encoding Rules (BER) and the Distinguished Encoding Rules (DER) + [X.690]. + +1.3. CMS Version Numbers + + As described in Section 1.3 of [RFC5652], the major data structures + include a version number as the first item in the data structure. + The version number is intended to avoid ASN.1 decode errors. Some + implementations do not check the version number prior to attempting a + decode, and then if a decode error occurs, the version number is + checked as part of the error-handling routine. This is a reasonable + approach; it places error processing outside of the fast path. This + approach is also forgiving when an incorrect version number is used + by the originator. + + Whenever the structure is updated, a higher version number will be + assigned. However, to ensure maximum interoperability, the higher + version number is only used when the new syntax feature is employed. + That is, the lowest version number that supports the generated syntax + is used. + +2. KEM Processing Overview + + KEM algorithms can be used with three CMS content types: the + enveloped-data content type [RFC5652], the authenticated-data content + type [RFC5652], or the authenticated-enveloped-data content type + [RFC5083]. For simplicity, the terminology associated with the + enveloped-data content type will be used in this overview. + + The originator randomly generates the CEK (or the CAEK), and then all + recipients obtain that key as an encrypted object within the + KEMRecipientInfo encryptedKey field explained in Section 3. All + recipients use the originator-generated symmetric key to decrypt the + CMS message. + + A KEM algorithm and a key derivation function are used to securely + establish a pairwise symmetric KEK, which is used to encrypt the + originator-generated CEK (or the CAEK). + + In advance, each recipient uses the KEM KeyGen() function to create a + key pair. The recipient will often obtain a certificate [RFC5280] + that includes the newly generated public key. Whether the public key + is certified or not, the newly generated public key is made available + to potential originators. + + The originator establishes the CEK (or the CAEK) using these steps: + + 1. The CEK (or the CAEK) is generated at random. + + 2. For each recipient: + + * The recipient's public key is used with the KEM Encapsulate() + function to obtain a pairwise shared secret (ss) and the + ciphertext for the recipient. + + * The key derivation function is used to derive a pairwise + symmetric KEK, from the pairwise ss and other data that is + optionally sent in the ukm field. + + * The KEK is used to encrypt the CEK for this recipient. + + 3. The CEK (or the CAEK) is used to encrypt the content for all + recipients. + + The recipient obtains the CEK (or the CAEK) using these steps: + + 1. The recipient's private key and the ciphertext are used with the + KEM Decapsulate() function to obtain a pairwise ss. + + 2. The key derivation function is used to derive a pairwise + symmetric KEK, from the pairwise ss and other data that is + optionally sent in the ukm field. + + 3. The KEK is used to decrypt the CEK (or the CAEK). + + 4. The CEK (or the CAEK) is used to decrypt the content. + +3. KEM Recipient Information + + This document defines KEMRecipientInfo for use with KEM algorithms. + As specified in Section 6.2.5 of [RFC5652], recipient information for + additional key management techniques is represented in the + OtherRecipientInfo type. Each key management technique is identified + by a unique ASN.1 object identifier. + + The object identifier associated with KEMRecipientInfo is: + + id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } + + id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 } + + The KEMRecipientInfo type is: + + KEMRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 0 + rid RecipientIdentifier, + kem KEMAlgorithmIdentifier, + kemct OCTET STRING, + kdf KeyDerivationAlgorithmIdentifier, + kekLength INTEGER (1..65535), + ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL, + wrap KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + + The fields of the KEMRecipientInfo type have the following meanings: + + version is the syntax version number. The version MUST be 0. The + CMSVersion type is described in Section 10.2.5 of [RFC5652]. + + rid specifies the recipient's certificate or key that was used by + the originator with the KEM Encapsulate() function. The + RecipientIdentifier provides two alternatives for specifying the + recipient's certificate [RFC5280], and thereby the recipient's + public key. The recipient's certificate MUST contain a KEM public + key. Therefore, a recipient X.509 version 3 certificate that + contains a key usage extension MUST assert the keyEncipherment + bit. The issuerAndSerialNumber alternative identifies the + recipient's certificate by the issuer's distinguished name and the + certificate serial number; the subjectKeyIdentifier alternative + identifies the recipient's certificate by a key identifier. When + an X.509 certificate is referenced, the key identifier matches the + X.509 subjectKeyIdentifier extension value. When other + certificate formats are referenced, the documents that specify the + certificate format and their use with the CMS must include details + on matching the key identifier to the appropriate certificate + field. For recipient processing, implementations MUST support + both of these alternatives for specifying the recipient's + certificate. For originator processing, implementations MUST + support at least one of these alternatives. + + kem identifies the KEM algorithm, and any associated parameters, + used by the originator. The KEMAlgorithmIdentifier is described + in Section 4. + + kemct is the ciphertext produced by the KEM Encapsulate() function + for this recipient. + + kdf identifies the key derivation function, and any associated + parameters, used by the originator to generate the KEK. The + KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of + [RFC5652]. + + kekLength is the size of the KEK in octets. This value is one of + the inputs to the key derivation function. The upper bound on the + integer value is provided to make it clear to implementers that + support for very large integer values is not needed. + Implementations MUST confirm that the value provided is consistent + with the key-encryption algorithm identified in the wrap field + below. + + ukm is optional user keying material. When the ukm value is + provided, it is used as part of the info structure described in + Section 5 to provide a context input to the key derivation + function. For example, the ukm value could include a nonce, + application-specific context information, or an identifier for the + originator. A KEM algorithm may place requirements on the ukm + value. Implementations that do not support the ukm field SHOULD + gracefully discontinue processing when the ukm field is present. + Note that this requirement expands the original purpose of the ukm + described in Section 10.2.6 of [RFC5652]; it is not limited to + being used with key agreement algorithms. + + wrap identifies a key-encryption algorithm used to encrypt the + CEK. The KeyEncryptionAlgorithmIdentifier is described in + Section 10.1.3 of [RFC5652]. + + encryptedKey is the result of encrypting the CEK or the CAEK (the + content-authenticated-encryption key, as discussed in [RFC5083]) + with the KEK. EncryptedKey is an OCTET STRING. + +4. KEM Algorithm Identifier + + The KEMAlgorithmIdentifier type identifies a KEM algorithm used to + establish a pairwise ss. The details of establishment depend on the + KEM algorithm used. A key derivation function is used to transform + the pairwise ss value into a KEK. + + KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} } + +5. Key Derivation + + This section describes the conventions of using the KDF to compute + the KEK for KEMRecipientInfo. For simplicity, the terminology used + in the HKDF specification [RFC5869] is used here. + + Many KDFs internally employ a one-way hash function. When this is + the case, the hash function that is used is indirectly indicated by + the KeyDerivationAlgorithmIdentifier. Other KDFs internally employ + an encryption algorithm. When this is the case, the encryption that + is used is indirectly indicated by the + KeyDerivationAlgorithmIdentifier. + + The KDF inputs are as follows: + + IKM is the input keying material. It is a symmetric secret input + to the KDF. The KDF may use a hash function or an encryption + algorithm to generate a pseudorandom key. The algorithm used to + derive the IKM is dependent on the algorithm identified in the + KeyDerivationAlgorithmIdentifier. + + L is the length of the output keying material in octets. L is + identified in the kekLength of the KEMRecipientInfo. The value is + dependent on the key-encryption algorithm used; the key-encryption + algorithm is identified in the KeyEncryptionAlgorithmIdentifier. + + info is contextual input to the KDF. The DER-encoded + CMSORIforKEMOtherInfo structure is created from elements of the + KEMRecipientInfo structure. CMSORIforKEMOtherInfo is defined as: + + CMSORIforKEMOtherInfo ::= SEQUENCE { + wrap KeyEncryptionAlgorithmIdentifier, + kekLength INTEGER (1..65535), + ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } + + The CMSORIforKEMOtherInfo structure contains the following: + + wrap identifies a key-encryption algorithm; the output of the key + derivation function will be used as a key for this algorithm. + + kekLength is the length of the KEK in octets; the output of the + key derivation function will be exactly this size. + + ukm is optional user keying material; see Section 3. + + The KDF output is as follows: + + OKM is the output keying material with the exact length of L + octets. The OKM is the KEK that is used to encrypt the CEK or the + CAEK. + + An acceptable KDF MUST accept an IKM, L, and info as inputs. An + acceptable KDF MAY also accept a salt input value, which is carried + as a parameter to the KeyDerivationAlgorithmIdentifier if present. + All of these inputs MUST influence the output of the KDF. + +6. ASN.1 Modules + + This section provides two ASN.1 modules [X.680]. The first ASN.1 + module is an extension to the AlgorithmInformation-2009 module + discussed in [RFC5912]; it defines the KEM-ALGORITHM CLASS. The + second ASN.1 module defines the structures needed to use KEM + algorithms with CMS [RFC5652]. + + The first ASN.1 module uses EXPLICIT tagging, and the second ASN.1 + module uses IMPLICIT tagging. + + Both ASN.1 modules follow the conventions established in [RFC5911], + [RFC5912], and [RFC6268]. + +6.1. KEMAlgorithmInformation-2023 ASN.1 Module + + <CODE BEGINS> + KEMAlgorithmInformation-2023 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-kemAlgorithmInformation-2023(109) } + + DEFINITIONS EXPLICIT TAGS ::= + BEGIN + -- EXPORTS ALL; + IMPORTS + ParamOptions, PUBLIC-KEY, SMIME-CAPS + FROM AlgorithmInformation-2009 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-algorithmInformation-02(58) } ; + + -- KEM-ALGORITHM + -- + -- Describes the basic properties of a KEM algorithm + -- + -- Suggested prefix for KEM algorithm objects is: kema- + -- + -- &id - contains the OID identifying the KEM algorithm + -- &Value - if present, contains a type definition for the kemct; + -- if absent, implies that no ASN.1 encoding is + -- performed on the kemct value + -- &Params - if present, contains the type for the algorithm + -- parameters; if absent, implies no parameters + -- ¶mPresence - parameter presence requirement + -- &PublicKeySet - specifies which public keys are used with + -- this algorithm + -- &Ukm - if absent, type for user keying material + -- &ukmPresence - specifies the requirements to define the UKM + -- field + -- &smimeCaps - contains the object describing how the S/MIME + -- capabilities are presented. + -- + -- Example: + -- kema-kem-rsa KEM-ALGORITHM ::= { + -- IDENTIFIER id-kem-rsa + -- PARAMS TYPE RsaKemParameters ARE optional + -- PUBLIC-KEYS { pk-rsa | pk-rsa-kem } + -- UKM ARE optional + -- SMIME-CAPS { TYPE GenericHybridParameters + -- IDENTIFIED BY id-rsa-kem } + -- } + + KEM-ALGORITHM ::= CLASS { + &id OBJECT IDENTIFIER UNIQUE, + &Value OPTIONAL, + &Params OPTIONAL, + ¶mPresence ParamOptions DEFAULT absent, + &PublicKeySet PUBLIC-KEY OPTIONAL, + &Ukm OPTIONAL, + &ukmPresence ParamOptions DEFAULT absent, + &smimeCaps SMIME-CAPS OPTIONAL + } WITH SYNTAX { + IDENTIFIER &id + [VALUE &Value] + [PARAMS [TYPE &Params] ARE ¶mPresence] + [PUBLIC-KEYS &PublicKeySet] + [UKM [TYPE &Ukm] ARE &ukmPresence] + [SMIME-CAPS &smimeCaps] + } + + END + <CODE ENDS> + +6.2. CMS-KEMRecipientInfo-2023 ASN.1 Module + + <CODE BEGINS> + CMS-KEMRecipientInfo-2023 + { iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs-9(9) smime(16) modules(0) + id-mod-cms-kemri-2023(77) } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + -- EXPORTS ALL; + IMPORTS + OTHER-RECIPIENT, CMSVersion, RecipientIdentifier, + EncryptedKey, KeyDerivationAlgorithmIdentifier, + KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial + FROM CryptographicMessageSyntax-2010 -- RFC 6268 + { iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs-9(9) smime(16) modules(0) + id-mod-cms-2009(58) } + KEM-ALGORITHM + FROM KEMAlgorithmInformation-2023 -- RFC 9629 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-kemAlgorithmInformation-2023(109) } + AlgorithmIdentifier{} + FROM AlgorithmInformation-2009 -- RFC 5912 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-algorithmInformation-02(58) } ; + + -- + -- OtherRecipientInfo Types (ori-) + -- + + SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... } + + ori-KEM OTHER-RECIPIENT ::= { + KEMRecipientInfo IDENTIFIED BY id-ori-kem } + + id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } + + id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 } + + -- + -- KEMRecipientInfo + -- + + KEMRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 0 + rid RecipientIdentifier, + kem KEMAlgorithmIdentifier, + kemct OCTET STRING, + kdf KeyDerivationAlgorithmIdentifier, + kekLength INTEGER (1..65535), + ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL, + wrap KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + + KEMAlgSet KEM-ALGORITHM ::= { ... } + + KEMAlgorithmIdentifier ::= + AlgorithmIdentifier{ KEM-ALGORITHM, {KEMAlgSet} } + + -- + -- CMSORIforKEMOtherInfo + -- + + CMSORIforKEMOtherInfo ::= SEQUENCE { + wrap KeyEncryptionAlgorithmIdentifier, + kekLength INTEGER (1..65535), + ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } + + END + <CODE ENDS> + +7. Security Considerations + + The security considerations discussed in [RFC5652] are applicable to + this document. + + To be appropriate for use with this specification, the KEM algorithm + MUST explicitly be designed to be secure when the public key is used + many times. For example, a KEM algorithm with a single-use public + key is not appropriate, because the public key is expected to be + carried in a long-lived certificate [RFC5280] and used over and over. + Thus, KEM algorithms that offer indistinguishability under adaptive + chosen ciphertext attack (IND-CCA2) security are appropriate. A + common design pattern for obtaining IND-CCA2 security with public key + reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a + variant of the FO transform [HHK]. + + The KDF SHOULD offer at least the security level of the KEM. + + The choice of the key-encryption algorithm and the size of the KEK + SHOULD be made based on the security level provided by the KEM. The + key-encryption algorithm and the KEK SHOULD offer at least the + security level of the KEM. + + KEM algorithms do not provide data origin authentication; therefore, + when a KEM algorithm is used with the authenticated-data content + type, the contents are delivered with integrity from an unknown + source. + + Implementations MUST protect the KEM private key, the KEK, and the + CEK (or the CAEK). Compromise of the KEM private key may result in + the disclosure of all contents protected with that KEM private key. + However, compromise of the KEK, the CEK, or the CAEK may result in + disclosure of the encrypted content of a single message. + + The KEM produces the IKM input value for the KDF. This IKM value + MUST NOT be reused for any other purpose. Likewise, any random value + used by the KEM algorithm to produce the shared secret or its + encapsulation MUST NOT be reused for any other purpose. That is, the + originator MUST generate a fresh KEM shared secret for each recipient + in the KEMRecipientInfo structure, including any random value used by + the KEM algorithm to produce the KEM shared secret. In addition, the + originator MUST discard the KEM shared secret, including any random + value used by the KEM algorithm to produce the KEM shared secret, + after constructing the entry in the KEMRecipientInfo structure for + the corresponding recipient. Similarly, the recipient MUST discard + the KEM shared secret, including any random value used by the KEM + algorithm to produce the KEM shared secret, after constructing the + KEK from the KEMRecipientInfo structure. + + Implementations MUST randomly generate content-encryption keys, + content-authenticated-encryption keys, and message-authentication + keys. Also, the generation of KEM key pairs relies on random + numbers. The use of inadequate pseudorandom number generators + (PRNGs) to generate these 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. [RFC4086] + offers important guidance in this area. + + If the cipher and key sizes used for the key-encryption algorithm and + the content-encryption algorithm are different, the effective + security is determined by the weaker of the two algorithms. If, for + example, the content is encrypted with AES-CBC using a 128-bit CEK + and the CEK is wrapped with AES-KEYWRAP using a 256-bit KEK, then at + most 128 bits of protection is provided. + + If the cipher and key sizes used for the key-encryption algorithm and + the content-authenticated-encryption algorithm are different, the + effective security is determined by the weaker of the two algorithms. + If, for example, the content is encrypted with AES-GCM using a + 128-bit CAEK and the CAEK is wrapped with AES-KEYWRAP using a 192-bit + KEK, then at most 128 bits of protection is provided. + + If the cipher and key sizes used for the key-encryption algorithm and + the message-authentication algorithm are different, the effective + security is determined by the weaker of the two algorithms. If, for + example, the content is authenticated with HMAC-SHA256 using a + 512-bit message-authentication key and the message-authentication key + is wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 256 + bits of protection is provided. + + Implementers should be aware that cryptographic algorithms, including + KEM algorithms, become weaker with time. As new cryptoanalysis + techniques are developed and computing capabilities advance, the work + factor to break a particular cryptographic algorithm will be reduced. + As a result, cryptographic algorithm implementations should be + modular, allowing new algorithms to be readily inserted. That is, + implementers should be prepared for the set of supported algorithms + to change over time. + +8. IANA Considerations + + For KEMRecipientInfo as defined in Section 3, IANA has assigned the + following OID in the "SMI Security for S/MIME Other Recipient Info + Identifiers (1.2.840.113549.1.9.16.13)" registry: + + +=========+=============+============+ + | Decimal | Description | References | + +=========+=============+============+ + | 3 | id-ori-kem | RFC 9629 | + +---------+-------------+------------+ + + Table 1 + + For the ASN.1 module defined in Section 6.1, IANA has assigned the + following OID in the "SMI Security for PKIX Module Identifier" + registry (1.3.6.1.5.5.7.0): + + +=========+=====================================+============+ + | Decimal | Description | References | + +=========+=====================================+============+ + | 109 | id-mod-kemAlgorithmInformation-2023 | RFC 9629 | + +---------+-------------------------------------+------------+ + + Table 2 + + For the ASN.1 module defined in Section 6.2, IANA has assigned the + following OID in the "SMI Security for S/MIME Module Identifier + (1.2.840.113549.1.9.16.0)" registry: + + +=========+=======================+============+ + | Decimal | Description | References | + +=========+=======================+============+ + | 77 | id-mod-cms-kemri-2023 | RFC 9629 | + +---------+-----------------------+------------+ + + Table 3 + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) + Authenticated-Enveloped-Data Content Type", RFC 5083, + DOI 10.17487/RFC5083, November 2007, + <https://www.rfc-editor.org/info/rfc5083>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + <https://www.rfc-editor.org/info/rfc5652>. + + [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for + Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, + DOI 10.17487/RFC5911, June 2010, + <https://www.rfc-editor.org/info/rfc5911>. + + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, + DOI 10.17487/RFC5912, June 2010, + <https://www.rfc-editor.org/info/rfc5912>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [X.680] ITU-T, "Information technology - Abstract Syntax Notation + One (ASN.1): Specification of basic notation", ITU-T + Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, + <https://www.itu.int/rec/T-REC-X.680>. + + [X.690] ITU-T, "Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021, + February 2021, <https://www.itu.int/rec/T-REC-X.690>. + +9.2. Informative References + + [FO] Fujisaki, E. and T. Okamoto, "Secure Integration of + Asymmetric and Symmetric Encryption Schemes", Springer + Science and Business Media LLC, Journal of Cryptology, + vol. 26, no. 1, pp. 80-101, DOI 10.1007/s00145-011-9114-1, + December 2011, + <https://doi.org/10.1007/s00145-011-9114-1>. + + [HHK] Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular + Analysis of the Fujisaki-Okamoto Transformation", Springer + International Publishing, Theory of Cryptography, TCC + 2017, Lecture Notes in Computer Science, vol. 10677, pp. + 341-371, Print ISBN 9783319704999, Online ISBN + 9783319705002, DOI 10.1007/978-3-319-70500-2_12, November + 2017, <https://doi.org/10.1007/978-3-319-70500-2_12>. + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + <https://www.rfc-editor.org/info/rfc4086>. + + [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC 5869, + DOI 10.17487/RFC5869, May 2010, + <https://www.rfc-editor.org/info/rfc5869>. + + [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules + for the Cryptographic Message Syntax (CMS) and the Public + Key Infrastructure Using X.509 (PKIX)", RFC 6268, + DOI 10.17487/RFC6268, July 2011, + <https://www.rfc-editor.org/info/rfc6268>. + +Acknowledgements + + Our thanks to Burt Kaliski for his guidance and design review. + + Our thanks to Carl Wallace for his careful review of the ASN.1 + modules. + + Our thanks to Hendrik Brockhaus, Jonathan Hammell, Mike Jenkins, + David von Oheimb, Francois Rousseau, and Linda Dunbar for their + careful reviews and thoughtful comments. + +Authors' Addresses + + Russ Housley + Vigil Security, LLC + Herndon, VA + United States of America + Email: housley@vigilsec.com + + + John Gray + Entrust + Minneapolis, MN + United States of America + Email: john.gray@entrust.com + + + Tomofumi Okubo + Penguin Securities Pte. Ltd. + Singapore + Email: tomofumi.okubo+ietf@gmail.com + + Additional contact information: + + 大久保 智史 + Penguin Securities Pte. Ltd. + Singapore |