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

This html diff was produced by rfcdiff 1.48.