rfc9810v1.txt | rfc9810.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) H. Brockhaus | Internet Engineering Task Force (IETF) H. Brockhaus | |||
Request for Comments: 9810 D. von Oheimb | Request for Comments: 9810 D. von Oheimb | |||
Obsoletes: 4210, 9480 Siemens | Obsoletes: 4210, 9480 Siemens | |||
Updates: 5912 M. Ounsworth | Updates: 5912 M. Ounsworth | |||
Category: Standards Track J. Gray | Category: Standards Track J. Gray | |||
ISSN: 2070-1721 Entrust | ISSN: 2070-1721 Entrust | |||
June 2025 | July 2025 | |||
Internet X.509 Public Key Infrastructure -- Certificate Management | Internet X.509 Public Key Infrastructure -- Certificate Management | |||
Protocol (CMP) | Protocol (CMP) | |||
Abstract | Abstract | |||
This document describes the Internet X.509 Public Key Infrastructure | This document describes the Internet X.509 Public Key Infrastructure | |||
(PKI) Certificate Management Protocol (CMP). Protocol messages are | (PKI) Certificate Management Protocol (CMP). Protocol messages are | |||
defined for X.509v3 certificate creation and management. CMP | defined for X.509v3 certificate creation and management. CMP | |||
provides interactions between client systems and PKI components such | provides interactions between client systems and PKI components such | |||
as a Registration Authority (RA) and a Certification Authority (CA). | as a Registration Authority (RA) and a Certification Authority (CA). | |||
This document adds support for management of certificates containing | This document adds support for management of certificates containing | |||
a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData | a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData | |||
instead of EncryptedValue. This document also includes the updates | instead of EncryptedValue. This document also includes the updates | |||
specified in Section 2 and Appendix A.2 of RFC 9480. | specified in Section 2 and Appendix A.2 of RFC 9480. | |||
The updates maintain backward compatibility with CMP version 2 | ||||
wherever possible. Updates to CMP version 2 are improving crypto | ||||
agility, extending the polling mechanism, adding new general message | ||||
types, and adding extended key usages (EKUs) to identify special CMP | ||||
server authorizations. CMP version 3 is introduced for changes to | ||||
the ASN.1 syntax, which support EnvelopedData, certConf with hashAlg, | ||||
POPOPrivKey with agreeMAC, and RootCaKeyUpdateContent in ckuann | ||||
messages. | ||||
This document obsoletes RFC 4210, and together with RFC 9811, it also | This document obsoletes RFC 4210, and together with RFC 9811, it also | |||
obsoletes RFC 9480. Appendix F of this document updates Section 9 of | obsoletes RFC 9480. Appendix F of this document updates Section 9 of | |||
RFC 5912. | RFC 5912. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
skipping to change at line 95 ¶ | skipping to change at line 86 ¶ | |||
4.1. End Entity Initialization | 4.1. End Entity Initialization | |||
4.2. Initial Registration/Certification | 4.2. Initial Registration/Certification | |||
4.2.1. Criteria Used | 4.2.1. Criteria Used | |||
4.2.1.1. Initiation of Registration/Certification | 4.2.1.1. Initiation of Registration/Certification | |||
4.2.1.2. End Entity Message Origin Authentication | 4.2.1.2. End Entity Message Origin Authentication | |||
4.2.1.3. Location of Key Generation | 4.2.1.3. Location of Key Generation | |||
4.2.1.4. Confirmation of Successful Certification | 4.2.1.4. Confirmation of Successful Certification | |||
4.2.2. Initial Registration/Certification Schemes | 4.2.2. Initial Registration/Certification Schemes | |||
4.2.2.1. Centralized Scheme | 4.2.2.1. Centralized Scheme | |||
4.2.2.2. Basic Authenticated Scheme | 4.2.2.2. Basic Authenticated Scheme | |||
4.3. Proof-of-Possession (POP) of Private Key | 4.3. POP of Private Key | |||
4.3.1. Signature Keys | 4.3.1. Signature Keys | |||
4.3.2. Encryption Keys | 4.3.2. Encryption Keys | |||
4.3.3. Key Agreement Keys | 4.3.3. Key Agreement Keys | |||
4.3.4. Key Encapsulation Mechanism Keys | 4.3.4. KEM Keys | |||
4.4. Root CA Key Update | 4.4. Root CA Key Update | |||
4.4.1. CA Operator Actions | 4.4.1. CA Operator Actions | |||
4.4.2. Verifying Certificates | 4.4.2. Verifying Certificates | |||
4.4.2.1. Verification in Cases 1 and 4 | 4.4.2.1. Verification in Cases 1 and 4 | |||
4.4.2.2. Verification in Case 2 | 4.4.2.2. Verification in Case 2 | |||
4.4.2.3. Verification in Case 3 | 4.4.2.3. Verification in Case 3 | |||
4.4.3. Revocation - Change of the CA Key | 4.4.3. Revocation - Change of the CA Key | |||
4.5. Extended Key Usage for PKI Entities | 4.5. EKU for PKI Entities | |||
5. Data Structures | 5. Data Structures | |||
5.1. Overall PKI Message | 5.1. Overall PKI Message | |||
5.1.1. PKI Message Header | 5.1.1. PKI Message Header | |||
5.1.1.1. ImplicitConfirm | 5.1.1.1. ImplicitConfirm | |||
5.1.1.2. ConfirmWaitTime | 5.1.1.2. ConfirmWaitTime | |||
5.1.1.3. OrigPKIMessage | 5.1.1.3. OrigPKIMessage | |||
5.1.1.4. CertProfile | 5.1.1.4. CertProfile | |||
5.1.1.5. KemCiphertextInfo | 5.1.1.5. KemCiphertextInfo | |||
5.1.2. PKI Message Body | 5.1.2. PKI Message Body | |||
5.1.3. PKI Message Protection | 5.1.3. PKI Message Protection | |||
skipping to change at line 131 ¶ | skipping to change at line 122 ¶ | |||
5.1.3.4. Key Encapsulation | 5.1.3.4. Key Encapsulation | |||
5.1.3.5. Multiple Protection | 5.1.3.5. Multiple Protection | |||
5.2. Common Data Structures | 5.2. Common Data Structures | |||
5.2.1. Requested Certificate Contents | 5.2.1. Requested Certificate Contents | |||
5.2.2. Encrypted Values | 5.2.2. Encrypted Values | |||
5.2.3. Status Codes and Failure Information for PKI Messages | 5.2.3. Status Codes and Failure Information for PKI Messages | |||
5.2.4. Certificate Identification | 5.2.4. Certificate Identification | |||
5.2.5. Out-of-Band Root CA Public Key | 5.2.5. Out-of-Band Root CA Public Key | |||
5.2.6. Archive Options | 5.2.6. Archive Options | |||
5.2.7. Publication Information | 5.2.7. Publication Information | |||
5.2.8. Proof-of-Possession Structures | 5.2.8. POP Structures | |||
5.2.8.1. raVerified | 5.2.8.1. raVerified | |||
5.2.8.2. POPOSigningKey Structure | 5.2.8.2. POPOSigningKey Structure | |||
5.2.8.3. POPOPrivKey Structure | 5.2.8.3. POPOPrivKey Structure | |||
5.2.8.4. Summary of POP Options | 5.2.8.4. Summary of POP Options | |||
5.2.9. GeneralizedTime | 5.2.9. GeneralizedTime | |||
5.3. Operation-Specific Data Structures | 5.3. Operation-Specific Data Structures | |||
5.3.1. Initialization Request | 5.3.1. Initialization Request | |||
5.3.2. Initialization Response | 5.3.2. Initialization Response | |||
5.3.3. Certification Request | 5.3.3. Certification Request | |||
5.3.4. Certification Response | 5.3.4. Certification Response | |||
skipping to change at line 184 ¶ | skipping to change at line 175 ¶ | |||
5.3.19.18. KEM Ciphertext | 5.3.19.18. KEM Ciphertext | |||
5.3.20. PKI General Response Content | 5.3.20. PKI General Response Content | |||
5.3.21. Error Message Content | 5.3.21. Error Message Content | |||
5.3.22. Polling Request and Response | 5.3.22. Polling Request and Response | |||
6. Mandatory PKI Management Functions | 6. Mandatory PKI Management Functions | |||
6.1. Root CA Initialization | 6.1. Root CA Initialization | |||
6.2. Root CA Key Update | 6.2. Root CA Key Update | |||
6.3. Subordinate CA Initialization | 6.3. Subordinate CA Initialization | |||
6.4. CRL Production | 6.4. CRL Production | |||
6.5. PKI Information Request | 6.5. PKI Information Request | |||
6.6. Cross Certification | 6.6. Cross-Certification | |||
6.6.1. One-Way Request-Response Scheme | 6.6.1. One-Way Request-Response Scheme | |||
6.7. End Entity Initialization | 6.7. End Entity Initialization | |||
6.7.1. Acquisition of PKI Information | 6.7.1. Acquisition of PKI Information | |||
6.7.2. Out-of-Band Verification of the Root CA Key | 6.7.2. Out-of-Band Verification of the Root CA Key | |||
6.8. Certificate Request | 6.8. Certificate Request | |||
6.9. Key Update | 6.9. Key Update | |||
7. Version Negotiation | 7. Version Negotiation | |||
7.1. Supporting RFC 2510 Implementations | 7.1. Supporting RFC 2510 Implementations | |||
7.1.1. Clients Talking to RFC 2510 Servers | 7.1.1. Clients Talking to RFC 2510 Servers | |||
7.1.2. Servers Receiving Version cmp1999 PKIMessages | 7.1.2. Servers Receiving Version cmp1999 PKIMessages | |||
8. Security Considerations | 8. Security Considerations | |||
8.1. On the Necessity of Proof-of-Possession | 8.1. On the Necessity of POP | |||
8.2. Proof-of-Possession with a Decryption Key | 8.2. POP with a Decryption Key | |||
8.3. Proof-of-Possession by Exposing the Private Key | 8.3. POP by Exposing the Private Key | |||
8.4. Attack Against Diffie-Hellman Key Exchange | 8.4. Attack Against DH Key Exchange | |||
8.5. Perfect Forward Secrecy | 8.5. Perfect Forward Secrecy | |||
8.6. Private Keys for Certificate Signing and CMP Message | 8.6. Private Keys for Certificate Signing and CMP Message | |||
Protection | Protection | |||
8.7. Entropy of Random Numbers, Key Pairs, and Shared Secret | 8.7. Entropy of Random Numbers, Key Pairs, and Shared Secret | |||
Information | Information | |||
8.8. Recurring Usage of KEM Keys for Message Protection | 8.8. Recurring Usage of KEM Keys for Message Protection | |||
8.9. Trust Anchor Provisioning Using CMP Messages | 8.9. Trust Anchor Provisioning Using CMP Messages | |||
8.10. Authorizing Requests for Certificates with Specific EKUs | 8.10. Authorizing Requests for Certificates with Specific EKUs | |||
8.11. Usage of Certificate Transparency Logs | 8.11. Usage of CT Logs | |||
9. IANA Considerations | 9. IANA Considerations | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
10.2. Informative References | 10.2. Informative References | |||
Appendix A. Reasons for the Presence of RAs | Appendix A. Reasons for the Presence of RAs | |||
Appendix B. The Use of Revocation Passphrase | Appendix B. The Use of Revocation Passphrase | |||
Appendix C. PKI Management Message Profiles (REQUIRED) | Appendix C. PKI Management Message Profiles (REQUIRED) | |||
C.1. General Rules for Interpretation of These Profiles | C.1. General Rules for Interpretation of These Profiles | |||
C.2. Algorithm Use Profile | C.2. Algorithm Use Profile | |||
C.3. Proof-of-Possession Profile | C.3. POP Profile | |||
C.4. Initial Registration/Certification (Basic Authenticated | C.4. Initial Registration/Certification (Basic Authenticated | |||
Scheme) | Scheme) | |||
C.5. Certificate Request | C.5. Certificate Request | |||
C.6. Key Update Request | C.6. Key Update Request | |||
Appendix D. PKI Management Message Profiles (OPTIONAL) | Appendix D. PKI Management Message Profiles (OPTIONAL) | |||
D.1. General Rules for Interpretation of These Profiles | D.1. General Rules for Interpretation of These Profiles | |||
D.2. Algorithm Use Profile | D.2. Algorithm Use Profile | |||
D.3. Self-Signed Certificates | D.3. Self-Signed Certificates | |||
D.4. Root CA Key Update | D.4. Root CA Key Update | |||
D.5. PKI Information Request/Response | D.5. PKI Information Request/Response | |||
D.6. Cross-Certification Request/Response (1-way) | D.6. Cross-Certification Request/Response (1-way) | |||
D.7. In-Band Initialization Using External Identity Certificate | D.7. In-Band Initialization Using External Identity Certificate | |||
Appendix E. Variants of Using KEM Keys for PKI Message Protection | Appendix E. Variants of Using KEM Keys for PKI Message Protection | |||
Appendix F. Compilable ASN.1 Definitions | Appendix F. Compilable ASN.1 Definitions | |||
Acknowledgements | Acknowledgements | |||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
This document describes the Internet X.509 Public Key Infrastructure | This document describes the Internet X.509 PKI CMP. Protocol | |||
(PKI) Certificate Management Protocol (CMP). Protocol messages are | messages are defined for certificate creation and management. The | |||
defined for certificate creation and management. The term | term "certificate" in this document refers to an X.509v3 certificate | |||
"certificate" in this document refers to an X.509v3 Certificate as | as defined in [RFC5280]. | |||
defined in [RFC5280]. | ||||
1.1. Changes Made by RFC 4210 | 1.1. Changes Made by RFC 4210 | |||
[RFC4210] differs from [RFC2510] in the following areas: | [RFC4210] differs from [RFC2510] in the following areas: | |||
* The PKI management message profile section is split to two | * The PKI management message profile section is split to two | |||
appendices: the required profile and the optional profile. Some | appendices: the required profile and the optional profile. Some | |||
of the formerly mandatory functionality is moved to the optional | of the formerly mandatory functionality is moved to the optional | |||
profile. | profile. | |||
skipping to change at line 273 ¶ | skipping to change at line 263 ¶ | |||
* The new specification contains some less prominent protocol | * The new specification contains some less prominent protocol | |||
enhancements and improved explanatory text on several issues. | enhancements and improved explanatory text on several issues. | |||
1.2. Updates Made by RFC 9480 | 1.2. Updates Made by RFC 9480 | |||
CMP Updates [RFC9480] and CMP Algorithms [RFC9481] updated [RFC4210], | CMP Updates [RFC9480] and CMP Algorithms [RFC9481] updated [RFC4210], | |||
supporting the PKI management operations specified in the Lightweight | supporting the PKI management operations specified in the Lightweight | |||
CMP Profile [RFC9483], in the following areas: | CMP Profile [RFC9483], in the following areas: | |||
* Added new extended key usages for various CMP server types, e.g., | * Added new extended key usages (EKUs) for various CMP server types, | |||
registration authority and certification authority, to express the | e.g., RA and CA, to express the authorization of the certificate | |||
authorization of the certificate holder that acts as the indicated | holder that acts as the indicated type of PKI management entity. | |||
type of PKI management entity. | ||||
* Extended the description of multiple protection to cover | * Extended the description of multiple protection to cover | |||
additional use cases, e.g., batch processing of messages. | additional use cases, e.g., batch processing of messages. | |||
* Used the Cryptographic Message Syntax (CMS) [RFC5652] type | * Used the Cryptographic Message Syntax (CMS) [RFC5652] type | |||
EnvelopedData as the preferred choice instead of EncryptedValue to | EnvelopedData as the preferred choice instead of EncryptedValue to | |||
better support crypto agility in CMP. | better support crypto agility in CMP. | |||
For reasons of completeness and consistency, the type | For reasons of completeness and consistency, the type | |||
EncryptedValue has been exchanged in all occurrences. This | EncryptedValue has been exchanged in all occurrences. This | |||
includes the protection of centrally generated private keys, | includes the protection of centrally generated private keys, | |||
encryption of certificates, proof-of-possession methods, and | encryption of certificates, Proof-of-Possession (POP) methods, and | |||
protection of revocation passphrases. To properly differentiate | protection of revocation passphrases. To properly differentiate | |||
the support of EnvelopedData instead of EncryptedValue, CMP | the support of EnvelopedData instead of EncryptedValue, CMP | |||
version 3 is introduced in case a transaction is supposed to use | version 3 is introduced in case a transaction is supposed to use | |||
EnvelopedData. | EnvelopedData. | |||
Note: According to point 9 in Section 2.1 of [RFC4211], the use of | Note: According to point 9 in Section 2.1 of [RFC4211], the use of | |||
the EncryptedValue structure has been deprecated in favor of the | the EncryptedValue structure has been deprecated in favor of the | |||
EnvelopedData structure. [RFC4211] offers the EncryptedKey | EnvelopedData structure. [RFC4211] offers the EncryptedKey | |||
structure a choice of EncryptedValue and EnvelopedData for | structure a choice of EncryptedValue and EnvelopedData for | |||
migration to EnvelopedData. | migration to EnvelopedData. | |||
* Offered an optional hashAlg field in CertStatus supporting cases | * Offered an optional hashAlg field in CertStatus supporting cases | |||
that a certificate needs to be confirmed that has a signature | when a certificate needs to be confirmed, but the certificate was | |||
algorithm that does not indicate a specific hash algorithm to use | signed using a signature algorithm that does not indicate a | |||
for computing the certHash. This is also in preparation for | specific hash algorithm to use for computing the certHash. This | |||
upcoming post-quantum algorithms. | is also in preparation for upcoming post-quantum algorithms. | |||
* Added new general message types to request CA certificates, a root | * Added new general message types to request CA certificates, a root | |||
CA update, a certificate request template, or Certificate | CA update, a certificate request template, or Certificate | |||
Revocation List (CRL) updates. | Revocation List (CRL) updates. | |||
* Extended the use of polling to p10cr, certConf, rr, genm, and | * Extended the use of polling to p10cr, certConf, rr, genm, and | |||
error messages. | error messages. | |||
* Deleted the mandatory algorithm profile in Appendix C.2 and | * Deleted the mandatory algorithm profile in Appendix C.2 and | |||
instead referred to Section 7 of [RFC9481]. | instead referred to Section 7 of [RFC9481]. | |||
* Added Sections 8.6, 8.7, 8.9, and 8.10 to the security | * Added Sections 8.6, 8.7, 8.9, and 8.10 to the security | |||
considerations. | considerations. | |||
1.3. Changes Made by This Document | 1.3. Changes Made by This Document | |||
This document obsoletes [RFC4210] and [RFC9480]. It includes the | This document obsoletes [RFC4210] and [RFC9480]. | |||
changes specified by Section 2 and Appendix A.2 of [RFC9480] as | ||||
described in Section 1.2. Additionally, this document updates the | ||||
content of [RFC4210] in the following areas: | ||||
* Added Section 3.1.1.4 introducing the Key Generation Authority. | Backward compatibility with CMP version 2 is maintained wherever | |||
possible. Updates to CMP version 2 improve crypto agility, extend | ||||
the polling mechanism, add new general message types, and add EKUs to | ||||
identify special CMP server authorizations. CMP version 3 is | ||||
introduced for changes to the ASN.1 syntax, which support | ||||
EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, and | ||||
RootCaKeyUpdateContent in ckuann messages. | ||||
The updates made in this document include the changes specified by | ||||
Section 2 and Appendix A.2 of [RFC9480] as described in Section 1.2. | ||||
Additionally, this document updates the content of [RFC4210] in the | ||||
following areas: | ||||
* Added Section 3.1.1.4 introducing the Key Generation Authority | ||||
(KGA). | ||||
* Extended Section 3.1.2 regarding use of Certificate Transparency | * Extended Section 3.1.2 regarding use of Certificate Transparency | |||
logs. | (CT) logs. | |||
* Updated Section 4.4 introducing RootCaKeyUpdateContent as an | * Updated Section 4.4 introducing RootCaKeyUpdateContent as an | |||
alternative to using a repository to acquire new root CA | alternative to using a repository to acquire new root CA | |||
certificates. | certificates. | |||
* Added Section 5.1.1.3 containing a description of origPKIMessage | * Added Section 5.1.1.3 containing a description of origPKIMessage | |||
content, moved here from Section 5.1.3.4. | content, moved here from Section 5.1.3.4. | |||
* Added support for KEM keys for proof-of-possession to Sections 4.3 | * Added support for KEM keys for POP to Sections 4.3 and 5.2.8, for | |||
and 5.2.8, for message protection to Sections 5.1.1 and 5.1.3.4 | message protection to Sections 5.1.1 and 5.1.3.4 and Appendix E, | |||
and Appendix E, and for usage with CMS EnvelopedData to | and for usage with CMS EnvelopedData to Section 5.2.2. | |||
Section 5.2.2. | ||||
* Deprecated CAKeyUpdAnnContent in favor of RootCaKeyUpdateContent. | * Deprecated CAKeyUpdAnnContent in favor of RootCaKeyUpdateContent. | |||
* Incorporated the request message behavioral clarifications from | * Incorporated the request message behavioral clarifications from | |||
Appendix C of [RFC4210] to Section 5. The definition of | Appendix C of [RFC4210] to Section 5. The definition of | |||
altCertTemplate was incorporated into Section 5.2.1, and the | altCertTemplate was incorporated into Section 5.2.1, and the | |||
clarification on POPOSigningKey and on POPOPrivKey was | clarification on POPOSigningKey and on POPOPrivKey was | |||
incorporated into Section 5.2.8. | incorporated into Section 5.2.8. | |||
* Added support for CMS EnvelopedData to different proof-of- | * Added support for CMS EnvelopedData to different POP methods for | |||
possession methods for transferring encrypted private keys, | transferring encrypted private keys, certificates, and challenges | |||
certificates, and challenges to Section 5.2.8. | to Section 5.2.8. | |||
* Added Sections 8.1, 8.5, 8.8, and 8.11 to the security | * Added Sections 8.1, 8.5, 8.8, and 8.11 to the security | |||
considerations. | considerations. | |||
2. Terminology and Abbreviations | 2. Terminology and Abbreviations | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
skipping to change at line 379 ¶ | skipping to change at line 378 ¶ | |||
CA: Certification Authority | CA: Certification Authority | |||
CMP: Certificate Management Protocol | CMP: Certificate Management Protocol | |||
CMS: Cryptographic Message Syntax | CMS: Cryptographic Message Syntax | |||
CRL: Certificate Revocation List | CRL: Certificate Revocation List | |||
CRMF: Certificate Request Message Format | CRMF: Certificate Request Message Format | |||
EE: End Entity | ||||
KEM: Key Encapsulation Mechanism | KEM: Key Encapsulation Mechanism | |||
KGA: Key Generation Authority | KGA: Key Generation Authority | |||
LRA: Local Registration Authority | LRA: Local Registration Authority | |||
MAC: Message Authentication Code | MAC: Message Authentication Code | |||
PKI: Public Key Infrastructure | PKI: Public Key Infrastructure | |||
skipping to change at line 407 ¶ | skipping to change at line 404 ¶ | |||
3. PKI Management Overview | 3. PKI Management Overview | |||
The PKI must be structured to be consistent with the types of | The PKI must be structured to be consistent with the types of | |||
individuals who must administer it. Providing such administrators | individuals who must administer it. Providing such administrators | |||
with unbounded choices not only complicates the software required but | with unbounded choices not only complicates the software required but | |||
also increases the chances that a subtle mistake by an administrator | also increases the chances that a subtle mistake by an administrator | |||
or software developer will result in broader compromise. Similarly, | or software developer will result in broader compromise. Similarly, | |||
restricting administrators with cumbersome mechanisms will cause them | restricting administrators with cumbersome mechanisms will cause them | |||
not to use the PKI. | not to use the PKI. | |||
Management protocols are REQUIRED to support on-line interactions | Management protocols are REQUIRED to support online interactions | |||
between Public Key Infrastructure (PKI) components. For example, a | between PKI components. For example, a management protocol might be | |||
management protocol might be used between a Certification Authority | used between a CA and a client system with which a key pair is | |||
(CA) and a client system with which a key pair is associated or | associated or between two CAs that issue cross-certificates for each | |||
between two CAs that issue cross-certificates for each other. | other. | |||
3.1. PKI Management Model | 3.1. PKI Management Model | |||
Before specifying particular message formats and procedures, we first | Before specifying particular message formats and procedures, we first | |||
define the entities involved in PKI management and their interactions | define the entities involved in PKI management and their interactions | |||
(in terms of the PKI management functions required). We then group | (in terms of the PKI management functions required). We then group | |||
these functions in order to accommodate different identifiable types | these functions in order to accommodate different identifiable types | |||
of end entities. | of end entities. | |||
3.1.1. Definitions of PKI Entities | 3.1.1. Definitions of PKI Entities | |||
The entities involved in PKI management include the end entity (i.e., | The entities involved in PKI management include the end entity (i.e., | |||
the entity to whom the certificate is issued) and the certification | the entity to whom the certificate is issued) and the CA (i.e., the | |||
authority (i.e., the entity that issues the certificate). A | entity that issues the certificate). An RA might also be involved in | |||
registration authority might also be involved in PKI management. | PKI management. | |||
3.1.1.1. Subjects and End Entities | 3.1.1.1. Subjects and End Entities | |||
The term "subject" is used here to refer to the entity to whom the | The term "subject" is used here to refer to the entity to whom the | |||
certificate is issued, typically named in the subject or | certificate is issued, typically named in the subject or | |||
subjectAltName field of a certificate. When we wish to distinguish | subjectAltName field of a certificate. When we wish to distinguish | |||
the tools and/or software used by the subject (e.g., a local | the tools and/or software used by the subject (e.g., a local | |||
certificate management module), we will use the term "subject | certificate management module), we will use the term "subject | |||
equipment". In general, the term "end entity" (EE), rather than | equipment". In general, the term "end entity", rather than | |||
"subject", is preferred in order to avoid confusion with the field | "subject", is preferred in order to avoid confusion with the field | |||
name. It is important to note that the end entities here will | name. It is important to note that the end entities here will | |||
include not only human users of applications but also applications | include not only human users of applications but also applications | |||
themselves (e.g., for Internet Key Exchange Protocol (IKE) / IPsec) | themselves (e.g., for Internet Key Exchange Protocol (IKE) / IPsec) | |||
or devices (e.g., routers or industrial control systems). This | or devices (e.g., routers or industrial control systems). This | |||
factor influences the protocols that the PKI management operations | factor influences the protocols that the PKI management operations | |||
use; for example, application software is far more likely to know | use; for example, application software is far more likely to know | |||
exactly which certificate extensions are required than are human | exactly which certificate extensions are required than are human | |||
users. PKI management entities are also end entities in the sense | users. PKI management entities are also end entities in the sense | |||
that they are sometimes named in the subject or subjectAltName field | that they are sometimes named in the subject or subjectAltName field | |||
skipping to change at line 459 ¶ | skipping to change at line 456 ¶ | |||
All end entities require secure local access to some information -- | All end entities require secure local access to some information -- | |||
at a minimum, their own name and private key, the name of a CA that | at a minimum, their own name and private key, the name of a CA that | |||
is directly trusted by this entity, and that CA's public key (or a | is directly trusted by this entity, and that CA's public key (or a | |||
fingerprint of the public key where a self-certified version is | fingerprint of the public key where a self-certified version is | |||
available elsewhere). Implementations MAY use secure local storage | available elsewhere). Implementations MAY use secure local storage | |||
for more than this minimum (e.g., the end entity's own certificates | for more than this minimum (e.g., the end entity's own certificates | |||
or application-specific information). The form of storage will also | or application-specific information). The form of storage will also | |||
vary -- from files to tamper-resistant cryptographic tokens. The | vary -- from files to tamper-resistant cryptographic tokens. The | |||
information stored in such local, trusted storage is referred to here | information stored in such local, trusted storage is referred to here | |||
as the end entity's Trusted Execution Environment (TEE), also known | as the end entity's TEE, also known as Personal Security Environment | |||
as Personal Security Environment (PSE). | (PSE). | |||
Though TEE formats are beyond the scope of this document (they are | Though TEE formats are beyond the scope of this document (they are | |||
very dependent on equipment, et cetera), a generic interchange format | very dependent on equipment, et cetera), a generic interchange format | |||
for TEEs is defined here: a certification response message (see | for TEEs is defined here: a certification response message (see | |||
Section 5.3.4) MAY be used. | Section 5.3.4) MAY be used. | |||
3.1.1.2. Certification Authority | 3.1.1.2. Certification Authority | |||
The certification authority (CA) may or may not actually be a real | The CA may or may not actually be a real "third party" from the end | |||
"third party" from the end entity's point of view. Quite often, the | entity's point of view. Quite often, the CA will actually belong to | |||
CA will actually belong to the same organization as the end entities | the same organization as the end entities it supports. | |||
it supports. | ||||
Again, we use the term "CA" to refer to the entity named in the | Again, we use the term "CA" to refer to the entity named in the | |||
issuer field of a certificate. When it is necessary to distinguish | issuer field of a certificate. When it is necessary to distinguish | |||
the software or hardware tools used by the CA, we use the term "CA | the software or hardware tools used by the CA, we use the term "CA | |||
equipment". | equipment". | |||
The CA equipment will often include both an "off-line" component and | The CA equipment will often include both an "offline" component and | |||
an "on-line" component, with the CA private key only available to the | an "online" component, with the CA private key only available to the | |||
"off-line" component. This is, however, a matter for implementers | "offline" component. This is, however, a matter for implementers | |||
(though it is also relevant as a policy issue). | (though it is also relevant as a policy issue). | |||
We use the term "root CA" to indicate a CA that is directly trusted | We use the term "root CA" to indicate a CA that is directly trusted | |||
by an end entity; that is, securely acquiring the value of a root CA | by an end entity; that is, securely acquiring the value of a root CA | |||
public key requires some out-of-band step(s). This term is not meant | public key requires some out-of-band step(s). This term is not meant | |||
to imply that a root CA is necessarily at the top of any hierarchy, | to imply that a root CA is necessarily at the top of any hierarchy, | |||
simply that the CA in question is trusted directly. The "root CA" | simply that the CA in question is trusted directly. The "root CA" | |||
may provide its trust anchor information with or without using a | may provide its trust anchor information with or without using a | |||
certificate. In some circumstances, such a certificate may be self- | certificate. In some circumstances, such a certificate may be self- | |||
signed, but in other circumstances, it may be cross-signed, signed by | signed, but in other circumstances, it may be cross-signed, signed by | |||
skipping to change at line 506 ¶ | skipping to change at line 502 ¶ | |||
continues using "root CA" based on the above definition because it is | continues using "root CA" based on the above definition because it is | |||
also present in the ASN.1 syntax that cannot be changed easily. | also present in the ASN.1 syntax that cannot be changed easily. | |||
A "subordinate CA" is one that is not a root CA for the end entity in | A "subordinate CA" is one that is not a root CA for the end entity in | |||
question. Often, a subordinate CA will not be a root CA for any | question. Often, a subordinate CA will not be a root CA for any | |||
entity, but this is not mandatory. | entity, but this is not mandatory. | |||
3.1.1.3. Registration Authority | 3.1.1.3. Registration Authority | |||
In addition to end entities and CAs, many environments call for the | In addition to end entities and CAs, many environments call for the | |||
existence of a Registration Authority (RA) separate from the | existence of an RA separate from the CA. The functions that the RA | |||
Certification Authority. The functions that the registration | may carry out will vary from case to case but MAY include identity | |||
authority may carry out will vary from case to case but MAY include | checking, token distribution, checking certificate requests and | |||
identity checking, token distribution, checking certificate requests | authentication of their origin, revocation reporting, name | |||
and authentication of their origin, revocation reporting, name | ||||
assignment, archival of key pairs, et cetera. | assignment, archival of key pairs, et cetera. | |||
This document views the RA as an OPTIONAL component: When it is not | This document views the RA as an OPTIONAL component: When it is not | |||
present, the CA is assumed to be able to carry out the RA's functions | present, the CA is assumed to be able to carry out the RA's functions | |||
so that the PKI management protocols are the same from the end | so that the PKI management protocols are the same from the end | |||
entity's point of view. | entity's point of view. | |||
Again, we distinguish, where necessary, between the RA and the tools | Again, we distinguish, where necessary, between the RA and the tools | |||
used (the "RA equipment"). | used (the "RA equipment"). | |||
skipping to change at line 537 ¶ | skipping to change at line 532 ¶ | |||
interacting at the moment (so one RA may work with more than one CA | interacting at the moment (so one RA may work with more than one CA | |||
whilst only being certified once). | whilst only being certified once). | |||
In some circumstances, end entities will communicate directly with a | In some circumstances, end entities will communicate directly with a | |||
CA even where an RA is present. For example, for initial | CA even where an RA is present. For example, for initial | |||
registration and/or certification, the end entity may use its RA but | registration and/or certification, the end entity may use its RA but | |||
communicate directly with the CA in order to refresh its certificate. | communicate directly with the CA in order to refresh its certificate. | |||
3.1.1.4. Key Generation Authority | 3.1.1.4. Key Generation Authority | |||
A Key Generation Authority (KGA) is a PKI management entity | A KGA is a PKI management entity generating key pairs on behalf of an | |||
generating key pairs on behalf of an end entity. As the KGA | end entity. As the KGA generates the key pair, it knows the public | |||
generates the key pair, it knows the public and the private part. | and the private part. | |||
This document views the KGA as an OPTIONAL component. When it is not | This document views the KGA as an OPTIONAL component. When it is not | |||
present and central key generation is needed, the CA is assumed to be | present and central key generation is needed, the CA is assumed to be | |||
able to carry out the KGA's functions so that the PKI management | able to carry out the KGA's functions so that the PKI management | |||
protocol messages are the same from the end entity's point of view. | protocol messages are the same from the end entity's point of view. | |||
If certain tasks of a CA are delegated to other components, this | If certain tasks of a CA are delegated to other components, this | |||
delegation needs authorization, which can be indicated by extended | delegation needs authorization, which can be indicated by EKUs (see | |||
key usages (see Section 4.5). | Section 4.5). | |||
Note: When doing central generation of key pairs, implementers should | Note: When doing central generation of key pairs, implementers should | |||
consider the implications of server-side retention on the overall | consider the implications of server-side retention on the overall | |||
security of the system; in some cases, retention is good, for | security of the system; in some cases, retention is good, for | |||
example, for escrow reasons, but in other cases, the server should | example, for escrow reasons, but in other cases, the server should | |||
clear its copy after delivery to the end entity. | clear its copy after delivery to the end entity. | |||
Note: If the CA delegates key generation to a KGA, the KGA can be | Note: If the CA delegates key generation to a KGA, the KGA can be | |||
collocated with the RA. | collocated with the RA. | |||
3.1.2. PKI Management Requirements | 3.1.2. PKI Management Requirements | |||
The protocols given here meet the following requirements on PKI | The protocols given here meet the following requirements on PKI | |||
management | management | |||
1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 | 1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 | |||
standards. | standards, in particular [X509.2019]. | |||
2. It must be possible to regularly update any key pair without | 2. It must be possible to regularly update any key pair without | |||
affecting any other key pair. | affecting any other key pair. | |||
3. The use of confidentiality in PKI management protocols must be | 3. The use of confidentiality in PKI management protocols must be | |||
kept to a minimum in order to ease acceptance in environments | kept to a minimum in order to ease acceptance in environments | |||
where strong confidentiality might cause regulatory problems. | where strong confidentiality might cause regulatory problems. | |||
4. PKI management protocols must allow the use of different | 4. PKI management protocols must allow the use of different | |||
industry-standard cryptographic algorithms (see CMP Algorithms | industry-standard cryptographic algorithms (see CMP Algorithms | |||
skipping to change at line 597 ¶ | skipping to change at line 592 ¶ | |||
Different implementations and different environments may choose | Different implementations and different environments may choose | |||
any of the above approaches. | any of the above approaches. | |||
7. PKI management protocols must support the production of | 7. PKI management protocols must support the production of | |||
Certificate Revocation Lists (CRLs) by allowing certified end | Certificate Revocation Lists (CRLs) by allowing certified end | |||
entities to make requests for the revocation of certificates. | entities to make requests for the revocation of certificates. | |||
This must be done in such a way that the denial-of-service | This must be done in such a way that the denial-of-service | |||
attacks, which are possible, are not made simpler. | attacks, which are possible, are not made simpler. | |||
8. PKI management protocols must be usable over a variety of | 8. PKI management protocols must be usable over a variety of | |||
"transport" mechanisms, specifically including mail, Hypertext | "transport" mechanisms, specifically including email, Hypertext | |||
Transfer Protocol (HTTP), Message Queuing Telemetry Transport | Transfer Protocol (HTTP), Message Queuing Telemetry Transport | |||
(MQTT), Constrained Application Protocol (CoAP), and off-line | (MQTT), Constrained Application Protocol (CoAP), and various | |||
file-based. | offline and non-networked file transfer methods. | |||
9. Final authority for certification creation rests with the CA. | 9. Final authority for certification creation rests with the CA. | |||
No RA or end entity equipment can assume that any certificate | No RA or end entity equipment can assume that any certificate | |||
issued by a CA will contain what was requested; a CA may alter | issued by a CA will contain what was requested; a CA may alter | |||
certificate field values or may add, delete, or alter extensions | certificate field values or may add, delete, or alter extensions | |||
according to its operating policy. In other words, all PKI | according to its operating policy. In other words, all PKI | |||
entities (end entities, RAs, KGAs, and CAs) must be capable of | entities (end entities, RAs, KGAs, and CAs) must be capable of | |||
handling responses to requests for certificates in which the | handling responses to requests for certificates in which the | |||
actual certificate issued is different from that requested (for | actual certificate issued is different from that requested (for | |||
example, a CA may shorten the validity period requested). Note | example, a CA may shorten the validity period requested). Note | |||
that policy may dictate that the CA must not publish or | that policy may dictate that the CA must not publish or | |||
otherwise distribute the certificate until the requesting entity | otherwise distribute the certificate until the requesting entity | |||
has reviewed and accepted the newly created certificate or the | has reviewed and accepted the newly created certificate or the | |||
POP is completed. In case of publication of the certificate | POP is completed. In case of publication of the certificate | |||
(when using indirect POP, see Section 8.11) or a precertificate | (when using indirect POP, see Section 8.11) or a precertificate | |||
in a Certificate Transparency log [RFC9162], the certificate | in a CT log [RFC9162], the certificate must be revoked if it was | |||
must be revoked if it was not accepted by the EE or the POP | not accepted by the end entity or the POP could not be | |||
could not be completed. | completed. | |||
10. A graceful, scheduled changeover from one non-compromised CA key | 10. A graceful, scheduled changeover from one non-compromised CA key | |||
pair to the next (CA key update) must be supported (note that if | pair to the next (CA key update) must be supported (note that if | |||
the CA key is compromised, re-initialization must be performed | the CA key is compromised, re-initialization must be performed | |||
for all entities in the domain of that CA). An end entity whose | for all entities in the domain of that CA). An end entity whose | |||
TEE contains the new CA public key (following a CA key update) | TEE contains the new CA public key (following a CA key update) | |||
may also need to be able to verify certificates verifiable using | may also need to be able to verify certificates verifiable using | |||
the old public key. End entities who directly trust the old CA | the old public key. End entities who directly trust the old CA | |||
key pair may also need to be able to verify certificates signed | key pair may also need to be able to verify certificates signed | |||
using the new CA private key (required for situations where the | using the new CA private key (required for situations where the | |||
skipping to change at line 644 ¶ | skipping to change at line 639 ¶ | |||
must be designed so that end entities will use the same protocol | must be designed so that end entities will use the same protocol | |||
regardless of whether the communication is with an RA or CA. | regardless of whether the communication is with an RA or CA. | |||
Naturally, the end entity must use the correct RA or CA public | Naturally, the end entity must use the correct RA or CA public | |||
key to verify the protection of the communication. | key to verify the protection of the communication. | |||
12. Where an end entity requests a certificate containing a given | 12. Where an end entity requests a certificate containing a given | |||
public key value, the end entity must be ready to demonstrate | public key value, the end entity must be ready to demonstrate | |||
possession of the corresponding private key value. This may be | possession of the corresponding private key value. This may be | |||
accomplished in various ways, depending on the type of | accomplished in various ways, depending on the type of | |||
certification request. See Section 4.3 for details of the in- | certification request. See Section 4.3 for details of the in- | |||
band methods defined for the PKIX-CMP (i.e., Certificate | band methods defined for the PKIX-CMP (i.e., CMP) messages. | |||
Management Protocol) messages. | ||||
3.1.3. PKI Management Operations | 3.1.3. PKI Management Operations | |||
The following diagram shows the relationship between the entities | The following diagram shows the relationship between the entities | |||
defined above in terms of the PKI management operations. The letters | defined above in terms of the PKI management operations. The letters | |||
in the diagram indicate "protocols" in the sense that a defined set | in the diagram indicate "protocols" in the sense that a defined set | |||
of PKI management messages can be sent along each of the lettered | of PKI management messages can be sent along each of the lettered | |||
lines. | lines. | |||
+---+ cert. publish +------------+ j | +---+ cert. publish +------------+ j | |||
skipping to change at line 802 ¶ | skipping to change at line 796 ¶ | |||
the creation of new CRL entries and/or new CRLs: | the creation of new CRL entries and/or new CRLs: | |||
a. revocation request: An authorized person advises a CA of an | a. revocation request: An authorized person advises a CA of an | |||
abnormal situation requiring certificate revocation. | abnormal situation requiring certificate revocation. | |||
7. TEE operations: Whilst the definition of TEE operations (e.g., | 7. TEE operations: Whilst the definition of TEE operations (e.g., | |||
moving a TEE, changing a PIN, etc.) are beyond the scope of this | moving a TEE, changing a PIN, etc.) are beyond the scope of this | |||
specification, we do define a PKIMessage (CertRepMessage) that | specification, we do define a PKIMessage (CertRepMessage) that | |||
can form the basis of such operations. | can form the basis of such operations. | |||
Note that on-line protocols are not the only way of implementing the | Note that online protocols are not the only way of implementing the | |||
above operations. For all operations, there are off-line methods of | above operations. For all operations, there are offline methods of | |||
achieving the same result, and this specification does not mandate | achieving the same result, and this specification does not mandate | |||
use of on-line protocols. For example, when hardware tokens are | use of online protocols. For example, when hardware tokens are used, | |||
used, many of the operations MAY be achieved as part of the physical | many of the operations MAY be achieved as part of the physical token | |||
token delivery. | delivery. | |||
Later sections define a set of standard messages supporting the above | Later sections define a set of standard messages supporting the above | |||
operations. Transfer protocols for conveying these exchanges in | operations. Transfer protocols for conveying these exchanges in | |||
various environments (e.g., off-line: file-based; on-line: mail, HTTP | various environments (e.g., offline: file-based; online: email, HTTP | |||
[RFC9811], MQTT, and CoAP [RFC9482]) are beyond the scope of this | [RFC9811], MQTT, and CoAP [RFC9482]) are beyond the scope of this | |||
document and must be specified separately. Appropriate transfer | document and must be specified separately. Appropriate transfer | |||
protocols MUST be capable of delivering the CMP messages reliably. | protocols MUST be capable of delivering the CMP messages reliably. | |||
CMP provides inbuilt integrity protection and authentication. The | CMP provides inbuilt integrity protection and authentication. The | |||
information communicated unencrypted in CMP messages does not contain | information communicated unencrypted in CMP messages does not contain | |||
sensitive information endangering the security of the PKI when | sensitive information endangering the security of the PKI when | |||
intercepted. However, it might be possible for an eavesdropper to | intercepted. However, it might be possible for an eavesdropper to | |||
utilize the available information to gather confidential technical or | utilize the available information to gather confidential technical or | |||
business-critical information. Therefore, users should consider | business-critical information. Therefore, users should consider | |||
skipping to change at line 864 ¶ | skipping to change at line 858 ¶ | |||
number of the cases that will arise in real use, whilst the optional | number of the cases that will arise in real use, whilst the optional | |||
schemes are available for special cases that arise less frequently. | schemes are available for special cases that arise less frequently. | |||
In this way, we achieve a balance between flexibility and ease of | In this way, we achieve a balance between flexibility and ease of | |||
implementation. | implementation. | |||
Further classification of mandatory and optional schemes addressing | Further classification of mandatory and optional schemes addressing | |||
different environments is available, e.g., in Appendices C and D of | different environments is available, e.g., in Appendices C and D of | |||
this specification on managing human user certificates as well as in | this specification on managing human user certificates as well as in | |||
the Lightweight CMP Profile [RFC9483] on fully automating certificate | the Lightweight CMP Profile [RFC9483] on fully automating certificate | |||
management in a machine-to-machine and Internet of Things (IoT) | management in a machine-to-machine and Internet of Things (IoT) | |||
environment. Also, industry standards like [ETSI-3GPP.33.310] for | environment. Industry standards such as [ETSI-3GPP.33.310] for | |||
mobile networks and [UNISIG.Subset-137] for Rail Automation adopted | mobile networks and [UNISIG.Subset-137] for railroad automation have | |||
CMP and have specified a set of mandatory schemes for their use case. | adopted CMP and defined a series of mandatory schemes for their use | |||
cases. | ||||
We will now describe the classification of initial registration/ | We will now describe the classification of initial registration/ | |||
certification schemes. | certification schemes. | |||
4.2.1. Criteria Used | 4.2.1. Criteria Used | |||
4.2.1.1. Initiation of Registration/Certification | 4.2.1.1. Initiation of Registration/Certification | |||
In terms of the PKI messages that are produced, we can regard the | In terms of the PKI messages that are produced, we can regard the | |||
initiation of the initial registration/certification exchanges as | initiation of the initial registration/certification exchanges as | |||
occurring wherever the first PKI message relating to the end entity | occurring wherever the first PKI message relating to the end entity | |||
is produced. Note that the real-world initiation of the | is produced. Note that the real-world initiation of the | |||
registration/certification procedure may occur elsewhere (e.g., a | registration/certification procedure may occur elsewhere (e.g., a | |||
personnel department may telephone an RA operator or use zero touch | personnel department may telephone an RA operator or use zero-touch | |||
methods like BRSKI [RFC8995] or SZTP [RFC8572]). | methods like BRSKI [RFC8995] or SZTP [RFC8572]). | |||
The possible locations are at the end entity, an RA, or a CA. | The possible locations are at the end entity, an RA, or a CA. | |||
4.2.1.2. End Entity Message Origin Authentication | 4.2.1.2. End Entity Message Origin Authentication | |||
The on-line messages produced by the end entity that requires a | The online messages produced by the end entity that requires a | |||
certificate may be authenticated or not. The requirement here is to | certificate may be authenticated or not. The requirement here is to | |||
authenticate the origin of any messages from the end entity to the | authenticate the origin of any messages from the end entity to the | |||
PKI (CA/RA). | PKI (CA/RA). | |||
In this specification, such authentication is achieved by two | In this specification, such authentication is achieved by two | |||
different means: | different means: | |||
* symmetric: The PKI (CA/RA) issuing the end entity with a secret | * symmetric: The PKI (CA/RA) issuing the end entity with a secret | |||
value (initial authentication key) and reference value (used to | value (initial authentication key) and reference value (used to | |||
identify the secret value) via some out-of-band means. The | identify the secret value) via some out-of-band means. The | |||
initial authentication key can then be used to protect relevant | initial authentication key can then be used to protect relevant | |||
PKI messages. | PKI messages. | |||
* asymmetric: Using a private key and certificate issued by another | * asymmetric: Using a private key and certificate issued by another | |||
PKI trusted for initial authentication, e.g., an Initial Device | PKI trusted for initial authentication, e.g., an Initial Device | |||
Identifier (IDevID) IEEE 802.1AR [IEEE.802.1AR-2018]. The trust | Identifier (IDevID) IEEE 802.1AR [IEEE.802.1AR-2018]. The trust | |||
establishment in this external PKI is out of scope of this | establishment in this external PKI is out of scope of this | |||
document. | document. | |||
Thus, we can classify the initial registration/certification scheme | Thus, we can classify the initial registration/certification scheme | |||
according to whether or not the on-line 'end entity -> PKI management | according to whether or not the online 'end entity -> PKI management | |||
entity' messages are authenticated or not. | entity' messages are authenticated or not. | |||
Note 1: We do not discuss the authentication of the 'PKI management | Note 1: We do not discuss the authentication of the 'PKI management | |||
entity -> end entity' messages here, as this is always | entity -> end entity' messages here, as this is always | |||
REQUIRED. In any case, it can be achieved simply once the | REQUIRED. In any case, it can be achieved simply once the | |||
root-CA public key has been installed at the end entity's | root-CA public key has been installed at the end entity's | |||
equipment or it can be based on the initial authentication | equipment or it can be based on the initial authentication | |||
key. | key. | |||
Note 2: An initial registration/certification procedure can be | Note 2: An initial registration/certification procedure can be | |||
skipping to change at line 962 ¶ | skipping to change at line 957 ¶ | |||
entity may support other schemes specified in profiles of PKIX-CMP, | entity may support other schemes specified in profiles of PKIX-CMP, | |||
such as Appendices C and D or [RFC9483]. | such as Appendices C and D or [RFC9483]. | |||
4.2.2.1. Centralized Scheme | 4.2.2.1. Centralized Scheme | |||
In terms of the classification above, this scheme is, in some ways, | In terms of the classification above, this scheme is, in some ways, | |||
the simplest possible, where: | the simplest possible, where: | |||
* initiation occurs at the certifying CA; | * initiation occurs at the certifying CA; | |||
* no on-line message authentication is required; | * no online message authentication is required; | |||
* "key generation" occurs at the certifying CA (see | * "key generation" occurs at the certifying CA (see | |||
Section 4.2.1.3); and | Section 4.2.1.3); and | |||
* no confirmation message is required. | * no confirmation message is required. | |||
In terms of message flow, this scheme means that the only message | In terms of message flow, this scheme means that the only message | |||
required is sent from the CA to the end entity. The message must | required is sent from the CA to the end entity. The message must | |||
contain the entire TEE for the end entity. Some out-of-band means | contain the entire TEE for the end entity. Some out-of-band means | |||
must be provided to allow the end entity to authenticate the message | must be provided to allow the end entity to authenticate the message | |||
skipping to change at line 996 ¶ | skipping to change at line 991 ¶ | |||
* a confirmation message is recommended. | * a confirmation message is recommended. | |||
Note: An Initial Authentication Key (IAK) can be either a symmetric | Note: An Initial Authentication Key (IAK) can be either a symmetric | |||
key or an asymmetric private key with a certificate issued by another | key or an asymmetric private key with a certificate issued by another | |||
PKI trusted for this purpose. The establishment of such trust is out | PKI trusted for this purpose. The establishment of such trust is out | |||
of scope of this document. | of scope of this document. | |||
In terms of message flow, the basic authenticated scheme is as | In terms of message flow, the basic authenticated scheme is as | |||
follows: | follows: | |||
End entity RA/CA | End Entity RA/CA | |||
========== ============= | ========== ============= | |||
out-of-band distribution of Initial Authentication | out-of-band distribution of Initial Authentication | |||
Key (IAK) and reference value (RA/CA -> EE) | Key (IAK) and reference value (RA/CA -> end entity) | |||
Key generation | Key generation | |||
Creation of certification request | Creation of certification request | |||
Protect request with IAK | Protect request with IAK | |||
-----> certification request -----> | -----> certification request -----> | |||
verify request | verify request | |||
process request | process request | |||
create response | create response | |||
<----- certification response <----- | <----- certification response <----- | |||
handle response | handle response | |||
create confirmation | create confirmation | |||
-----> cert conf message -----> | -----> cert conf message -----> | |||
verify confirmation | verify confirmation | |||
create response | create response | |||
<----- conf ack (optional) <----- | <----- conf ack (optional) <----- | |||
handle response | handle response | |||
Note: Where verification of the cert confirmation message fails, the | Note: Where verification of the cert confirmation message fails, the | |||
RA/CA MUST revoke the newly issued certificate if it has been | RA/CA MUST revoke the newly issued certificate if it has been | |||
published or otherwise made available. | published or otherwise made available. | |||
4.3. Proof-of-Possession (POP) of Private Key | 4.3. POP of Private Key | |||
Proof-of-possession (POP) is where a PKI management entity (CA/RA) | POP is where a PKI management entity (CA/RA) verifies if an end | |||
verifies if an end entity has access to the private key corresponding | entity has access to the private key corresponding to a given public | |||
to a given public key. The question of whether, and in what | key. The question of whether, and in what circumstances, POPs add | |||
circumstances, POPs add value to a PKI is a debate as old as PKI | value to a PKI is a debate as old as PKI itself! See Section 8.1 for | |||
itself! See Section 8.1 for a further discussion on the necessity of | a further discussion on the necessity of POP in PKI. | |||
proof-of-possession in PKI. | ||||
The PKI management operations specified here make it possible for an | The PKI management operations specified here make it possible for an | |||
end entity to prove to a CA/RA that it has possession of (i.e., is | end entity to prove to a CA/RA that it has possession of (i.e., is | |||
able to use) the private key corresponding to the public key for | able to use) the private key corresponding to the public key for | |||
which a certificate is requested (see Section 5.2.8 for different POP | which a certificate is requested (see Section 5.2.8 for different POP | |||
methods). A given CA/RA is free to choose how to enforce POP (e.g., | methods). A given CA/RA is free to choose how to enforce POP (e.g., | |||
out-of-band procedural means versus PKIX-CMP in-band messages) in its | out-of-band procedural means versus PKIX-CMP in-band messages) in its | |||
certification exchanges (i.e., this may be a policy issue). However, | certification exchanges (i.e., this may be a policy issue). However, | |||
it is REQUIRED that CAs/RAs MUST enforce POP by some means because | it is REQUIRED that CAs/RAs MUST enforce POP by some means because | |||
there are currently many non-PKIX operational protocols in use | there are currently many non-PKIX operational protocols in use | |||
(various electronic mail protocols are one example) that do not | (various electronic mail protocols are one example) that do not | |||
explicitly check the binding between the end entity and the private | explicitly check the binding between the end entity and the private | |||
key. Until operational protocols that do verify the binding (for | key. Until operational protocols that do verify the binding (for | |||
signature, encryption, key agreement, and KEM key pairs) exist, and | signature, encryption, key agreement, and KEM key pairs) exist, and | |||
are ubiquitous, this binding can only be assumed to have been | are ubiquitous, this binding can only be assumed to have been | |||
verified by the CA/RA. Therefore, if the binding is not verified by | verified by the CA/RA. Therefore, if the binding is not verified by | |||
the CA/RA, certificates in the Internet Public Key Infrastructure end | the CA/RA, certificates in the Internet PKI end up being somewhat | |||
up being somewhat less meaningful. | less meaningful. | |||
POP is accomplished in different ways depending upon the type of key | POP is accomplished in different ways depending upon the type of key | |||
for which a certificate is requested. If a key can be used for | for which a certificate is requested. If a key can be used for | |||
multiple purposes (e.g., an RSA key), then any appropriate method MAY | multiple purposes (e.g., an RSA key), then any appropriate method MAY | |||
be used (e.g., a key that may be used for signing, as well as other | be used (e.g., a key that may be used for signing, as well as other | |||
purposes, MUST NOT be sent to the CA/RA in order to prove possession | purposes, MUST NOT be sent to the CA/RA in order to prove possession | |||
unless archival of the private key is explicitly desired). | unless archival of the private key is explicitly desired). | |||
This specification explicitly allows for cases where an end entity | This specification explicitly allows for cases where an end entity | |||
supplies the relevant proof to an RA and the RA subsequently attests | supplies the relevant proof to an RA and the RA subsequently attests | |||
skipping to change at line 1078 ¶ | skipping to change at line 1072 ¶ | |||
4.3.2. Encryption Keys | 4.3.2. Encryption Keys | |||
For encryption keys, the end entity can provide the private key to | For encryption keys, the end entity can provide the private key to | |||
the CA/RA (e.g., for archiving), see Section 5.2.8.3.1, or can be | the CA/RA (e.g., for archiving), see Section 5.2.8.3.1, or can be | |||
required to decrypt a value in order to prove possession of the | required to decrypt a value in order to prove possession of the | |||
private key. Decrypting a value can be achieved either directly (see | private key. Decrypting a value can be achieved either directly (see | |||
Section 5.2.8.3.3) or indirectly (see Section 5.2.8.3.2). | Section 5.2.8.3.3) or indirectly (see Section 5.2.8.3.2). | |||
The direct method is for the RA/CA to issue a random challenge to | The direct method is for the RA/CA to issue a random challenge to | |||
which an immediate response by the EE is required. | which an immediate response by the end entity is required. | |||
The indirect method is to issue a certificate that is encrypted for | The indirect method is to issue a certificate that is encrypted for | |||
the end entity (and have the end entity demonstrate its ability to | the end entity (and have the end entity demonstrate its ability to | |||
decrypt this certificate in the confirmation message). This allows a | decrypt this certificate in the confirmation message). This allows a | |||
CA to issue a certificate in a form that can only be used by the | CA to issue a certificate in a form that can only be used by the | |||
intended end entity. | intended end entity. | |||
This specification encourages use of the indirect method because it | This specification encourages use of the indirect method because it | |||
requires no extra messages to be sent (i.e., the proof can be | requires no extra messages to be sent (i.e., the proof can be | |||
demonstrated using the {request, response, confirmation} triple of | demonstrated using the {request, response, confirmation} triple of | |||
messages). | messages). | |||
4.3.3. Key Agreement Keys | 4.3.3. Key Agreement Keys | |||
For key agreement keys, the end entity and the PKI management entity | For key agreement keys, the end entity and the PKI management entity | |||
(i.e., CA or RA) must establish a shared secret key in order to prove | (i.e., CA or RA) must establish a shared secret key in order to prove | |||
that the end entity has possession of the private key. | that the end entity has possession of the private key. | |||
Note that this need not impose any restrictions on the keys that can | Note that this need not impose any restrictions on the keys that can | |||
be certified by a given CA. In particular, for Diffie-Hellman keys, | be certified by a given CA. In particular, for Diffie-Hellman (DH) | |||
the end entity may freely choose its algorithm parameters provided | keys, the end entity may freely choose its algorithm parameters | |||
that the CA can generate a short-term (or one-time) key pair with the | provided that the CA can generate a short-term (or one-time) key pair | |||
appropriate parameters when necessary. | with the appropriate parameters when necessary. | |||
4.3.4. Key Encapsulation Mechanism Keys | 4.3.4. KEM Keys | |||
For key encapsulation mechanism (KEM) keys, the end entity can | For KEM keys, the end entity can provide the private key to the CA/RA | |||
provide the private key to the CA/RA (e.g., for archiving), see | (e.g., for archiving), see Section 5.2.8.3.1, or can be required to | |||
Section 5.2.8.3.1, or can be required to decrypt a value in order to | decrypt a value in order to prove possession of the private key. | |||
prove possession of the private key. Decrypting a value can be | Decrypting a value can be achieved either directly (see | |||
achieved either directly (see Section 5.2.8.3.3) or indirectly (see | Section 5.2.8.3.3) or indirectly (see Section 5.2.8.3.2). | |||
Section 5.2.8.3.2). | ||||
Note: A definition of key encapsulation mechanisms can be found in | Note: A definition of KEMs can be found in Section 1 of [RFC9629]. | |||
Section 1 of [RFC9629]. | ||||
The direct method is for the RA/CA to issue a random challenge to | The direct method is for the RA/CA to issue a random challenge to | |||
which an immediate response by the EE is required. | which an immediate response by the end entity is required. | |||
The indirect method is to issue a certificate that is encrypted for | The indirect method is to issue a certificate that is encrypted for | |||
the end entity using a shared secret key derived from a key | the end entity using a shared secret key derived from a key | |||
encapsulated using the public key (and have the end entity | encapsulated using the public key (and have the end entity | |||
demonstrate its ability to use its private key for decapsulation of | demonstrate its ability to use its private key for decapsulation of | |||
the KEM ciphertext, derive the shared secret key, decrypt this | the KEM ciphertext, derive the shared secret key, decrypt this | |||
certificate, and provide a hash of the certificate in the | certificate, and provide a hash of the certificate in the | |||
confirmation message). This allows a CA to issue a certificate in a | confirmation message). This allows a CA to issue a certificate in a | |||
form that can only be used by the intended end entity. | form that can only be used by the intended end entity. | |||
skipping to change at line 1169 ¶ | skipping to change at line 1161 ¶ | |||
When a CA changes its key pair, those entities who have acquired the | When a CA changes its key pair, those entities who have acquired the | |||
old CA public key via "out-of-band" means are most affected. These | old CA public key via "out-of-band" means are most affected. These | |||
end entities need to acquire the new CA public key in a trusted way. | end entities need to acquire the new CA public key in a trusted way. | |||
This may be achieved "out-of-band" by using a repository or by using | This may be achieved "out-of-band" by using a repository or by using | |||
online messages also containing the link certificates "new with old". | online messages also containing the link certificates "new with old". | |||
Once the end entity acquired and properly verified the new CA public | Once the end entity acquired and properly verified the new CA public | |||
key, it must load the new trust anchor information into its trusted | key, it must load the new trust anchor information into its trusted | |||
store. | store. | |||
The data structure used to protect the new and old CA public keys is | The data structure used to protect the new and old CA public keys is | |||
typically a standard X.509 v3 certificate (which may also contain | typically a standard X.509v3 certificate (which may also contain | |||
extensions). There are no new data structures required. | extensions). There are no new data structures required. | |||
Note: Sometimes self-signed root CA certificates do not make use of | Note: Sometimes self-signed root CA certificates do not make use of | |||
X.509 v3 extensions and may be X.509 v1 certificates. Therefore, a | X.509v3 extensions and may be X.509v1 certificates. Therefore, a | |||
root CA key update must be able to work for version 1 certificates. | root CA key update must be able to work for version 1 certificates. | |||
The use of the X.509 v3 KeyIdentifier extension is recommended for | The use of the X.509v3 KeyIdentifier extension is recommended for | |||
easier path building. | easier path building. | |||
Note: While the scheme could be generalized to cover cases where the | Note: While the scheme could be generalized to cover cases where the | |||
CA updates its key pair more than once during the validity period of | CA updates its key pair more than once during the validity period of | |||
one of its end entities' certificates, this generalization seems of | one of its end entities' certificates, this generalization seems of | |||
dubious value. Not having this generalization simply means that the | dubious value. Not having this generalization simply means that the | |||
validity periods of certificates issued with the old CA key pair | validity periods of certificates issued with the old CA key pair | |||
cannot exceed the end of the "old with new" certificate validity | cannot exceed the end of the "old with new" certificate validity | |||
period. | period. | |||
skipping to change at line 1360 ¶ | skipping to change at line 1352 ¶ | |||
4.4.3. Revocation - Change of the CA Key | 4.4.3. Revocation - Change of the CA Key | |||
As we saw above, the verification of a certificate becomes more | As we saw above, the verification of a certificate becomes more | |||
complex once the CA is allowed to change its key. This is also true | complex once the CA is allowed to change its key. This is also true | |||
for revocation checks, as the CA may have signed the CRL using a | for revocation checks, as the CA may have signed the CRL using a | |||
newer private key than the one within the user's TEE. | newer private key than the one within the user's TEE. | |||
The analysis of the alternatives is the same as for certificate | The analysis of the alternatives is the same as for certificate | |||
verification. | verification. | |||
4.5. Extended Key Usage for PKI Entities | 4.5. EKU for PKI Entities | |||
The extended key usage (EKU) extension indicates the purposes for | The EKU extension indicates the purposes for which the certified key | |||
which the certified key pair may be used. Therefore, it restricts | pair may be used. Therefore, it restricts the use of a certificate | |||
the use of a certificate to specific applications. | to specific applications. | |||
A CA may want to delegate parts of its duties to other PKI management | A CA may want to delegate parts of its duties to other PKI management | |||
entities. This section provides a mechanism to both prove this | entities. This section provides a mechanism to both prove this | |||
delegation and enable automated means for checking the authorization | delegation and enable automated means for checking the authorization | |||
of this delegation. Such delegation may also be expressed by other | of this delegation. Such delegation may also be expressed by other | |||
means, e.g., explicit configuration. | means, e.g., explicit configuration. | |||
To offer automatic validation for the delegation of a role by a CA to | To offer automatic validation for the delegation of a role by a CA to | |||
another entity, the certificates used for CMP message protection or | another entity, the certificates used for CMP message protection or | |||
signed data for central key generation MUST be issued by the | signed data for central key generation MUST be issued by the | |||
skipping to change at line 1395 ¶ | skipping to change at line 1387 ¶ | |||
id-kp-cmcRA OBJECT IDENTIFIER ::= { | id-kp-cmcRA OBJECT IDENTIFIER ::= { | |||
iso(1) identified-organization(3) dod(6) internet(1) | iso(1) identified-organization(3) dod(6) internet(1) | |||
security(5) mechanisms(5) pkix(7) kp(3) 28 } | security(5) mechanisms(5) pkix(7) kp(3) 28 } | |||
id-kp-cmKGA OBJECT IDENTIFIER ::= { | id-kp-cmKGA OBJECT IDENTIFIER ::= { | |||
iso(1) identified-organization(3) dod(6) internet(1) | iso(1) identified-organization(3) dod(6) internet(1) | |||
security(5) mechanisms(5) pkix(7) kp(3) 32 } | security(5) mechanisms(5) pkix(7) kp(3) 32 } | |||
Note: Section 2.10 of [RFC6402] specifies OIDs for a Certificate | Note: Section 2.10 of [RFC6402] specifies OIDs for a Certificate | |||
Management over CMS (CMC) CA and a CMC RA. As the functionality of a | Management over CMS (CMC) CA and a CMC RA. As the functionality of a | |||
CA and RA is not specific to any certificate management protocol | CA and RA is not specific to any protocol used for managing | |||
(such as CMC or CMP), these EKUs are reused by CMP. | certificates (such as CMC or CMP), these EKUs are reused by CMP. | |||
The meaning of the id-kp-cmKGA EKU is as follows: | The meaning of the id-kp-cmKGA EKU is as follows: | |||
CMP KGA: CMP key generation authorities are CAs or are identified by | CMP KGA: CMP KGAs are CAs or are identified by the id-kp-cmKGA EKU. | |||
the id-kp-cmKGA extended key usage. The CMP KGA knows the private | The CMP KGA knows the private key it generated on behalf of the | |||
key it generated on behalf of the end entity. This is a very | end entity. This is a very sensitive service and needs specific | |||
sensitive service and needs specific authorization, which by | authorization, which by default is with the CA certificate itself. | |||
default is with the CA certificate itself. The CA may delegate | The CA may delegate its authorization by placing the id-kp-cmKGA | |||
its authorization by placing the id-kp-cmKGA extended key usage in | EKU in the certificate used to authenticate the origin of the | |||
the certificate used to authenticate the origin of the generated | generated private key. The authorization may also be determined | |||
private key. The authorization may also be determined through | through local configuration of the end entity. | |||
local configuration of the end entity. | ||||
5. Data Structures | 5. Data Structures | |||
This section contains descriptions of the data structures required | This section contains descriptions of the data structures required | |||
for PKI management messages. Section 6 describes constraints on | for PKI management messages. Section 6 describes constraints on | |||
their values and the sequence of events for each of the various PKI | their values and the sequence of events for each of the various PKI | |||
management operations. | management operations. | |||
5.1. Overall PKI Message | 5.1. Overall PKI Message | |||
skipping to change at line 1487 ¶ | skipping to change at line 1478 ¶ | |||
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String | PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String | |||
The usage of the protocol version number (pvno) is described in | The usage of the protocol version number (pvno) is described in | |||
Section 7. | Section 7. | |||
The sender field contains the name of the sender of the PKIMessage. | The sender field contains the name of the sender of the PKIMessage. | |||
This name (in conjunction with senderKID, if supplied) should be | This name (in conjunction with senderKID, if supplied) should be | |||
sufficient to indicate the key to use to verify the protection on the | sufficient to indicate the key to use to verify the protection on the | |||
message. If nothing about the sender is known to the sending entity | message. If nothing about the sender is known to the sending entity | |||
(e.g., in the initial request message, where the end entity may not | (e.g., in the initial request message, where the end entity may not | |||
know its own Distinguished Name (DN), email name, IP address, etc.), | know its own DN, email name, IP address, etc.), then the "sender" | |||
then the "sender" field MUST contain a "NULL-DN" value in the | field MUST contain a "NULL-DN" value in the directoryName choice. A | |||
directoryName choice. A "NULL-DN" is a SEQUENCE OF relative | "NULL-DN" is a SEQUENCE OF relative DNs of zero length and is encoded | |||
distinguished names of zero length and is encoded as 0x3000. In such | as 0x3000. In such a case, the senderKID field MUST hold an | |||
a case, the senderKID field MUST hold an identifier (i.e., a | identifier (i.e., a reference number) that indicates to the receiver | |||
reference number) that indicates to the receiver the appropriate | the appropriate shared secret information to use to verify the | |||
shared secret information to use to verify the message. | message. | |||
The recipient field contains the name of the recipient of the | The recipient field contains the name of the recipient of the | |||
PKIMessage. This name (in conjunction with recipKID, if supplied) | PKIMessage. This name (in conjunction with recipKID, if supplied) | |||
should be usable to verify the protection on the message. | should be usable to verify the protection on the message. | |||
The protectionAlg field specifies the algorithm used to protect the | The protectionAlg field specifies the algorithm used to protect the | |||
message. If no protection bits are supplied (note that PKIProtection | message. If no protection bits are supplied (note that PKIProtection | |||
is OPTIONAL), then this field MUST be omitted; if protection bits are | is OPTIONAL), then this field MUST be omitted; if protection bits are | |||
supplied, then this field MUST be supplied. | supplied, then this field MUST be supplied. | |||
senderKID and recipKID are usable to indicate which keys have been | senderKID and recipKID are usable to indicate which keys have been | |||
used to protect the message (recipKID will normally only be required | used to protect the message (recipKID will normally only be required | |||
where protection of the message uses Diffie-Hellman (DH) or Elliptic | where protection of the message uses DH or Elliptic Curve Diffie- | |||
Curve Diffie-Hellman (ECDH) keys). These fields MUST be used if | Hellman (ECDH) keys). These fields MUST be used if required to | |||
required to uniquely identify a key (e.g., if more than one key is | uniquely identify a key (e.g., if more than one key is associated | |||
associated with a given sender name). The senderKID SHOULD be used | with a given sender name). The senderKID SHOULD be used in any case. | |||
in any case. | ||||
Note: The recommendation of using senderKID has changed since | Note: The recommendation of using senderKID has changed since | |||
[RFC4210], where it was recommended to be omitted if not needed to | [RFC4210], where it was recommended to be omitted if not needed to | |||
identify the protection key. | identify the protection key. | |||
The transactionID field within the message header is to be used to | The transactionID field within the message header is to be used to | |||
allow the recipient of a message to correlate this with an ongoing | allow the recipient of a message to correlate this with an ongoing | |||
transaction. This is needed for all transactions that consist of | transaction. This is needed for all transactions that consist of | |||
more than just a single request/response pair. For transactions that | more than just a single request/response pair. For transactions that | |||
consist of a single request/response pair, the rules are as follows. | consist of a single request/response pair, the rules are as follows. | |||
skipping to change at line 1584 ¶ | skipping to change at line 1574 ¶ | |||
include a language tag [RFC5646] to indicate the language of the | include a language tag [RFC5646] to indicate the language of the | |||
contained text. The first language used in this sequence indicates | contained text. The first language used in this sequence indicates | |||
the desired language for replies. | the desired language for replies. | |||
The generalInfo field may be used to send machine-processable | The generalInfo field may be used to send machine-processable | |||
additional data to the recipient. The following generalInfo | additional data to the recipient. The following generalInfo | |||
extensions are defined and MAY be supported. | extensions are defined and MAY be supported. | |||
5.1.1.1. ImplicitConfirm | 5.1.1.1. ImplicitConfirm | |||
This is used by the EE to inform the CA or RA that it does not wish | This is used by the end entity to inform the CA or RA that it does | |||
to send a certificate confirmation for issued certificates. | not wish to send a certificate confirmation for issued certificates. | |||
id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} | id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} | |||
ImplicitConfirmValue ::= NULL | ImplicitConfirmValue ::= NULL | |||
If the CA grants the request to the EE, it MUST put the same | If the CA grants the request to the end entity, it MUST put the same | |||
extension in the PKIHeader of the response. If the EE does not find | extension in the PKIHeader of the response. If the end entity does | |||
the extension in the response, it MUST send the certificate | not find the extension in the response, it MUST send the certificate | |||
confirmation. | confirmation. | |||
5.1.1.2. ConfirmWaitTime | 5.1.1.2. ConfirmWaitTime | |||
This is used by the CA or RA to inform the EE how long it intends to | This is used by the CA or RA to inform the end entity how long it | |||
wait for the certificate confirmation before revoking the certificate | intends to wait for the certificate confirmation before revoking the | |||
and deleting the transaction. | certificate and deleting the transaction. | |||
id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} | id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} | |||
ConfirmWaitTimeValue ::= GeneralizedTime | ConfirmWaitTimeValue ::= GeneralizedTime | |||
5.1.1.3. OrigPKIMessage | 5.1.1.3. OrigPKIMessage | |||
An RA MAY include the original PKIMessage from the EE in the | An RA MAY include the original PKIMessage from the end entity in the | |||
generalInfo field of the PKIHeader of a PKIMessage. This is used by | generalInfo field of the PKIHeader of a PKIMessage. This is used by | |||
the RA to inform the CA of the original PKIMessage that it received | the RA to inform the CA of the original PKIMessage that it received | |||
from the EE and modified in some way (e.g., added or modified | from the end entity and modified in some way (e.g., added or modified | |||
particular field values or added new extensions) before forwarding | particular field values or added new extensions) before forwarding | |||
the new PKIMessage. This accommodates, for example, cases in which | the new PKIMessage. This accommodates, for example, cases in which | |||
the CA wishes to check the message origin, the POP, or other | the CA wishes to check the message origin, the POP, or other | |||
information on the original EE message. | information on the original end entity message. | |||
Note: If the changes made by the RA to the original PKIMessage break | Note: If the changes made by the RA to the original PKIMessage break | |||
the POP of a certificate request, the RA can set the popo field of | the POP of a certificate request, the RA can set the popo field of | |||
the new PKIMessage to raVerified (see Section 5.2.8.4). | the new PKIMessage to raVerified (see Section 5.2.8.4). | |||
Unless the OrigPKIMessage infoValue is in the header of a nested | Unless the OrigPKIMessage infoValue is in the header of a nested | |||
message, it MUST contain exactly one PKIMessage. The contents of | message, it MUST contain exactly one PKIMessage. The contents of | |||
OrigPKIMessage infoValue in the header of a nested message MAY | OrigPKIMessage infoValue in the header of a nested message MAY | |||
contain multiple PKIMessage structures, which MUST be in the same | contain multiple PKIMessage structures, which MUST be in the same | |||
order as the PKIMessage structures in PKIBody. | order as the PKIMessage structures in PKIBody. | |||
id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} | id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} | |||
OrigPKIMessageValue ::= PKIMessages | OrigPKIMessageValue ::= PKIMessages | |||
5.1.1.4. CertProfile | 5.1.1.4. CertProfile | |||
This is used by the EE to indicate specific certificate profiles, | This is used by the end entity to indicate specific certificate | |||
e.g., when requesting a new certificate or a certificate request | profiles, e.g., when requesting a new certificate or a certificate | |||
template (see Section 5.3.19.16). | request template (see Section 5.3.19.16). | |||
id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} | id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} | |||
CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF UTF8String | CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF UTF8String | |||
When used in a p10cr message, the CertProfileValue sequence MUST NOT | When used in a p10cr message, the CertProfileValue sequence MUST NOT | |||
contain multiple certificate profile names. When used in an | contain multiple certificate profile names. When used in an | |||
ir/cr/kur/genm message, the CertProfileValue sequence MUST NOT | ir/cr/kur/genm message, the CertProfileValue sequence MUST NOT | |||
contain more certificate profile names than the number of CertReqMsg | contain more certificate profile names than the number of CertReqMsg | |||
or GenMsgContent InfoTypeAndValue elements contained in the message | or GenMsgContent InfoTypeAndValue elements contained in the message | |||
body. | body. | |||
skipping to change at line 1734 ¶ | skipping to change at line 1724 ¶ | |||
There MAY be cases in which the PKIProtection BIT STRING is | There MAY be cases in which the PKIProtection BIT STRING is | |||
deliberately not used to protect a message (i.e., this OPTIONAL field | deliberately not used to protect a message (i.e., this OPTIONAL field | |||
is omitted) because other protection, external to PKIX, will be | is omitted) because other protection, external to PKIX, will be | |||
applied instead. Such a choice is explicitly allowed in this | applied instead. Such a choice is explicitly allowed in this | |||
specification. Examples of such external protection include CMS | specification. Examples of such external protection include CMS | |||
[RFC5652] and Security Multiparts [RFC1847] encapsulation of the | [RFC5652] and Security Multiparts [RFC1847] encapsulation of the | |||
PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the | PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the | |||
relevant PKIHeader information is securely carried in the external | relevant PKIHeader information is securely carried in the external | |||
mechanism). It is noted, however, that many such external mechanisms | mechanism). It is noted, however, that many such external mechanisms | |||
require that the end entity already possesses a public-key | require that the end entity already possesses a public-key | |||
certificate, a unique Distinguished Name, and/or other such | certificate, a unique DN, and/or other such infrastructure-related | |||
infrastructure-related information. Thus, they may not be | information. Thus, they may not be appropriate for initial | |||
appropriate for initial registration, key-recovery, or any other | registration, key-recovery, or any other process with "bootstrapping" | |||
process with "boot-strapping" characteristics. For those cases, it | characteristics. For those cases, it may be necessary that the | |||
may be necessary that the PKIProtection parameter be used. In the | PKIProtection parameter be used. In the future, if/when external | |||
future, if/when external mechanisms are modified to accommodate boot- | mechanisms are modified to accommodate bootstrapping scenarios, the | |||
strapping scenarios, the use of PKIProtection may become rare or non- | use of PKIProtection may become rare or non-existent. | |||
existent. | ||||
Depending on the circumstances, the PKIProtection bits may contain a | Depending on the circumstances, the PKIProtection bits may contain a | |||
Message Authentication Code (MAC) or signature. Only the following | MAC or signature. Only the following cases can occur: | |||
cases can occur: | ||||
5.1.3.1. Shared Secret Information | 5.1.3.1. Shared Secret Information | |||
In this case, the sender and recipient share secret information with | In this case, the sender and recipient share secret information with | |||
sufficient entropy (established via out-of-band means). | sufficient entropy (established via out-of-band means). | |||
PKIProtection will contain a MAC value, and the protectionAlg MAY be | PKIProtection will contain a MAC value, and the protectionAlg MAY be | |||
one of the options described in Section 6.1 of CMP Algorithms | one of the options described in Section 6.1 of CMP Algorithms | |||
[RFC9481]. | [RFC9481]. | |||
The algorithm identifier id-PasswordBasedMac is defined in | The algorithm identifier id-PasswordBasedMac is defined in | |||
skipping to change at line 1770 ¶ | skipping to change at line 1758 ¶ | |||
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} | id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} | |||
PBMParameter ::= SEQUENCE { | PBMParameter ::= SEQUENCE { | |||
salt OCTET STRING, | salt OCTET STRING, | |||
owf AlgorithmIdentifier, | owf AlgorithmIdentifier, | |||
iterationCount INTEGER, | iterationCount INTEGER, | |||
mac AlgorithmIdentifier | mac AlgorithmIdentifier | |||
} | } | |||
The following text gives a method of key expansion to be used when | The following text gives a method of key expansion to be used when | |||
the MAC algorithm requires an input length that is larger than the | the MAC algorithm requires an input length that is larger than the | |||
size of the one-way function. | size of the one-way function (OWF). | |||
Note: Section 4.4 of [RFC4211] and [RFC9045] do not mention this key | Note: Section 4.4 of [RFC4211] and [RFC9045] do not mention this key | |||
expansion method or give an example using HMAC algorithms where key | expansion method or give an example using HMAC algorithms where key | |||
expansion is not needed. It is recognized that this omission in | expansion is not needed. It is recognized that this omission in | |||
[RFC4211] can lead to confusion and possible incompatibility if key | [RFC4211] can lead to confusion and possible incompatibility if key | |||
expansion [RFC4210] is not used when needed. Therefore, when key | expansion [RFC4210] is not used when needed. Therefore, when key | |||
expansion is required (when K > H), the key expansion defined in the | expansion is required (when K > H), the key expansion defined in the | |||
following text MUST be used. | following text MUST be used. | |||
In the above protectionAlg, the salt value is appended to the shared | In the above protectionAlg, the salt value is appended to the shared | |||
secret input. The one-way function (OWF) is then applied | secret input. The OWF is then applied iterationCount times, where | |||
iterationCount times, where the salted secret is the input to the | the salted secret is the input to the first iteration and, for each | |||
first iteration and, for each successive iteration, the input is set | successive iteration, the input is set to be the output of the | |||
to be the output of the previous iteration. The output of the final | previous iteration. The output of the final iteration (called | |||
iteration (called "BASEKEY" for ease of reference, with a size of | "BASEKEY" for ease of reference, with a size of "H") is what is used | |||
"H") is what is used to form the symmetric key. If the MAC algorithm | to form the symmetric key. If the MAC algorithm requires a K-bit key | |||
requires a K-bit key and K <= H, then the most significant K bits of | and K <= H, then the most significant K bits of BASEKEY are used. If | |||
BASEKEY are used. If K > H, then all of BASEKEY is used for the most | K > H, then all of BASEKEY is used for the most significant H bits of | |||
significant H bits of the key, OWF("1" || BASEKEY) is used for the | the key, OWF("1" || BASEKEY) is used for the next most significant H | |||
next most significant H bits of the key, OWF("2" || BASEKEY) is used | bits of the key, OWF("2" || BASEKEY) is used for the next most | |||
for the next most significant H bits of the key, and so on, until all | significant H bits of the key, and so on, until all K bits have been | |||
K bits have been derived. [Here "N" is the ASCII byte encoding the | derived. [Here "N" is the ASCII byte encoding the number N and "||" | |||
number N and "||" represents concatenation.] | represents concatenation.] | |||
Note: It is RECOMMENDED that the fields of PBMParameter remain | Note: It is RECOMMENDED that the fields of PBMParameter remain | |||
constant throughout the messages of a single transaction (e.g., | constant throughout the messages of a single transaction (e.g., | |||
ir/ip/certConf/pkiConf) to reduce the overhead associated with | ir/ip/certConf/pkiConf) to reduce the overhead associated with | |||
PasswordBasedMac computation. | PasswordBasedMac computation. | |||
5.1.3.2. DH Key Pairs | 5.1.3.2. DH Key Pairs | |||
Where the sender and receiver possess finite-field or elliptic-curve- | Where the sender and receiver possess finite-field or elliptic-curve- | |||
based Diffie-Hellman certificates with compatible DH parameters in | based DH certificates with compatible DH parameters in order to | |||
order to protect the message, the end entity must generate a | protect the message, the end entity must generate a symmetric key | |||
symmetric key based on its private DH key value and the DH public key | based on its private DH key value and the DH public key of the | |||
of the recipient of the PKI message. PKIProtection will contain a | recipient of the PKI message. PKIProtection will contain a MAC value | |||
MAC value keyed with this derived symmetric key, and the | keyed with this derived symmetric key, and the protectionAlg will be | |||
protectionAlg will be the following: | the following: | |||
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} | id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} | |||
DHBMParameter ::= SEQUENCE { | DHBMParameter ::= SEQUENCE { | |||
owf AlgorithmIdentifier, | owf AlgorithmIdentifier, | |||
-- AlgId for a One-Way Function | -- AlgId for an OWF | |||
mac AlgorithmIdentifier | mac AlgorithmIdentifier | |||
-- the MAC AlgId | -- the MAC AlgId | |||
} | } | |||
In the above protectionAlg, OWF is applied to the result of the | In the above protectionAlg, OWF is applied to the result of the DH | |||
Diffie-Hellman computation. The OWF output (called "BASEKEY" for | computation. The OWF output (called "BASEKEY" for ease of reference, | |||
ease of reference, with a size of "H") is what is used to form the | with a size of "H") is what is used to form the symmetric key. If | |||
symmetric key. If the MAC algorithm requires a K-bit key and K <= H, | the MAC algorithm requires a K-bit key and K <= H, then the most | |||
then the most significant K bits of BASEKEY are used. If K > H, then | significant K bits of BASEKEY are used. If K > H, then all of | |||
all of BASEKEY is used for the most significant H bits of the key, | BASEKEY is used for the most significant H bits of the key, | |||
OWF("1" || BASEKEY) is used for the next most significant H bits of | OWF("1" || BASEKEY) is used for the next most significant H bits of | |||
the key, OWF("2" || BASEKEY) is used for the next most significant H | the key, OWF("2" || BASEKEY) is used for the next most significant H | |||
bits of the key, and so on, until all K bits have been derived. | bits of the key, and so on, until all K bits have been derived. | |||
[Here "N" is the ASCII byte encoding the number N and "||" represents | [Here "N" is the ASCII byte encoding the number N and "||" represents | |||
concatenation.] | concatenation.] | |||
Note: Hash algorithms that can be used as one-way functions are | Note: Hash algorithms that can be used as OWFs are listed in | |||
listed in Section 2 of CMP Algorithms [RFC9481]. | Section 2 of CMP Algorithms [RFC9481]. | |||
5.1.3.3. Signature | 5.1.3.3. Signature | |||
In this case, the sender possesses a signature key pair and simply | In this case, the sender possesses a signature key pair and simply | |||
signs the PKI message. PKIProtection will contain the signature | signs the PKI message. PKIProtection will contain the signature | |||
value and the protectionAlg will be an AlgorithmIdentifier for a | value and the protectionAlg will be an AlgorithmIdentifier for a | |||
digital signature, which MAY be one of the options described in | digital signature, which MAY be one of the options described in | |||
Section 3 of CMP Algorithms [RFC9481]. | Section 3 of CMP Algorithms [RFC9481]. | |||
5.1.3.4. Key Encapsulation | 5.1.3.4. Key Encapsulation | |||
In case the sender of a message has a Key Encapsulation Mechanism | In case the sender of a message has a KEM key pair, it can be used to | |||
(KEM) key pair, it can be used to establish a shared secret key for | establish a shared secret key for MAC-based message protection. This | |||
MAC-based message protection. This can be used for message | can be used for message authentication. | |||
authentication. | ||||
This approach uses the definition of Key Encapsulation Mechanism | This approach uses the definition of KEM algorithm functions in | |||
(KEM) algorithm functions in Section 1 of [RFC9629] as follows: | Section 1 of [RFC9629] as follows: | |||
A KEM algorithm provides three functions: | A KEM algorithm provides three functions: | |||
1. KeyGen() -> (pk, sk): Generate a public key (pk) and a private | 1. KeyGen() -> (pk, sk): Generate a public key (pk) and a private | |||
(secret) key (sk). | (secret) key (sk). | |||
2. Encapsulate(pk) -> (ct, ss): Given the public key (pk), produce a | 2. Encapsulate(pk) -> (ct, ss): Given the public key (pk), produce a | |||
ciphertext (ct) and a shared secret (ss). | ciphertext (ct) and a shared secret (ss). | |||
3. Decapsulate(sk, ct) -> (ss): Given the private key (sk) and the | 3. Decapsulate(sk, ct) -> (ss): Given the private key (sk) and the | |||
skipping to change at line 2008 ¶ | skipping to change at line 1995 ¶ | |||
Alice. | Alice. | |||
This shared secret key (ssk) can be reused by Alice for MAC-based | This shared secret key (ssk) can be reused by Alice for MAC-based | |||
protection of further messages sent to Bob within the current PKI | protection of further messages sent to Bob within the current PKI | |||
management operation. | management operation. | |||
This approach employs the notation of KDF(IKM, L, info) as described | This approach employs the notation of KDF(IKM, L, info) as described | |||
in Section 5 of [RFC9629] with the following changes: | in Section 5 of [RFC9629] with the following changes: | |||
* IKM is the input key material. It is the symmetric secret called | * IKM is the input key material. It is the symmetric secret called | |||
"ss" resulting from the key encapsulation mechanism. | "ss" resulting from the KEM. | |||
* L is dependent of the MAC algorithm that is used with the shared | * L is dependent of the MAC algorithm that is used with the shared | |||
secret key for CMP message protection and is called "len" in this | secret key for CMP message protection and is called "len" in this | |||
document. | document. | |||
* info is an additional input to the KDF, is called "context" in | * info is an additional input to the KDF, is called "context" in | |||
this document, and contains the DER-encoded KemOtherInfo structure | this document, and contains the DER-encoded KemOtherInfo structure | |||
defined as: | defined as: | |||
KemOtherInfo ::= SEQUENCE { | KemOtherInfo ::= SEQUENCE { | |||
skipping to change at line 2073 ¶ | skipping to change at line 2060 ¶ | |||
Additionally, multiple PKI messages MAY be aggregated. There are | Additionally, multiple PKI messages MAY be aggregated. There are | |||
several use cases for such messages. | several use cases for such messages. | |||
* The RA confirms having validated and authorized a message and | * The RA confirms having validated and authorized a message and | |||
forwards the original message unchanged. | forwards the original message unchanged. | |||
* A PKI management entity collects several messages that are to be | * A PKI management entity collects several messages that are to be | |||
forwarded in the same direction and forwards them in a batch. | forwarded in the same direction and forwards them in a batch. | |||
Request messages can be transferred as a batch upstream (towards | Request messages can be transferred as a batch upstream (towards | |||
the CA); response or announce messages can be transferred as a | the CA); response or announce messages can be transferred as a | |||
batch downstream (towards an RA but not to the EE). For instance, | batch downstream (towards an RA but not to the end entity). For | |||
this can be used when bridging an off-line connection between two | instance, this can be used when bridging an offline connection | |||
PKI management entities. | between two PKI management entities. | |||
These use cases are accomplished by nesting the messages within a new | These use cases are accomplished by nesting the messages within a new | |||
PKI message. The structure used is as follows: | PKI message. The structure used is as follows: | |||
NestedMessageContent ::= PKIMessages | NestedMessageContent ::= PKIMessages | |||
In case an RA needs to modify a request message, it MAY include the | In case an RA needs to modify a request message, it MAY include the | |||
original PKIMessage in the generalInfo field of the modified message, | original PKIMessage in the generalInfo field of the modified message, | |||
as described in Section 5.1.1.3. | as described in Section 5.1.1.3. | |||
5.2. Common Data Structures | 5.2. Common Data Structures | |||
Before specifying the specific types that may be placed in a PKIBody, | Before specifying the specific types that may be placed in a PKIBody, | |||
we define some data structures that are used in more than one case. | we define some data structures that are used in more than one case. | |||
5.2.1. Requested Certificate Contents | 5.2.1. Requested Certificate Contents | |||
Various PKI management messages require that the originator of the | Various PKI management messages require that the originator of the | |||
message indicate some of the fields that are required to be present | message indicate some of the fields that are required to be present | |||
in a certificate. The CertTemplate structure allows an end entity or | in a certificate. The CertTemplate structure allows entities | |||
RA to specify as much as it wishes about the certificate it requires. | requesting a certificate to specify the data fields that they want to | |||
CertTemplate is identical to a Certificate but with all fields | be included. Typically, they are required to provide at least the | |||
optional. | publicKey field. A CertTemplate structure is identical to a | |||
TBSCertificate structure (see [RFC5280]) but with all fields | ||||
optional/situational. | ||||
Note: Even if the originator completely specifies the contents of a | Note: Even if the originator completely specifies the contents of a | |||
certificate it requires, a CA is free to modify fields within the | certificate it requires, a CA is free to modify fields within the | |||
certificate actually issued. If the modified certificate is | certificate actually issued. If the modified certificate is | |||
unacceptable to the requester, the requester MUST send back a | unacceptable to the requester, the requester MUST send back a | |||
certConf message that either does not include this certificate (via a | certConf message that either does not include this certificate (via a | |||
CertHash) or does include this certificate (via a CertHash) along | CertHash) or does include this certificate (via a CertHash) along | |||
with a status of "rejected". See Section 5.3.18 for the definition | with a status of "rejected". See Section 5.3.18 for the definition | |||
and use of CertHash and the certConf message. | and use of CertHash and the certConf message. | |||
skipping to change at line 2160 ¶ | skipping to change at line 2149 ¶ | |||
The use of the EncryptedValue structure has been deprecated in favor | The use of the EncryptedValue structure has been deprecated in favor | |||
of the EnvelopedData structure. Therefore, it is RECOMMENDED to use | of the EnvelopedData structure. Therefore, it is RECOMMENDED to use | |||
EnvelopedData. | EnvelopedData. | |||
Note: The EncryptedKey structure defined in CRMF [RFC4211] is used | Note: The EncryptedKey structure defined in CRMF [RFC4211] is used | |||
here, which makes the update backward compatible. Using the new | here, which makes the update backward compatible. Using the new | |||
syntax with the untagged default choice EncryptedValue is bits-on- | syntax with the untagged default choice EncryptedValue is bits-on- | |||
the-wire compatible with the old syntax. | the-wire compatible with the old syntax. | |||
To indicate support for EnvelopedData, the pvno cmp2021 has been | To indicate support for EnvelopedData, the pvno cmp2021 has been | |||
introduced. Details on the usage of the protocol version number | introduced. Details on the usage of the protocol version number are | |||
(pvno) are described in Section 7. | described in Section 7. | |||
The EnvelopedData structure is RECOMMENDED to be used in CMP to | The EnvelopedData structure is RECOMMENDED to be used in CMP to | |||
transport a private key, certificate, POP challenge, or revocation | transport a private key, certificate, POP challenge, or revocation | |||
passphrase in encrypted form as follows: | passphrase in encrypted form as follows: | |||
* It contains only one RecipientInfo structure because the content | * It contains only one RecipientInfo structure because the content | |||
is encrypted only for one recipient. | is encrypted only for one recipient. | |||
* It may contain a private key in the AsymmetricKeyPackage structure | * It may contain a private key in the AsymmetricKeyPackage structure | |||
(which is placed in the encryptedContentInfo field), as defined in | (which is placed in the encryptedContentInfo field), as defined in | |||
[RFC5958], that is wrapped in a SignedData structure, as specified | [RFC5958], that is wrapped in a SignedData structure, as specified | |||
in Section 5 of [RFC5652] and [RFC8933], signed by the Key | in Section 5 of [RFC5652] and [RFC8933], signed by the KGA or CA. | |||
Generation Authority or CA. | ||||
* It may contain a certificate, POP challenge, or revocation | * It may contain a certificate, POP challenge, or revocation | |||
passphrase directly in the encryptedContent field. | passphrase directly in the encryptedContent field. | |||
The content of the EnvelopedData structure, as specified in Section 6 | The content of the EnvelopedData structure, as specified in Section 6 | |||
of [RFC5652], MUST be encrypted using a newly generated symmetric | of [RFC5652], MUST be encrypted using a newly generated symmetric | |||
content-encryption key. This content-encryption key MUST be securely | content-encryption key. This content-encryption key MUST be securely | |||
provided to the recipient using one of four key management | provided to the recipient using one of four key management | |||
techniques. | techniques. | |||
skipping to change at line 2205 ¶ | skipping to change at line 2193 ¶ | |||
key that supports key agreement and where any given key usage | key that supports key agreement and where any given key usage | |||
extension allows keyAgreement: The content-encryption key will be | extension allows keyAgreement: The content-encryption key will be | |||
protected using the key agreement key management technique, as | protected using the key agreement key management technique, as | |||
specified in Section 6.2.2 of [RFC5652]. | specified in Section 6.2.2 of [RFC5652]. | |||
* a password or shared secret: The content-encryption key will be | * a password or shared secret: The content-encryption key will be | |||
protected using the password-based key management technique, as | protected using the password-based key management technique, as | |||
specified in Section 6.2.4 of [RFC5652]. | specified in Section 6.2.4 of [RFC5652]. | |||
* recipient's certificate with an algorithm identifier and a public | * recipient's certificate with an algorithm identifier and a public | |||
key that supports key encapsulation mechanism and where any given | key that supports KEM and where any given key usage extension | |||
key usage extension allows keyEncipherment: The content-encryption | allows keyEncipherment: The content-encryption key will be | |||
key will be protected using the key management technique for KEM | protected using the key management technique for KEM keys, as | |||
keys, as specified in [RFC9629]. | specified in [RFC9629]. | |||
Note: There are cases where the algorithm identifier, the type of the | Note: There are cases where the algorithm identifier, the type of the | |||
public key, and the key usage extension will not be sufficient to | public key, and the key usage extension will not be sufficient to | |||
decide on the key management technique to use, e.g., when | decide on the key management technique to use, e.g., when | |||
rsaEncryption is the algorithm identifier. In such cases, it is a | rsaEncryption is the algorithm identifier. In such cases, it is a | |||
matter of local policy to decide. | matter of local policy to decide. | |||
5.2.3. Status Codes and Failure Information for PKI Messages | 5.2.3. Status Codes and Failure Information for PKI Messages | |||
All response messages will include some status information. The | All response messages will include some status information. The | |||
skipping to change at line 2336 ¶ | skipping to change at line 2324 ¶ | |||
See [RFC4211] for PKIArchiveOptions syntax. | See [RFC4211] for PKIArchiveOptions syntax. | |||
5.2.7. Publication Information | 5.2.7. Publication Information | |||
Requesters may indicate that they wish the PKI to publish a | Requesters may indicate that they wish the PKI to publish a | |||
certificate using the PKIPublicationInfo structure. | certificate using the PKIPublicationInfo structure. | |||
See [RFC4211] for PKIPublicationInfo syntax. | See [RFC4211] for PKIPublicationInfo syntax. | |||
5.2.8. Proof-of-Possession Structures | 5.2.8. POP Structures | |||
The proof-of-possession structure used is indicated in the popo field | The POP structure used is indicated in the popo field of type | |||
of type ProofOfPossession in the CertReqMsg sequence (see Section 4 | ProofOfPossession in the CertReqMsg sequence (see Section 4 of | |||
of [RFC4211]). | [RFC4211]). | |||
ProofOfPossession ::= CHOICE { | ProofOfPossession ::= CHOICE { | |||
raVerified [0] NULL, | raVerified [0] NULL, | |||
signature [1] POPOSigningKey, | signature [1] POPOSigningKey, | |||
keyEncipherment [2] POPOPrivKey, | keyEncipherment [2] POPOPrivKey, | |||
keyAgreement [3] POPOPrivKey | keyAgreement [3] POPOPrivKey | |||
} | } | |||
5.2.8.1. raVerified | 5.2.8.1. raVerified | |||
An EE MUST NOT use raVerified. If an RA performs changes to a | An end entity MUST NOT use raVerified. If an RA performs changes to | |||
certification request breaking the provided proof-of-possession | a certification request breaking the provided POP, or if the RA | |||
(POP), or if the RA requests a certificate on behalf of an EE and | requests a certificate on behalf of an end entity and cannot provide | |||
cannot provide the POP itself, the RA MUST use raVerified. | the POP itself, the RA MUST use raVerified. Otherwise, it SHOULD NOT | |||
Otherwise, it SHOULD NOT use raVerified. | use raVerified. | |||
When introducing raVerified, the RA MUST check the existing POP, or | When introducing raVerified, the RA MUST check the existing POP, or | |||
it MUST ensure by other means that the EE is the holder of the | it MUST ensure by other means that the end entity is the holder of | |||
private key. The RA MAY provide the original message containing the | the private key. The RA MAY provide the original message containing | |||
POP in the generalInfo field using the id-it-origPKIMessage (see | the POP in the generalInfo field using the id-it-origPKIMessage (see | |||
Section 5.1.1.3) enabling the CA to verify it. | Section 5.1.1.3) enabling the CA to verify it. | |||
5.2.8.2. POPOSigningKey Structure | 5.2.8.2. POPOSigningKey Structure | |||
If the certification request is for a key pair that supports signing | If the certification request is for a key pair that supports signing | |||
(i.e., a request for a verification certificate), then the proof-of- | (i.e., a request for a verification certificate), then the POP of the | |||
possession of the private key is demonstrated through use of the | private key is demonstrated through use of the POPOSigningKey | |||
POPOSigningKey structure; for details, see Section 4.1 of [RFC4211]. | structure; for details, see Section 4.1 of [RFC4211]. | |||
POPOSigningKey ::= SEQUENCE { | POPOSigningKey ::= SEQUENCE { | |||
poposkInput [0] POPOSigningKeyInput OPTIONAL, | poposkInput [0] POPOSigningKeyInput OPTIONAL, | |||
algorithmIdentifier AlgorithmIdentifier, | algorithmIdentifier AlgorithmIdentifier, | |||
signature BIT STRING | signature BIT STRING | |||
} | } | |||
POPOSigningKeyInput ::= SEQUENCE { | POPOSigningKeyInput ::= SEQUENCE { | |||
authInfo CHOICE { | authInfo CHOICE { | |||
sender [0] GeneralName, | sender [0] GeneralName, | |||
skipping to change at line 2404 ¶ | skipping to change at line 2392 ¶ | |||
and publicKey values, then poposkInput MUST be omitted and the | and publicKey values, then poposkInput MUST be omitted and the | |||
signature MUST be computed on the DER-encoded value of the certReq | signature MUST be computed on the DER-encoded value of the certReq | |||
field of the CertReqMsg (or the DER-encoded value of | field of the CertReqMsg (or the DER-encoded value of | |||
AltCertTemplate). If certTemplate/altCertTemplate does not contain | AltCertTemplate). If certTemplate/altCertTemplate does not contain | |||
both the subject and public key values (i.e., if it contains only one | both the subject and public key values (i.e., if it contains only one | |||
of these or neither), then poposkInput MUST be present and the | of these or neither), then poposkInput MUST be present and the | |||
signature MUST be computed on the DER-encoded value of poposkInput | signature MUST be computed on the DER-encoded value of poposkInput | |||
(i.e., the "value" OCTETs of the POPOSigningKeyInput DER). | (i.e., the "value" OCTETs of the POPOSigningKeyInput DER). | |||
In the special case that the CA/RA has a DH certificate that is known | In the special case that the CA/RA has a DH certificate that is known | |||
to the EE and the certification request is for a key agreement key | to the end entity and the certification request is for a key | |||
pair, the EE can also use the POPOSigningKey structure (where the | agreement key pair, the end entity can also use the POPOSigningKey | |||
algorithmIdentifier field is DHBasedMAC and the signature field is | structure (where the algorithmIdentifier field is DHBasedMAC and the | |||
the MAC) for demonstrating POP. | signature field is the MAC) for demonstrating POP. | |||
5.2.8.3. POPOPrivKey Structure | 5.2.8.3. POPOPrivKey Structure | |||
If the certification request is for a key pair that does not support | If the certification request is for a key pair that does not support | |||
signing (i.e., a request for an encryption or key agreement | signing (i.e., a request for an encryption or key agreement | |||
certificate), then the proof-of-possession of the private key is | certificate), then the POP of the private key is demonstrated through | |||
demonstrated through use of the POPOPrivKey structure in one of the | use of the POPOPrivKey structure in one of the following three ways; | |||
following three ways; for details see Sections 4.2 and 4.3 in | for details see Sections 4.2 and 4.3 in [RFC4211]. | |||
[RFC4211]. | ||||
POPOPrivKey ::= CHOICE { | POPOPrivKey ::= CHOICE { | |||
thisMessage [0] BIT STRING, -- deprecated | thisMessage [0] BIT STRING, -- deprecated | |||
subsequentMessage [1] SubsequentMessage, | subsequentMessage [1] SubsequentMessage, | |||
dhMAC [2] BIT STRING, -- deprecated | dhMAC [2] BIT STRING, -- deprecated | |||
agreeMAC [3] PKMACValue, | agreeMAC [3] PKMACValue, | |||
encryptedKey [4] EnvelopedData | encryptedKey [4] EnvelopedData | |||
} | } | |||
SubsequentMessage ::= INTEGER { | SubsequentMessage ::= INTEGER { | |||
encrCert (0), | encrCert (0), | |||
challengeResp (1) | challengeResp (1) | |||
} | } | |||
When using agreeMAC or encryptedKey choices, the pvno cmp2021(3) MUST | When using agreeMAC or encryptedKey choices, the pvno cmp2021(3) MUST | |||
be used. Details on the usage of the protocol version number (pvno) | be used. Details on the usage of the protocol version number are | |||
are described in Section 7. | described in Section 7. | |||
5.2.8.3.1. Inclusion of the Private Key | 5.2.8.3.1. Inclusion of the Private Key | |||
This method mentioned previously in Section 4.3 demonstrates proof- | This method mentioned previously in Section 4.3 demonstrates POP of | |||
of-possession of the private key by including the encrypted private | the private key by including the encrypted private key in the | |||
key in the CertRequest in the POPOPrivKey structure or in the | CertRequest in the POPOPrivKey structure or in the PKIArchiveOptions | |||
PKIArchiveOptions control structure. This method SHALL only be used | control structure. This method SHALL only be used if archival of the | |||
if archival of the private key is desired. | private key is desired. | |||
For a certification request message indicating cmp2021(3) in the pvno | For a certification request message indicating cmp2021(3) in the pvno | |||
field of the PKIHeader, the encrypted private key MUST be transferred | field of the PKIHeader, the encrypted private key MUST be transferred | |||
in the encryptedKey choice of POPOPrivKey (or within the | in the encryptedKey choice of POPOPrivKey (or within the | |||
PKIArchiveOptions control) in a CMS EnvelopedData structure, as | PKIArchiveOptions control) in a CMS EnvelopedData structure, as | |||
defined in Section 5.2.2. | defined in Section 5.2.2. | |||
Note: The thisMessage choice has been deprecated in favor of | Note: The thisMessage choice has been deprecated in favor of | |||
encryptedKey. When using cmp2000(2) in the certification request | encryptedKey. When using cmp2000(2) in the certification request | |||
message header for backward compatibility, the thisMessage choice of | message header for backward compatibility, the thisMessage choice of | |||
POPOPrivKey is used containing the encrypted private key in an | POPOPrivKey is used containing the encrypted private key in an | |||
EncryptedValue structure wrapped in a BIT STRING. This allows the | EncryptedValue structure wrapped in a BIT STRING. This allows the | |||
necessary conveyance and protection of the private key while | necessary conveyance and protection of the private key while | |||
maintaining bits-on-the-wire compatibility with [RFC4211]. | maintaining bits-on-the-wire compatibility with [RFC4211]. | |||
5.2.8.3.2. Indirect Method - Encrypted Certificate | 5.2.8.3.2. Indirect Method - Encrypted Certificate | |||
The indirect method mentioned previously in Section 4.3 demonstrates | The indirect method mentioned previously in Section 4.3 demonstrates | |||
proof-of-possession of the private key by having the CA return the | POP of the private key by having the CA return the requested | |||
requested certificate in encrypted form (see Section 5.2.2). This | certificate in encrypted form (see Section 5.2.2). This method is | |||
method is indicated in the CertRequest by requesting the encrCert | indicated in the CertRequest by requesting the encrCert option in the | |||
option in the subsequentMessage choice of POPOPrivKey. | subsequentMessage choice of POPOPrivKey. | |||
EE RA/CA | end entity RA/CA | |||
---- req ----> | ---- req ----> | |||
<--- rep (enc cert) ----- | <--- rep (enc cert) ----- | |||
---- conf (cert hash) ----> | ---- conf (cert hash) ----> | |||
<--- ack ----- | <--- ack ----- | |||
The end entity proves knowledge of the private key to the CA by | The end entity proves knowledge of the private key to the CA by | |||
providing the correct CertHash for this certificate in the certConf | providing the correct CertHash for this certificate in the certConf | |||
message. This demonstrates POP because the EE can only compute the | message. This demonstrates POP because the end entity can only | |||
correct CertHash if it is able to recover the encrypted certificate, | compute the correct CertHash if it is able to recover the encrypted | |||
and it can only recover the certificate if it is able to obtain the | certificate, and it can only recover the certificate if it is able to | |||
symmetric key using the required private key. Clearly, for this to | obtain the symmetric key using the required private key. Clearly, | |||
work, the CA MUST NOT publish the certificate until the certConf | for this to work, the CA MUST NOT publish the certificate until the | |||
message arrives (when certHash is to be used to demonstrate POP). | certConf message arrives (when certHash is to be used to demonstrate | |||
See Section 5.3.18 for further details, and see Section 8.11 for | POP). See Section 5.3.18 for further details, and see Section 8.11 | |||
security considerations regarding use of Certificate Transparency | for security considerations regarding use of CT logs. | |||
logs. | ||||
The recipient SHOULD maintain a context of the PKI management | The recipient SHOULD maintain a context of the PKI management | |||
operation, e.g., using transactionID and certReqId, to identify the | operation, e.g., using transactionID and certReqId, to identify the | |||
private key to use when decrypting the EnvelopedData containing the | private key to use when decrypting the EnvelopedData containing the | |||
newly issued certificate. The recipient may be unable to use the | newly issued certificate. The recipient may be unable to use the | |||
RecipientInfo structure as it refers to the certificate that is still | RecipientInfo structure as it refers to the certificate that is still | |||
encrypted. The sender MUST populate the rid field as specified by | encrypted. The sender MUST populate the rid field as specified by | |||
CMS, and the client MAY ignore it. | CMS, and the client MAY ignore it. | |||
5.2.8.3.3. Direct Method - Challenge-Response Protocol | 5.2.8.3.3. Direct Method - Challenge-Response Protocol | |||
The direct method mentioned previously in Section 4.3 demonstrates | The direct method mentioned previously in Section 4.3 demonstrates | |||
proof-of-possession of the private key by having the end entity | POP of the private key by having the end entity engage in a | |||
engage in a challenge-response protocol (using the messages popdecc | challenge-response protocol (using the messages popdecc of type | |||
of type POPODecKeyChall and popdecr of type POPODecKeyResp; see | POPODecKeyChall and popdecr of type POPODecKeyResp; see below) | |||
below) between CertReqMessages and CertRepMessage. This method is | between CertReqMessages and CertRepMessage. This method is indicated | |||
indicated in the CertRequest by requesting the challengeResp option | in the CertRequest by requesting the challengeResp option in the | |||
in the subsequentMessage choice of POPOPrivKey. | subsequentMessage choice of POPOPrivKey. | |||
Note: This method would typically be used in an environment in which | Note: This method would typically be used in an environment in which | |||
an RA verifies POP and then makes a certification request to the CA | an RA verifies POP and then makes a certification request to the CA | |||
on behalf of the end entity. In such a scenario, the CA trusts the | on behalf of the end entity. In such a scenario, the CA trusts the | |||
RA to have done POP correctly before the RA requests a certificate | RA to have done POP correctly before the RA requests a certificate | |||
for the end entity. | for the end entity. | |||
The complete protocol then looks as follows (note that req' does not | The complete protocol then looks as follows (note that req' does not | |||
necessarily encapsulate req as a nested message): | necessarily encapsulate req as a nested message): | |||
EE RA CA | end entity RA CA | |||
---- req ----> | ---- req ----> | |||
<--- chall --- | <--- chall --- | |||
---- resp ---> | ---- resp ---> | |||
---- req' ---> | ---- req' ---> | |||
<--- rep ----- | <--- rep ----- | |||
---- conf ---> | ---- conf ---> | |||
<--- ack ----- | <--- ack ----- | |||
<--- rep ----- | <--- rep ----- | |||
---- conf ---> | ---- conf ---> | |||
<--- ack ----- | <--- ack ----- | |||
This protocol is obviously much longer than the exchange given in | This protocol is obviously much longer than the exchange given in | |||
Section 5.2.8.3.2 above but allows a local Registration Authority to | Section 5.2.8.3.2 above but allows a Local Registration Authority | |||
be involved and has the property that the certificate itself is not | (LRA) to be involved and has the property that the certificate itself | |||
actually created until the proof-of-possession is complete. In some | is not actually created until the POP is complete. In some | |||
environments, a different order of the above messages may be | environments, a different order of the above messages may be | |||
required, such as the following (this may be determined by policy): | required, such as the following (this may be determined by policy): | |||
EE RA CA | end entity RA CA | |||
---- req ----> | ---- req ----> | |||
<--- chall --- | <--- chall --- | |||
---- resp ---> | ---- resp ---> | |||
---- req' ---> | ---- req' ---> | |||
<--- rep ----- | <--- rep ----- | |||
<--- rep ----- | <--- rep ----- | |||
---- conf ---> | ---- conf ---> | |||
---- conf ---> | ---- conf ---> | |||
<--- ack ----- | <--- ack ----- | |||
<--- ack ----- | <--- ack ----- | |||
The challenge-response messages for proof-of-possession of a private | The challenge-response messages for POP of a private key are | |||
key are specified as follows (for decryption keys, see [MvOV97], | specified as follows (for decryption keys, see [MvOV97], p.404 for | |||
p.404 for details). This challenge-response exchange is associated | details). This challenge-response exchange is associated with the | |||
with the preceding certification request message (and subsequent | preceding certification request message (and subsequent certification | |||
certification response and confirmation messages) by the | response and confirmation messages) by the transactionID used in the | |||
transactionID used in the PKIHeader and by the protection applied to | PKIHeader and by the protection applied to the PKIMessage. | |||
the PKIMessage. | ||||
POPODecKeyChallContent ::= SEQUENCE OF Challenge | POPODecKeyChallContent ::= SEQUENCE OF Challenge | |||
Challenge ::= SEQUENCE { | Challenge ::= SEQUENCE { | |||
owf AlgorithmIdentifier OPTIONAL, | owf AlgorithmIdentifier OPTIONAL, | |||
witness OCTET STRING, | witness OCTET STRING, | |||
challenge OCTET STRING, -- deprecated | challenge OCTET STRING, -- deprecated | |||
encryptedRand [0] EnvelopedData OPTIONAL | encryptedRand [0] EnvelopedData OPTIONAL | |||
} | } | |||
skipping to change at line 2624 ¶ | skipping to change at line 2609 ¶ | |||
EKPOPEncryptedCert; | EKPOPEncryptedCert; | |||
KAKPOPEncryptedCert; | KAKPOPEncryptedCert; | |||
KEMKPOPEncryptedCert; | KEMKPOPEncryptedCert; | |||
EKPOPChallengeResp; | EKPOPChallengeResp; | |||
KAKPOPChallengeResp; and | KAKPOPChallengeResp; and | |||
KEMKPOPChallengeResp. | KEMKPOPChallengeResp. | |||
Given this array of options, it is natural to ask how an end entity | Given this array of options, it is natural to ask how an end entity | |||
can know what is supported by the CA/RA (i.e., which options it may | can know what is supported by the CA/RA (i.e., which options it may | |||
use when requesting certificates). The following guidelines should | use when requesting certificates). The following guidelines should | |||
clarify this situation for EE implementers. | clarify this situation for end entity implementers. | |||
* RAVerified: This is not an EE decision; the RA uses this if and | * RAVerified: This is not an end entity decision; the RA uses this | |||
only if it has verified POP before forwarding the request on to | if and only if it has verified POP before forwarding the request | |||
the CA, so it is not possible for the EE to choose this technique. | on to the CA, so it is not possible for the end entity to choose | |||
this technique. | ||||
* SKPOP: If the EE has a signing key pair, this is the only POP | * SKPOP: If the end entity has a signing key pair, this is the only | |||
method specified for use in the request for a corresponding | POP method specified for use in the request for a corresponding | |||
certificate. | certificate. | |||
* EKPOPThisMessage (deprecated), KAKPOPThisMessage (deprecated), | * EKPOPThisMessage (deprecated), KAKPOPThisMessage (deprecated), | |||
EKPOPEncryptedKey, KAKPOPEncryptedKey, KEMKPOPEncryptedKey: | EKPOPEncryptedKey, KAKPOPEncryptedKey, KEMKPOPEncryptedKey: | |||
Whether or not to give up its private key to the CA/RA is an EE | Whether or not to give up its private key to the CA/RA is an end | |||
decision. If the EE decides to reveal its key, then these are the | entity decision. If the end entity decides to reveal its key, | |||
only POP methods available in this specification to achieve this | then these are the only POP methods available in this | |||
(and the key pair type and protocol version used will determine | specification to achieve this (and the key pair type and protocol | |||
which of these methods to use). The reason for deprecating | version used will determine which of these methods to use). The | |||
EKPOPThisMessage and KAKPOPThisMessage options has been given in | reason for deprecating EKPOPThisMessage and KAKPOPThisMessage | |||
Section 5.2.8.3.1. | options has been given in Section 5.2.8.3.1. | |||
* KAKPOPThisMessageDHMAC: The EE can only use this method if (1) the | * KAKPOPThisMessageDHMAC: The end entity can only use this method if | |||
CA/RA has a DH certificate available for this purpose and (2) the | (1) the CA/RA has a DH certificate available for this purpose and | |||
EE already has a copy of this certificate. If both these | (2) the end entity already has a copy of this certificate. If | |||
conditions hold, then this technique is clearly supported and may | both these conditions hold, then this technique is clearly | |||
be used by the EE, if desired. | supported and may be used by the end entity, if desired. | |||
* EKPOPEncryptedCert, KAKPOPEncryptedCert, KEMKPOPEncryptedCert, | * EKPOPEncryptedCert, KAKPOPEncryptedCert, KEMKPOPEncryptedCert, | |||
EKPOPChallengeResp, KAKPOPChallengeResp, and KEMKPOPChallengeResp: | EKPOPChallengeResp, KAKPOPChallengeResp, and KEMKPOPChallengeResp: | |||
The EE picks one of these (in the subsequentMessage field) in the | The end entity picks one of these (in the subsequentMessage field) | |||
request message, depending upon preference and key pair type. The | in the request message, depending upon preference and key pair | |||
EE is not doing POP at this point; it is simply indicating which | type. The end entity is not doing POP at this point; it is simply | |||
method it wants to use. Therefore, if the CA/RA replies with a | indicating which method it wants to use. Therefore, if the CA/RA | |||
"badPOP" error, the EE can re-request using the other POP method | replies with a "badPOP" error, the end entity can re-request using | |||
chosen in subsequentMessage. Note, however, that this | the other POP method chosen in subsequentMessage. Note, however, | |||
specification encourages the use of the EncryptedCert choice and, | that this specification encourages the use of the EncryptedCert | |||
furthermore, says that the challenge-response would typically be | choice and, furthermore, says that the challenge-response would | |||
used when an RA is involved and doing POP verification. Thus, the | typically be used when an RA is involved and doing POP | |||
EE should be able to make an intelligent decision regarding which | verification. Thus, the end entity should be able to make an | |||
of these POP methods to choose in the request message. | intelligent decision regarding which of these POP methods to | |||
choose in the request message. | ||||
5.2.9. GeneralizedTime | 5.2.9. GeneralizedTime | |||
GeneralizedTime is a standard ASN.1 type and SHALL be used as | GeneralizedTime is a standard ASN.1 type and SHALL be used as | |||
specified in Section 4.1.2.5.2 of [RFC5280]. | specified in Section 4.1.2.5.2 of [RFC5280]. | |||
5.3. Operation-Specific Data Structures | 5.3. Operation-Specific Data Structures | |||
5.3.1. Initialization Request | 5.3.1. Initialization Request | |||
skipping to change at line 2770 ¶ | skipping to change at line 2757 ¶ | |||
Given an EncryptedCert and the relevant decryption key, the | Given an EncryptedCert and the relevant decryption key, the | |||
certificate may be obtained. The purpose of this is to allow a CA to | certificate may be obtained. The purpose of this is to allow a CA to | |||
return the value of a certificate but with the constraint that only | return the value of a certificate but with the constraint that only | |||
the intended recipient can obtain the actual certificate. The | the intended recipient can obtain the actual certificate. The | |||
benefit of this approach is that a CA may reply with a certificate | benefit of this approach is that a CA may reply with a certificate | |||
even in the absence of proof that the requester is the end entity | even in the absence of proof that the requester is the end entity | |||
that can use the relevant private key (note that the proof is not | that can use the relevant private key (note that the proof is not | |||
obtained until the certConf message is received by the CA). Thus, | obtained until the certConf message is received by the CA). Thus, | |||
the CA will not have to revoke that certificate in the event that | the CA will not have to revoke that certificate in the event that | |||
something goes wrong with the proof-of-possession (but MAY do so | something goes wrong with the POP (but MAY do so anyway, depending | |||
anyway, depending upon policy). | upon policy). | |||
The use of EncryptedKey is described in Section 5.2.2. | The use of EncryptedKey is described in Section 5.2.2. | |||
Note: To indicate support for EnvelopedData, the pvno cmp2021 has | Note: To indicate support for EnvelopedData, the pvno cmp2021 has | |||
been introduced. Details on the usage of different protocol version | been introduced. Details on the usage of different protocol version | |||
numbers (pvnos) are described in Section 7. | numbers are described in Section 7. | |||
5.3.5. Key Update Request Content | 5.3.5. Key Update Request Content | |||
For key update requests, the CertReqMessages syntax is used. | For key update requests, the CertReqMessages syntax is used. | |||
Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template | Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template | |||
fields that may be supplied for each key to be updated (see the | fields that may be supplied for each key to be updated (see the | |||
profiles defined in Section 4.1.3 of [RFC9483] and Appendix C.6 for | profiles defined in Section 4.1.3 of [RFC9483] and Appendix C.6 for | |||
further information). This message is intended to be used to request | further information). This message is intended to be used to request | |||
updates to existing (non-revoked and non-expired) certificates | updates to existing (non-revoked and non-expired) certificates | |||
(therefore, it is sometimes referred to as a "Certificate Update" | (therefore, it is sometimes referred to as a "Certificate Update" | |||
skipping to change at line 2811 ¶ | skipping to change at line 2798 ¶ | |||
5.3.7. Key Recovery Request Content | 5.3.7. Key Recovery Request Content | |||
For key recovery requests, the syntax used is identical to the | For key recovery requests, the syntax used is identical to the | |||
initialization request CertReqMessages. Typically, | initialization request CertReqMessages. Typically, | |||
SubjectPublicKeyInfo and KeyId are the template fields that may be | SubjectPublicKeyInfo and KeyId are the template fields that may be | |||
used to supply a signature public key for which a certificate is | used to supply a signature public key for which a certificate is | |||
required. | required. | |||
See Section 5.2.1 and [RFC4211] for CertReqMessages syntax. Note | See Section 5.2.1 and [RFC4211] for CertReqMessages syntax. Note | |||
that if a key history is required, the requester must supply a | that if a key history is required, the requester must supply a | |||
Protocol Encryption Key control in the request message. | protocol encryption key control in the request message. | |||
5.3.8. Key Recovery Response Content | 5.3.8. Key Recovery Response Content | |||
For key recovery responses, the following syntax is used. For some | For key recovery responses, the following syntax is used. For some | |||
status values (e.g., waiting), none of the optional fields will be | status values (e.g., waiting), none of the optional fields will be | |||
present. | present. | |||
KeyRecRepContent ::= SEQUENCE { | KeyRecRepContent ::= SEQUENCE { | |||
status PKIStatusInfo, | status PKIStatusInfo, | |||
newSigCert [0] Certificate OPTIONAL, | newSigCert [0] Certificate OPTIONAL, | |||
skipping to change at line 2893 ¶ | skipping to change at line 2880 ¶ | |||
oldWithNew [1] CMPCertificate OPTIONAL | oldWithNew [1] CMPCertificate OPTIONAL | |||
} | } | |||
CAKeyUpdContent ::= CHOICE { | CAKeyUpdContent ::= CHOICE { | |||
cAKeyUpdAnnV2 CAKeyUpdAnnContent, -- deprecated | cAKeyUpdAnnV2 CAKeyUpdAnnContent, -- deprecated | |||
cAKeyUpdAnnV3 [0] RootCaKeyUpdateContent | cAKeyUpdAnnV3 [0] RootCaKeyUpdateContent | |||
} | } | |||
When using RootCaKeyUpdateContent in the ckuann message, the pvno | When using RootCaKeyUpdateContent in the ckuann message, the pvno | |||
cmp2021 MUST be used. Details on the usage of the protocol version | cmp2021 MUST be used. Details on the usage of the protocol version | |||
number (pvno) are described in Section 7. | number are described in Section 7. | |||
In contrast to CAKeyUpdAnnContent as supported with cmp2000, | In contrast to CAKeyUpdAnnContent as supported with cmp2000, | |||
RootCaKeyUpdateContent offers omitting newWithOld and oldWithNew, | RootCaKeyUpdateContent offers omitting newWithOld and oldWithNew, | |||
depending on the needs of the EE. | depending on the needs of the end entity. | |||
5.3.14. Certificate Announcement | 5.3.14. Certificate Announcement | |||
This structure MAY be used to announce the existence of certificates. | This structure MAY be used to announce the existence of certificates. | |||
Note that this message is intended to be used for those cases (if | Note that this message is intended to be used for those cases (if | |||
any) where there is no pre-existing method for publication of | any) where there is no pre-existing method for publication of | |||
certificates; it is not intended to be used where, for example, X.500 | certificates; it is not intended to be used where, for example, X.500 | |||
is the method for publication of certificates. | is the method for publication of certificates. | |||
skipping to change at line 2949 ¶ | skipping to change at line 2936 ¶ | |||
5.3.17. PKI Confirmation Content | 5.3.17. PKI Confirmation Content | |||
This data structure is used in the protocol exchange as the final | This data structure is used in the protocol exchange as the final | |||
PKIMessage. Its content is the same in all cases -- actually, there | PKIMessage. Its content is the same in all cases -- actually, there | |||
is no content since the PKIHeader carries all the required | is no content since the PKIHeader carries all the required | |||
information. | information. | |||
PKIConfirmContent ::= NULL | PKIConfirmContent ::= NULL | |||
Use of this message for certificate confirmation is NOT RECOMMENDED; | Use of this message for certificate confirmation is NOT RECOMMENDED; | |||
certConf SHOULD be used instead. Upon receiving a PKIConfirm for a | certConf SHOULD be used instead. Upon receiving a pkiconf for a | |||
certificate response, the recipient MAY treat it as a certConf with | certificate response, the recipient MAY treat it as a certConf with | |||
all certificates being accepted. | all certificates being accepted. | |||
5.3.18. Certificate Confirmation Content | 5.3.18. Certificate Confirmation Content | |||
This data structure is used by the client to send a confirmation to | This data structure is used by the client to send a confirmation to | |||
the CA/RA to accept or reject certificates. | the CA/RA to accept or reject certificates. | |||
CertConfirmContent ::= SEQUENCE OF CertStatus | CertConfirmContent ::= SEQUENCE OF CertStatus | |||
skipping to change at line 2991 ¶ | skipping to change at line 2978 ¶ | |||
indicates acceptance of the specified certificate. Alternatively, | indicates acceptance of the specified certificate. Alternatively, | |||
explicit status details (with respect to acceptance or rejection) MAY | explicit status details (with respect to acceptance or rejection) MAY | |||
be provided in the statusInfo field, perhaps for auditing purposes at | be provided in the statusInfo field, perhaps for auditing purposes at | |||
the CA/RA. | the CA/RA. | |||
Within CertConfirmContent, omission of a CertStatus structure | Within CertConfirmContent, omission of a CertStatus structure | |||
corresponding to a certificate supplied in the previous response | corresponding to a certificate supplied in the previous response | |||
message indicates rejection of the certificate. Thus, an empty | message indicates rejection of the certificate. Thus, an empty | |||
CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate | CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate | |||
rejection of all supplied certificates. See Section 5.2.8.3.2 for a | rejection of all supplied certificates. See Section 5.2.8.3.2 for a | |||
discussion of the certHash field with respect to proof-of-possession. | discussion of the certHash field with respect to POP. | |||
5.3.19. PKI General Message Content | 5.3.19. PKI General Message Content | |||
InfoTypeAndValue ::= SEQUENCE { | InfoTypeAndValue ::= SEQUENCE { | |||
infoType OBJECT IDENTIFIER, | infoType OBJECT IDENTIFIER, | |||
infoValue ANY DEFINED BY infoType OPTIONAL | infoValue ANY DEFINED BY infoType OPTIONAL | |||
} | } | |||
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} | -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} | |||
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue | GenMsgContent ::= SEQUENCE OF InfoTypeAndValue | |||
5.3.19.1. CA Protocol Encryption Certificate | 5.3.19.1. CA Protocol Encryption Certificate | |||
This MAY be used by the EE to get a certificate from the CA to use to | This MAY be used by the end entity to get a certificate from the CA | |||
protect sensitive information during the protocol. | to use to protect sensitive information during the protocol. | |||
GenMsg: {id-it 1}, < absent > | GenMsg: {id-it 1}, < absent > | |||
GenRep: {id-it 1}, Certificate | < absent > | GenRep: {id-it 1}, Certificate | < absent > | |||
EEs MUST ensure that the correct certificate is used for this | End entities MUST ensure that the correct certificate is used for | |||
purpose. | this purpose. | |||
5.3.19.2. Signing Key Pair Types | 5.3.19.2. Signing Key Pair Types | |||
This MAY be used by the EE to get the list of signature algorithms | This MAY be used by the end entity to get the list of signature | |||
whose subject public key values the CA is willing to certify. | algorithms whose subject public key values the CA is willing to | |||
certify. | ||||
GenMsg: {id-it 2}, < absent > | GenMsg: {id-it 2}, < absent > | |||
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF | GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF | |||
AlgorithmIdentifier | AlgorithmIdentifier | |||
Note: For the purposes of this exchange, rsaEncryption and | Note: For the purposes of this exchange, rsaEncryption and | |||
sha256WithRSAEncryption, for example, are considered to be | sha256WithRSAEncryption, for example, are considered to be | |||
equivalent; the question being asked is, "Is the CA willing to | equivalent; the question being asked is, "Is the CA willing to | |||
certify an RSA public key?" | certify an RSA public key?" | |||
skipping to change at line 3050 ¶ | skipping to change at line 3038 ¶ | |||
AlgorithmIdentifier | AlgorithmIdentifier | |||
Note: In case several elliptic curves are supported, several id- | Note: In case several elliptic curves are supported, several id- | |||
ecPublicKey elements as defined in [RFC5480] need to be given, one | ecPublicKey elements as defined in [RFC5480] need to be given, one | |||
per named curve. | per named curve. | |||
5.3.19.4. Preferred Symmetric Algorithm | 5.3.19.4. Preferred Symmetric Algorithm | |||
This MAY be used by the client to get the CA-preferred symmetric | This MAY be used by the client to get the CA-preferred symmetric | |||
encryption algorithm for any confidential information that needs to | encryption algorithm for any confidential information that needs to | |||
be exchanged between the EE and the CA (for example, if the EE wants | be exchanged between the end entity and the CA (for example, if the | |||
to send its private decryption key to the CA for archival purposes). | end entity wants to send its private decryption key to the CA for | |||
archival purposes). | ||||
GenMsg: {id-it 4}, < absent > | GenMsg: {id-it 4}, < absent > | |||
GenRep: {id-it 4}, AlgorithmIdentifier | GenRep: {id-it 4}, AlgorithmIdentifier | |||
5.3.19.5. Updated CA Key Pair | 5.3.19.5. Updated CA Key Pair | |||
This MAY be used by the CA to announce a CA key update event. | This MAY be used by the CA to announce a CA key update event. | |||
GenMsg: {id-it 18}, RootCaKeyUpdateValue | GenMsg: {id-it 18}, RootCaKeyUpdateValue | |||
skipping to change at line 3081 ¶ | skipping to change at line 3070 ¶ | |||
5.3.19.7. Unsupported Object Identifiers | 5.3.19.7. Unsupported Object Identifiers | |||
This is used by the server to return a list of object identifiers | This is used by the server to return a list of object identifiers | |||
that it does not recognize or support from the list submitted by the | that it does not recognize or support from the list submitted by the | |||
client. | client. | |||
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER | GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER | |||
5.3.19.8. Key Pair Parameters | 5.3.19.8. Key Pair Parameters | |||
This MAY be used by the EE to request the domain parameters to use | This MAY be used by the end entity to request the domain parameters | |||
for generating the key pair for certain public-key algorithms. It | to use for generating the key pair for certain public-key algorithms. | |||
can be used, for example, to request the appropriate P, Q, and G to | It can be used, for example, to request the appropriate P, Q, and G | |||
generate the DH/DSA key or to request a set of well-known elliptic | to generate the DH/DSA key or to request a set of well-known elliptic | |||
curves. | curves. | |||
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id) | GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id) | |||
GenRep: {id-it 11}, AlgorithmIdentifier | < absent > | GenRep: {id-it 11}, AlgorithmIdentifier | < absent > | |||
An absent infoValue in the GenRep indicates that the algorithm | An absent infoValue in the GenRep indicates that the algorithm | |||
specified in GenMsg is not supported. | specified in GenMsg is not supported. | |||
EEs MUST ensure that the parameters are acceptable to it and that the | End entities MUST ensure that the parameters are acceptable to it and | |||
GenRep message is authenticated (to avoid substitution attacks). | that the GenRep message is authenticated (to avoid substitution | |||
attacks). | ||||
5.3.19.9. Revocation Passphrase | 5.3.19.9. Revocation Passphrase | |||
This MAY be used by the EE to send a passphrase to a CA/RA for the | This MAY be used by the end entity to send a passphrase to a CA/RA | |||
purpose of authenticating a later revocation request (in the case | for the purpose of authenticating a later revocation request (in the | |||
that the appropriate signing private key is no longer available to | case that the appropriate signing private key is no longer available | |||
authenticate the request). See Appendix B for further details on the | to authenticate the request). See Appendix B for further details on | |||
use of this mechanism. | the use of this mechanism. | |||
GenMsg: {id-it 12}, EncryptedKey | GenMsg: {id-it 12}, EncryptedKey | |||
GenRep: {id-it 12}, < absent > | GenRep: {id-it 12}, < absent > | |||
The use of EncryptedKey is described in Section 5.2.2. | The use of EncryptedKey is described in Section 5.2.2. | |||
5.3.19.10. ImplicitConfirm | 5.3.19.10. ImplicitConfirm | |||
See Section 5.1.1.1 for the definition and use of {id-it 13}. | See Section 5.1.1.1 for the definition and use of {id-it 13}. | |||
skipping to change at line 3148 ¶ | skipping to change at line 3138 ¶ | |||
GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF | GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF | |||
CMPCertificate | < absent > | CMPCertificate | < absent > | |||
5.3.19.15. Root CA Update | 5.3.19.15. Root CA Update | |||
This MAY be used by the client to get an update of a root CA | This MAY be used by the client to get an update of a root CA | |||
certificate, which is provided in the body of the request message. | certificate, which is provided in the body of the request message. | |||
In contrast to the ckuann message, this approach follows the request/ | In contrast to the ckuann message, this approach follows the request/ | |||
response model. | response model. | |||
The EE SHOULD reference its current trust anchor in RootCaCertValue | The end entity SHOULD reference its current trust anchor in | |||
in the request body, giving the root CA certificate if available. | RootCaCertValue in the request body, giving the root CA certificate | |||
if available. | ||||
GenMsg: {id-it 20}, RootCaCertValue | < absent > | GenMsg: {id-it 20}, RootCaCertValue | < absent > | |||
GenRep: {id-it 18}, RootCaKeyUpdateValue | < absent > | GenRep: {id-it 18}, RootCaKeyUpdateValue | < absent > | |||
RootCaCertValue ::= CMPCertificate | RootCaCertValue ::= CMPCertificate | |||
RootCaKeyUpdateValue ::= RootCaKeyUpdateContent | RootCaKeyUpdateValue ::= RootCaKeyUpdateContent | |||
RootCaKeyUpdateContent ::= SEQUENCE { | RootCaKeyUpdateContent ::= SEQUENCE { | |||
newWithNew CMPCertificate, | newWithNew CMPCertificate, | |||
newWithOld [0] CMPCertificate OPTIONAL, | newWithOld [0] CMPCertificate OPTIONAL, | |||
oldWithNew [1] CMPCertificate OPTIONAL | oldWithNew [1] CMPCertificate OPTIONAL | |||
} | } | |||
Note: In contrast to CAKeyUpdAnnContent (which was deprecated with | Note: In contrast to CAKeyUpdAnnContent (which was deprecated with | |||
pvno cmp2021), RootCaKeyUpdateContent offers omitting newWithOld and | pvno cmp2021), RootCaKeyUpdateContent offers omitting newWithOld and | |||
oldWithNew, depending on the needs of the EE. | oldWithNew, depending on the needs of the end entity. | |||
5.3.19.16. Certificate Request Template | 5.3.19.16. Certificate Request Template | |||
This MAY be used by the client to get a template containing | This MAY be used by the client to get a template containing | |||
requirements for certificate request attributes and extensions. The | requirements for certificate request attributes and extensions. The | |||
controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain | controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain | |||
details on the types of subject public keys the CA is willing to | details on the types of subject public keys the CA is willing to | |||
certify. | certify. | |||
The id-regCtrl-algId control MAY be used to identify a cryptographic | The id-regCtrl-algId control MAY be used to identify a cryptographic | |||
skipping to change at line 3285 ¶ | skipping to change at line 3276 ¶ | |||
5.3.20. PKI General Response Content | 5.3.20. PKI General Response Content | |||
GenRepContent ::= SEQUENCE OF InfoTypeAndValue | GenRepContent ::= SEQUENCE OF InfoTypeAndValue | |||
Examples of GenReps that MAY be supported include those listed in the | Examples of GenReps that MAY be supported include those listed in the | |||
subsections of Section 5.3.19. | subsections of Section 5.3.19. | |||
5.3.21. Error Message Content | 5.3.21. Error Message Content | |||
This data structure MAY be used by an EE, CA, or RA to convey error | This data structure MAY be used by an end entity, CA, or RA to convey | |||
information and by a PKI management entity to initiate delayed | error information and by a PKI management entity to initiate delayed | |||
delivery of responses. | delivery of responses. | |||
ErrorMsgContent ::= SEQUENCE { | ErrorMsgContent ::= SEQUENCE { | |||
pKIStatusInfo PKIStatusInfo, | pKIStatusInfo PKIStatusInfo, | |||
errorCode INTEGER OPTIONAL, | errorCode INTEGER OPTIONAL, | |||
errorDetails PKIFreeText OPTIONAL | errorDetails PKIFreeText OPTIONAL | |||
} | } | |||
This message MAY be generated at any time during a PKI transaction. | This message MAY be generated at any time during a PKI transaction. | |||
If the client sends this request, the server MUST respond with a | If the client sends this request, the server MUST respond with a | |||
PKIConfirm response or another ErrorMsg if any part of the header is | pkiconf response or another error message if any part of the header | |||
not valid. | is not valid. | |||
In case a PKI management entity sends an error message to the EE with | In case a PKI management entity sends an error message to the end | |||
the pKIStatusInfo field containing the status "waiting", the EE | entity with the pKIStatusInfo field containing the status "waiting", | |||
SHOULD initiate polling as described in Section 5.3.22. If the EE | the end entity SHOULD initiate polling as described in | |||
does not initiate polling, both sides MUST treat this message as the | Section 5.3.22. If the end entity does not initiate polling, both | |||
end of the transaction (if a transaction is in progress). | sides MUST treat this message as the end of the transaction (if a | |||
transaction is in progress). | ||||
If protection is desired on the message, the client MUST protect it | If protection is desired on the message, the client MUST protect it | |||
using the same technique (i.e., signature or MAC) as the starting | using the same technique (i.e., signature or MAC) as the starting | |||
message of the transaction. The CA MUST always sign it with a | message of the transaction. The CA MUST always sign it with a | |||
signature key. | signature key. | |||
5.3.22. Polling Request and Response | 5.3.22. Polling Request and Response | |||
This pair of messages is intended to handle scenarios in which the | This pair of messages is intended to handle scenarios in which the | |||
client needs to poll the server to determine the status of an | client needs to poll the server to determine the status of an | |||
skipping to change at line 3337 ¶ | skipping to change at line 3329 ¶ | |||
response to an ir, cr, p10cr, kur, krr, or ccr request message, | response to an ir, cr, p10cr, kur, krr, or ccr request message, | |||
polling is initiated with an ip, cp, kup, krp, or ccp response | polling is initiated with an ip, cp, kup, krp, or ccp response | |||
message containing status "waiting". For any type of request | message containing status "waiting". For any type of request | |||
message, polling can be initiated with an error response message with | message, polling can be initiated with an error response message with | |||
status "waiting". The following clauses describe how polling | status "waiting". The following clauses describe how polling | |||
messages are used. It is assumed that multiple certConf messages can | messages are used. It is assumed that multiple certConf messages can | |||
be sent during transactions. There will be one sent in response to | be sent during transactions. There will be one sent in response to | |||
each ip, cp, kup, krp, or ccp that contains a CertStatus for an | each ip, cp, kup, krp, or ccp that contains a CertStatus for an | |||
issued certificate. | issued certificate. | |||
1. In response to an ip, cp, kup, krp, or ccp message, an EE will | 1. In response to an ip, cp, kup, krp, or ccp message, an end entity | |||
send a certConf for all issued certificates and expect a PKIconf | will send a certConf for all issued certificates and expect a | |||
for each certConf. An EE will send a pollReq message in response | pkiconf for each certConf. An end entity will send a pollReq | |||
to each CertResponse element of an ip, cp, or kup message with | message in response to each CertResponse element of an ip, cp, or | |||
status "waiting" and in response to an error message with status | kup message with status "waiting" and in response to an error | |||
"waiting". Its certReqId MUST be either the index of a | message with status "waiting". Its certReqId MUST be either the | |||
CertResponse data structure with status "waiting" or -1 referring | index of a CertResponse data structure with status "waiting" or | |||
to the complete response. | -1 referring to the complete response. | |||
2. In response to a pollReq, a CA/RA will return an ip, cp, kup, | 2. In response to a pollReq, a CA/RA will return an ip, cp, kup, | |||
krp, or ccp if one or more of the still pending requested | krp, or ccp if one or more of the still pending requested | |||
certificates are ready or the final response to some other type | certificates are ready or the final response to some other type | |||
of request is available; otherwise, it will return a pollRep. | of request is available; otherwise, it will return a pollRep. | |||
3. If the EE receives a pollRep, it will wait for at least the | 3. If the end entity receives a pollRep, it will wait for at least | |||
number of seconds given in the checkAfter field before sending | the number of seconds given in the checkAfter field before | |||
another pollReq. | sending another pollReq. | |||
Note that the checkAfter value heavily depends on the certificate | Note that the checkAfter value heavily depends on the certificate | |||
management environment. There are different possible reasons for | management environment. There are different possible reasons for | |||
a delayed delivery of response messages, e.g., high load on the | a delayed delivery of response messages, e.g., high load on the | |||
server's backend, offline transfer of messages between two PKI | server's backend, offline transfer of messages between two PKI | |||
management entities, or required RA operator approval. | management entities, or required RA operator approval. | |||
Therefore, the checkAfter time can vary greatly. This should | Therefore, the checkAfter time can vary greatly. This should | |||
also be considered by the transfer protocol. | also be considered by the transfer protocol. | |||
4. If the EE receives an ip, cp, kup, krp, or ccp, then it will be | 4. If the end entity receives an ip, cp, kup, krp, or ccp, then it | |||
treated in the same way as the initial response; if it receives | will be treated in the same way as the initial response; if it | |||
any other response, then this will be treated as the final | receives any other response, then this will be treated as the | |||
response to the original request. | final response to the original request. | |||
The following client-side state machine describes polling for | The following client-side state machine describes polling for | |||
individual CertResponse elements at the example of an ir request | individual CertResponse elements at the example of an ir request | |||
message. | message. | |||
START | START | |||
| | | | |||
v | v | |||
Send ir | Send ir | |||
| ip | | ip | |||
skipping to change at line 3402 ¶ | skipping to change at line 3394 ¶ | |||
(empty pending list) V V | pollRep | (empty pending list) V V | pollRep | |||
END <---- Send certConf Send pollReq---------->Wait | END <---- Send certConf Send pollReq---------->Wait | |||
| ^ ^ | | | ^ ^ | | |||
| | | | | | | | | | |||
+-----------------+ +---------------+ | +-----------------+ +---------------+ | |||
(pending list) | (pending list) | |||
In the following exchange, the end entity is enrolling for two | In the following exchange, the end entity is enrolling for two | |||
certificates in one request. | certificates in one request. | |||
Step# End Entity PKI | Step# End entity PKI | |||
--------------------------------------------------------------------- | --------------------------------------------------------------------- | |||
1 format ir | 1 format ir | |||
2 --> ir --> | 2 --> ir --> | |||
3 handle ir | 3 handle ir | |||
4 manual intervention is | 4 manual intervention is | |||
required for both certs | required for both certs | |||
5 <-- ip <-- | 5 <-- ip <-- | |||
6 process ip | 6 process ip | |||
7 format pollReq | 7 format pollReq | |||
8 --> pollReq --> | 8 --> pollReq --> | |||
skipping to change at line 3429 ¶ | skipping to change at line 3421 ¶ | |||
14 --> pollReq --> | 14 --> pollReq --> | |||
15 check status of cert requests, | 15 check status of cert requests, | |||
one certificate is ready | one certificate is ready | |||
16 format ip | 16 format ip | |||
17 <-- ip <-- | 17 <-- ip <-- | |||
18 handle ip | 18 handle ip | |||
19 format certConf | 19 format certConf | |||
20 --> certConf --> | 20 --> certConf --> | |||
21 handle certConf | 21 handle certConf | |||
22 format ack | 22 format ack | |||
23 <-- pkiConf <-- | 23 <-- pkiconf <-- | |||
24 format pollReq | 24 format pollReq | |||
25 --> pollReq --> | 25 --> pollReq --> | |||
26 check status of certificate, | 26 check status of certificate, | |||
certificate is ready | certificate is ready | |||
27 format ip | 27 format ip | |||
28 <-- ip <-- | 28 <-- ip <-- | |||
29 handle ip | 29 handle ip | |||
30 format certConf | 30 format certConf | |||
31 --> certConf --> | 31 --> certConf --> | |||
32 handle certConf | 32 handle certConf | |||
33 format ack | 33 format ack | |||
34 <-- pkiConf <-- | 34 <-- pkiconf <-- | |||
The following client-side state machine describes polling for a | The following client-side state machine describes polling for a | |||
complete response message. | complete response message. | |||
Start | Start | |||
| | | | |||
| Send request | | Send request | |||
v | v | |||
+----------- Receive response ------------+ | +----------- Receive response ------------+ | |||
| | | | | | |||
skipping to change at line 3473 ¶ | skipping to change at line 3465 ¶ | |||
pollRep other response | | pollRep other response | | |||
v | v | |||
Handle response | Handle response | |||
| | | | |||
v | v | |||
End | End | |||
In the following exchange, the end entity is sending a general | In the following exchange, the end entity is sending a general | |||
message request, and the response is delayed by the server. | message request, and the response is delayed by the server. | |||
Step# End Entity PKI | Step# End entity PKI | |||
--------------------------------------------------------------------- | --------------------------------------------------------------------- | |||
1 format genm | 1 format genm | |||
2 --> genm --> | 2 --> genm --> | |||
3 handle genm | 3 handle genm | |||
4 delay in response is necessary | 4 delay in response is necessary | |||
5 format error message "waiting" | 5 format error message "waiting" | |||
with certReqId set to -1 | with certReqId set to -1 | |||
6 <-- error <-- | 6 <-- error <-- | |||
7 process error | 7 process error | |||
8 format pollReq | 8 format pollReq | |||
skipping to change at line 3563 ¶ | skipping to change at line 3555 ¶ | |||
produce an initial revocation list. | produce an initial revocation list. | |||
6.4. CRL Production | 6.4. CRL Production | |||
Before issuing any certificates, a newly established CA (which issues | Before issuing any certificates, a newly established CA (which issues | |||
CRLs) must produce "empty" versions of each CRL, which are to be | CRLs) must produce "empty" versions of each CRL, which are to be | |||
periodically produced. | periodically produced. | |||
6.5. PKI Information Request | 6.5. PKI Information Request | |||
When a PKI entity (CA, RA, or EE) wishes to acquire information about | When a PKI entity (CA, RA, or end entity) wishes to acquire | |||
the current status of a CA, it MAY send that CA a request for such | information about the current status of a CA, it MAY send that CA a | |||
information. | request for such information. | |||
The CA MUST respond to the request by providing (at least) all of the | The CA MUST respond to the request by providing (at least) all of the | |||
information requested by the requester. If some of the information | information requested by the requester. If some of the information | |||
cannot be provided, then an error must be conveyed to the requester. | cannot be provided, then an error must be conveyed to the requester. | |||
If PKIMessages are used to request and supply this PKI information, | If PKIMessages are used to request and supply this PKI information, | |||
then the request MUST be the GenMsg message, the response MUST be the | then the request MUST be the GenMsg message, the response MUST be the | |||
GenRep message, and the error MUST be the Error message. These | GenRep message, and the error MUST be the Error message. These | |||
messages are protected using a MAC based on shared secret information | messages are protected using a MAC based on shared secret information | |||
(e.g., password-based MAC; see Section 6.1 of "CMP Algorithms" | (e.g., password-based MAC; see Section 6.1 of "CMP Algorithms" | |||
[RFC9481]) or using any asymmetric authentication means such as a | [RFC9481]) or using any asymmetric authentication means such as a | |||
signature (if the end entity has an existing certificate). | signature (if the end entity has an existing certificate). | |||
6.6. Cross Certification | 6.6. Cross-Certification | |||
The requester CA is the CA that will become the subject of the cross- | The requester CA is the CA that will become the subject of the cross- | |||
certificate; the responder CA will become the issuer of the cross- | certificate; the responder CA will become the issuer of the cross- | |||
certificate. | certificate. | |||
The requester CA must be "up and running" before initiating the | The requester CA must be "up and running" before initiating the | |||
cross-certification operation. | cross-certification operation. | |||
6.6.1. One-Way Request-Response Scheme | 6.6.1. One-Way Request-Response Scheme | |||
skipping to change at line 3604 ¶ | skipping to change at line 3596 ¶ | |||
must initiate a cross-certification operation (or use another | must initiate a cross-certification operation (or use another | |||
scheme). | scheme). | |||
This scheme is suitable where the two CAs in question can already | This scheme is suitable where the two CAs in question can already | |||
verify each other's signatures (they have some common points of | verify each other's signatures (they have some common points of | |||
trust) or where there is an out-of-band verification of the origin of | trust) or where there is an out-of-band verification of the origin of | |||
the certification request. | the certification request. | |||
Detailed Description: | Detailed Description: | |||
Cross certification is initiated at one CA known as the responder. | Cross-certification is initiated at one CA known as the responder. | |||
The CA administrator for the responder identifies the CA it wants | The CA administrator for the responder identifies the CA it wants | |||
to cross certify and the responder CA equipment generates an | to cross-certify and the responder CA equipment generates an | |||
authorization code. The responder CA administrator passes this | authorization code. The responder CA administrator passes this | |||
authorization code by out-of-band means to the requester CA | authorization code by out-of-band means to the requester CA | |||
administrator. The requester CA administrator enters the | administrator. The requester CA administrator enters the | |||
authorization code at the requester CA in order to initiate the | authorization code at the requester CA in order to initiate the | |||
on-line exchange. | online exchange. | |||
The authorization code is used for authentication and integrity | The authorization code is used for authentication and integrity | |||
purposes. This is done by generating a symmetric key based on the | purposes. This is done by generating a symmetric key based on the | |||
authorization code and using the symmetric key for generating | authorization code and using the symmetric key for generating MACs | |||
Message Authentication Codes (MACs) on all messages exchanged. | on all messages exchanged. (Authentication may alternatively be | |||
(Authentication may alternatively be done using signatures instead | done using signatures instead of MACs, if the CAs are able to | |||
of MACs, if the CAs are able to retrieve and validate the required | retrieve and validate the required public keys by some means, such | |||
public keys by some means, such as an out-of-band hash | as an out-of-band hash comparison.) | |||
comparison.) | ||||
The requester CA initiates the exchange by generating a cross- | The requester CA initiates the exchange by generating a cross- | |||
certification request (ccr) with a fresh random number (requester | certification request (ccr) with a fresh random number (requester | |||
random number). The requester CA then sends the ccr message to | random number). The requester CA then sends the ccr message to | |||
the responder CA. The fields in this message are protected from | the responder CA. The fields in this message are protected from | |||
modification with a MAC based on the authorization code. | modification with a MAC based on the authorization code. | |||
Upon receipt of the ccr message, the responder CA validates the | Upon receipt of the ccr message, the responder CA validates the | |||
message and the MAC, saves the requester random number, and | message and the MAC, saves the requester random number, and | |||
generates its own random number (responder random number). It | generates its own random number (responder random number). It | |||
skipping to change at line 3648 ¶ | skipping to change at line 3639 ¶ | |||
Upon receipt of the ccp message, the requester CA validates the | Upon receipt of the ccp message, the requester CA validates the | |||
message (including the received random numbers) and the MAC. The | message (including the received random numbers) and the MAC. The | |||
requester CA responds with the certConf message. The fields in | requester CA responds with the certConf message. The fields in | |||
this message are protected from modification with a MAC based on | this message are protected from modification with a MAC based on | |||
the authorization code. The requester CA MAY write the requester | the authorization code. The requester CA MAY write the requester | |||
certificate to the Repository as an aid to later certificate path | certificate to the Repository as an aid to later certificate path | |||
construction. | construction. | |||
Upon receipt of the certConf message, the responder CA validates | Upon receipt of the certConf message, the responder CA validates | |||
the message and the MAC and sends back an acknowledgement using | the message and the MAC and sends back an acknowledgement using | |||
the PKIConfirm message. It MAY also publish the requester | the pkiconf message. It MAY also publish the requester | |||
certificate as an aid to later path construction. | certificate as an aid to later path construction. | |||
Notes: | Notes: | |||
1. The ccr message must contain a "complete" certification request; | 1. The ccr message must contain a "complete" certification request; | |||
that is, all fields except the serial number (including, e.g., a | that is, all fields except the serial number (including, e.g., a | |||
BasicConstraints extension) must be specified by the requester | BasicConstraints extension) must be specified by the requester | |||
CA. | CA. | |||
2. The ccp message SHOULD contain the verification certificate of | 2. The ccp message SHOULD contain the verification certificate of | |||
skipping to change at line 3753 ¶ | skipping to change at line 3744 ¶ | |||
If a client knows the protocol version(s) supported by the server | If a client knows the protocol version(s) supported by the server | |||
(e.g., from a previous PKIMessage exchange or via some out-of-band | (e.g., from a previous PKIMessage exchange or via some out-of-band | |||
means), then it MUST send a PKIMessage with the highest version | means), then it MUST send a PKIMessage with the highest version | |||
supported by both it and the server. If a client does not know what | supported by both it and the server. If a client does not know what | |||
version(s) the server supports, then it MUST send a PKIMessage using | version(s) the server supports, then it MUST send a PKIMessage using | |||
the highest version it supports with the following exception: Version | the highest version it supports with the following exception: Version | |||
cmp2021 SHOULD only be used if cmp2021 syntax is needed for the | cmp2021 SHOULD only be used if cmp2021 syntax is needed for the | |||
request being sent or for the expected response. | request being sent or for the expected response. | |||
Note: Using cmp2000 as the default pvno is done to avoid extra | Note: Using cmp2000 as the default pvno value is done to avoid extra | |||
message exchanges for version negotiation and to foster compatibility | message exchanges for version negotiation and to foster compatibility | |||
with cmp2000 implementations. Version cmp2021 syntax is only needed | with cmp2000 implementations. Version cmp2021 syntax is only needed | |||
if a message exchange uses EnvelopedData, hashAlg (in CertStatus), | if a message exchange uses EnvelopedData, hashAlg (in CertStatus), | |||
POPOPrivKey with agreeMAC, or ckuann with RootCaKeyUpdateContent. | POPOPrivKey with agreeMAC, or ckuann with RootCaKeyUpdateContent. | |||
If a server receives a message with a version that it supports, then | If a server receives a message with a version that it supports, then | |||
the version of the response message MUST be the same as the received | the version of the response message MUST be the same as the received | |||
version. If a server receives a message with a version higher or | version. If a server receives a message with a version higher or | |||
lower than it supports, then it MUST send back an ErrorMsg with the | lower than it supports, then it MUST send back an ErrorMsg with the | |||
unsupportedVersion bit set (in the failureInfo field of the | unsupportedVersion bit set (in the failureInfo field of the | |||
skipping to change at line 3783 ¶ | skipping to change at line 3774 ¶ | |||
7.1. Supporting RFC 2510 Implementations | 7.1. Supporting RFC 2510 Implementations | |||
[RFC2510] did not specify the behavior of implementations receiving | [RFC2510] did not specify the behavior of implementations receiving | |||
versions they did not understand since there was only one version in | versions they did not understand since there was only one version in | |||
existence. With the introduction of the revision in [RFC4210], the | existence. With the introduction of the revision in [RFC4210], the | |||
following versioning behavior is recommended. | following versioning behavior is recommended. | |||
7.1.1. Clients Talking to RFC 2510 Servers | 7.1.1. Clients Talking to RFC 2510 Servers | |||
If, after sending a message with a protocol version number higher | If, after sending a message with a pvno value higher than cmp1999, a | |||
than cmp1999, a client receives an ErrorMsgContent with a version of | client receives an ErrorMsgContent with a version of cmp1999, then it | |||
cmp1999, then it MUST abort the current transaction. | MUST abort the current transaction. | |||
If a client receives a non-error PKIMessage with a version of | If a client receives a non-error PKIMessage with a version of | |||
cmp1999, then it MAY decide to continue the transaction (if the | cmp1999, then it MAY decide to continue the transaction (if the | |||
transaction hasn't finished) using the semantics described in | transaction hasn't finished) using the semantics described in | |||
[RFC2510]. If it does not choose to do so and the transaction is not | [RFC2510]. If it does not choose to do so and the transaction is not | |||
finished, then it MUST abort the transaction and send an | finished, then it MUST abort the transaction and send an | |||
ErrorMsgContent with a version of cmp1999. | ErrorMsgContent with a version of cmp1999. | |||
7.1.2. Servers Receiving Version cmp1999 PKIMessages | 7.1.2. Servers Receiving Version cmp1999 PKIMessages | |||
If a server receives a version cmp1999 message, it MAY revert to the | If a server receives a version cmp1999 message, it MAY revert to the | |||
behavior described in [RFC2510] and respond with version cmp1999 | behavior described in [RFC2510] and respond with version cmp1999 | |||
messages. If it does not choose to do so, then it MUST send back an | messages. If it does not choose to do so, then it MUST send back an | |||
ErrorMsgContent as described above in Section 7. | ErrorMsgContent as described above in Section 7. | |||
8. Security Considerations | 8. Security Considerations | |||
8.1. On the Necessity of Proof-of-Possession | 8.1. On the Necessity of POP | |||
It is well established that the role of a Certification Authority is | It is well established that the role of a CA is to verify that the | |||
to verify that the name and public key belong to the end entity prior | name and public key belong to the end entity prior to issuing a | |||
to issuing a certificate. If an entity holding a private key obtains | certificate. If an entity holding a private key obtains a | |||
a certificate containing the corresponding public key issued for a | certificate containing the corresponding public key issued for a | |||
different entity, it can authenticate as the entity named in the | different entity, it can authenticate as the entity named in the | |||
certificate. This facilitates masquerading. It is not entirely | certificate. This facilitates masquerading. It is not entirely | |||
clear what security guarantees are lost if an end entity is able to | clear what security guarantees are lost if an end entity is able to | |||
obtain a certificate containing a public key that they do not possess | obtain a certificate containing a public key that they do not possess | |||
the corresponding private key for. There are some scenarios, | the corresponding private key for. There are some scenarios, | |||
described as "forwarding attacks" in Appendix A of [Gueneysu], in | described as "forwarding attacks" in Appendix A of [Gueneysu], in | |||
which this can lead to protocol attacks against a naively implemented | which this can lead to protocol attacks against a naively implemented | |||
sign-then-encrypt protocol, but in general, it merely results in the | sign-then-encrypt protocol, but in general, it merely results in the | |||
end entity obtaining a certificate that they cannot use. | end entity obtaining a certificate that they cannot use. | |||
8.2. Proof-of-Possession with a Decryption Key | 8.2. POP with a Decryption Key | |||
Some cryptographic considerations are worth explicitly spelling out. | Some cryptographic considerations are worth explicitly spelling out. | |||
In the protocols specified above, when an end entity is required to | In the protocols specified above, when an end entity is required to | |||
prove possession of a decryption key, it is effectively challenged to | prove possession of a decryption key, it is effectively challenged to | |||
decrypt something (its own certificate). This scheme (and many | decrypt something (its own certificate). This scheme (and many | |||
others!) could be vulnerable to an attack if the possessor of the | others!) could be vulnerable to an attack if the possessor of the | |||
decryption key in question could be fooled into decrypting an | decryption key in question could be fooled into decrypting an | |||
arbitrary challenge and returning the cleartext to an attacker. | arbitrary challenge and returning the cleartext to an attacker. | |||
Although in this specification a number of other failures in security | Although in this specification a number of other failures in security | |||
are required in order for this attack to succeed, it is conceivable | are required in order for this attack to succeed, it is conceivable | |||
skipping to change at line 3842 ¶ | skipping to change at line 3833 ¶ | |||
reiterate the general rule that implementations should be very | reiterate the general rule that implementations should be very | |||
careful about decrypting arbitrary "ciphertext" and revealing | careful about decrypting arbitrary "ciphertext" and revealing | |||
recovered "plaintext" since such a practice can lead to serious | recovered "plaintext" since such a practice can lead to serious | |||
security vulnerabilities. | security vulnerabilities. | |||
The client MUST return the decrypted values only if they match the | The client MUST return the decrypted values only if they match the | |||
expected content type. In an indirect method, the decrypted value | expected content type. In an indirect method, the decrypted value | |||
MUST be a valid certificate, and in a direct method, the decrypted | MUST be a valid certificate, and in a direct method, the decrypted | |||
value MUST be a Rand as defined in Section 5.2.8.3.3. | value MUST be a Rand as defined in Section 5.2.8.3.3. | |||
8.3. Proof-of-Possession by Exposing the Private Key | 8.3. POP by Exposing the Private Key | |||
Note also that exposing a private key to the CA/RA as a proof-of- | Note also that exposing a private key to the CA/RA as a POP technique | |||
possession technique can carry some security risks (depending upon | can carry some security risks (depending upon whether or not the CA/ | |||
whether or not the CA/RA can be trusted to handle such material | RA can be trusted to handle such material appropriately). | |||
appropriately). Implementers are advised to: | Implementers are advised to: | |||
* Exercise caution in selecting and using this particular POP | * Exercise caution in selecting and using this particular POP | |||
mechanism. | mechanism. | |||
* Only use this POP mechanism if archival of the private key is | * Only use this POP mechanism if archival of the private key is | |||
desired. | desired. | |||
* When appropriate, have the user of the application explicitly | * When appropriate, have the user of the application explicitly | |||
state that they are willing to trust the CA/RA to have a copy of | state that they are willing to trust the CA/RA to have a copy of | |||
their private key before proceeding to reveal the private key. | their private key before proceeding to reveal the private key. | |||
8.4. Attack Against Diffie-Hellman Key Exchange | 8.4. Attack Against DH Key Exchange | |||
A small subgroup attack during a Diffie-Hellman key exchange may be | A small subgroup attack during a DH key exchange may be carried out | |||
carried out as follows. A malicious end entity may deliberately | as follows. A malicious end entity may deliberately choose DH | |||
choose DH parameters that enable it to derive (a significant number | parameters that enable it to derive (a significant number of bits of) | |||
of bits of) the DH private key of the CA during a key archival or key | the DH private key of the CA during a key archival or key recovery | |||
recovery operation. Armed with this knowledge, the EE would then be | operation. Armed with this knowledge, the end entity would then be | |||
able to retrieve the decryption private key of another unsuspecting | able to retrieve the decryption private key of another unsuspecting | |||
end entity, EE2, during EE2's legitimate key archival or key recovery | end entity, EE2, during EE2's legitimate key archival or key recovery | |||
operation with that CA. In order to avoid the possibility of such an | operation with that CA. In order to avoid the possibility of such an | |||
attack, two courses of action are available. (1) The CA may generate | attack, two courses of action are available. (1) The CA may generate | |||
a fresh DH key pair to be used as a protocol encryption key pair for | a fresh DH key pair to be used as a protocol encryption key pair for | |||
each EE with which it interacts. (2) The CA may enter into a key | each end entity with which it interacts. (2) The CA may enter into a | |||
validation protocol (not specified in this document) with each | key validation protocol (not specified in this document) with each | |||
requesting end entity to ensure that the EE's protocol encryption key | requesting end entity to ensure that the end entity's protocol | |||
pair will not facilitate this attack. Option (1) is clearly simpler | encryption key pair will not facilitate this attack. Option (1) is | |||
(requiring no extra protocol exchanges from either party) and is | clearly simpler (requiring no extra protocol exchanges from either | |||
therefore RECOMMENDED. | party) and is therefore RECOMMENDED. | |||
8.5. Perfect Forward Secrecy | 8.5. Perfect Forward Secrecy | |||
Long-term security typically requires perfect forward secrecy (pfs). | Long-term security typically requires perfect forward secrecy (pfs). | |||
When transferring encrypted long-term confidential values such as | When transferring encrypted long-term confidential values such as | |||
centrally generated private keys or revocation passphrases, pfs is | centrally generated private keys or revocation passphrases, pfs is | |||
likely important. Yet, it is not needed for CMP message protection | likely important. Yet, it is not needed for CMP message protection | |||
providing integrity and authenticity because transfer of PKI messages | providing integrity and authenticity because transfer of PKI messages | |||
is usually completed in very limited time. For the same reason, it | is usually completed in very limited time. For the same reason, it | |||
is not typically required for the indirect method to provide a POP | is not typically required for the indirect method to provide a POP | |||
skipping to change at line 3925 ¶ | skipping to change at line 3916 ¶ | |||
numbers is difficult. ISO/IEC 20543:2019 [ISO.20543-2019], NIST SP | numbers is difficult. ISO/IEC 20543:2019 [ISO.20543-2019], NIST SP | |||
800-90A Rev.1 [NIST.SP.800_90Ar1], BSI AIS 31 V2.0 [AIS31], and other | 800-90A Rev.1 [NIST.SP.800_90Ar1], BSI AIS 31 V2.0 [AIS31], and other | |||
specifications offer valuable guidance in this area. | specifications offer valuable guidance in this area. | |||
If shared secret information is generated by a cryptographically | If shared secret information is generated by a cryptographically | |||
secure random number generator (CSRNG), it is safe to assume that the | secure random number generator (CSRNG), it is safe to assume that the | |||
entropy of the shared secret information equals its bit length. If | entropy of the shared secret information equals its bit length. If | |||
no CSRNG is used, the entropy of shared secret information depends on | no CSRNG is used, the entropy of shared secret information depends on | |||
the details of the generation process and cannot be measured securely | the details of the generation process and cannot be measured securely | |||
after it has been generated. If user-generated passwords are used as | after it has been generated. If user-generated passwords are used as | |||
shared secret information, their entropy cannot be measured and are | shared secret information, their entropy cannot be measured. | |||
typically insufficient for protected delivery of centrally generated | Passwords generated from user-supplied entropy are typically | |||
keys or trust anchors. | insufficient for protected delivery of centrally generated keys or | |||
trust anchors. | ||||
If the entropy of shared secret information protecting the delivery | If the entropy of shared secret information protecting the delivery | |||
of a centrally generated key pair is known, it should not be less | of a centrally generated key pair is known, it should not be less | |||
than the security strength of that key pair; if the shared secret | than the security strength of that key pair; if the shared secret | |||
information is reused for different key pairs, the security of the | information is reused for different key pairs, the security of the | |||
shared secret information should exceed the security strength of each | shared secret information should exceed the security strength of each | |||
individual key pair. | individual key pair. | |||
For the case of a PKI management operation that delivers a new trust | For the case of a PKI management operation that delivers a new trust | |||
anchor (e.g., a root CA certificate), using caPubs or genp that is | anchor (e.g., a root CA certificate), using caPubs or genp that is | |||
skipping to change at line 3985 ¶ | skipping to change at line 3977 ¶ | |||
Therefore, given a long-term public key using an IND-CCA2-secure KEM | Therefore, given a long-term public key using an IND-CCA2-secure KEM | |||
algorithm, there is no limit to the number of CMP messages that can | algorithm, there is no limit to the number of CMP messages that can | |||
be authenticated using KEM keys for MAC-based message protection. | be authenticated using KEM keys for MAC-based message protection. | |||
8.9. Trust Anchor Provisioning Using CMP Messages | 8.9. Trust Anchor Provisioning Using CMP Messages | |||
A provider of trust anchors, which may be an RA involved in | A provider of trust anchors, which may be an RA involved in | |||
configuration management of its clients, MUST NOT include to-be- | configuration management of its clients, MUST NOT include to-be- | |||
trusted CA certificates in a CMP message unless the specific | trusted CA certificates in a CMP message unless the specific | |||
deployment scenario can ensure that it is adequate that the receiving | deployment scenario can ensure that it is adequate that the receiving | |||
EE trusts these certificates, e.g., by loading them into its trust | end entity trusts these certificates, e.g., by loading them into its | |||
store. | trust store. | |||
Whenever an EE receives in a CMP message a CA certificate to be used | Whenever an end entity receives in a CMP message a CA certificate to | |||
as a trust anchor (for example, in the caPubs field of a certificate | be used as a trust anchor (for example, in the caPubs field of a | |||
response or in a general response), it MUST properly authenticate the | certificate response or in a general response), it MUST properly | |||
message sender with existing trust anchors without requiring new | authenticate the message sender with existing trust anchors without | |||
trust anchor information included in the message. | requiring new trust anchor information included in the message. | |||
Additionally, the EE MUST verify that the sender is an authorized | Additionally, the end entity MUST verify that the sender is an | |||
source of trust anchors. This authorization is governed by local | authorized source of trust anchors. This authorization is governed | |||
policy and typically indicated using shared secret information or | by local policy and typically indicated using shared secret | |||
with a signature-based message protection using a certificate issued | information or with a signature-based message protection using a | |||
by a PKI that is explicitly authorized for this purpose. | certificate issued by a PKI that is explicitly authorized for this | |||
purpose. | ||||
8.10. Authorizing Requests for Certificates with Specific EKUs | 8.10. Authorizing Requests for Certificates with Specific EKUs | |||
When a CA issues a certificate containing extended key usage | When a CA issues a certificate containing EKU extensions as defined | |||
extensions as defined in Section 4.5, this expresses delegation of an | in Section 4.5, this expresses delegation of an authorization that | |||
authorization that originally is only with the CA certificate itself. | originally is only with the CA certificate itself. Such delegation | |||
Such delegation is a very sensitive action in a PKI, and therefore, | is a very sensitive action in a PKI, and therefore, special care must | |||
special care must be taken when approving such certificate requests | be taken when approving such certificate requests to ensure that only | |||
to ensure that only legitimate entities receive a certificate | legitimate entities receive a certificate containing such an EKU. | |||
containing such an EKU. | ||||
8.11. Usage of Certificate Transparency Logs | 8.11. Usage of CT Logs | |||
CAs that support indirect POP MUST NOT also publish final | CAs that support indirect POP MUST NOT also publish final | |||
certificates to Certificate Transparency (CT) logs [RFC9162] before | certificates to CT logs [RFC9162] before having received the certConf | |||
having received the certConf message containing the certHash of that | message containing the certHash of that certificate to complete the | |||
certificate to complete the POP. The risk is that a malicious actor | POP. The risk is that a malicious actor could fetch the final | |||
could fetch the final certificate from the CT log and use that to | certificate from the CT log and use that to spoof a response to the | |||
spoof a response to the implicit POP challenge via a certConf | implicit POP challenge via a certConf response. This risk does not | |||
response. This risk does not apply to CT precertificates, so those | apply to CT precertificates, so those are OK to publish. | |||
are OK to publish. | ||||
If a certificate or its precertificate was published in a CT log, it | If a certificate or its precertificate was published in a CT log, it | |||
must be revoked if a required certConf message could not be verified, | must be revoked if a required certConf message could not be verified, | |||
especially when the implicit POP was used. | especially when the implicit POP was used. | |||
9. IANA Considerations | 9. IANA Considerations | |||
This document updates the ASN.1 modules in Appendix A.2 of CMP | This document updates the ASN.1 modules in Appendix A.2 of CMP | |||
Updates [RFC9480]. The OID 116 (id-mod-cmp2023-02) was registered in | Updates [RFC9480]. The OID 116 (id-mod-cmp2023-02) was registered in | |||
the "SMI Security for PKIX Module Identifier" registry to identify | the "SMI Security for PKIX Module Identifier" registry to identify | |||
the updated ASN.1 module. | the updated ASN.1 module. | |||
IANA has added the following entry in the "SMI Security for PKIX CMP | IANA has added the following entry in the "SMI Security for PKIX CMP | |||
Information Types" registry within the SMI Numbers registry group | Information Types" registry within the SMI Numbers registry group | |||
(see <https://www.iana.org/assignments/smi-numbers>) [RFC7299]: | (see <https://www.iana.org/assignments/smi-numbers>) [RFC7299]: | |||
Decimal: 24 | Decimal: 24 | |||
Description: id-it-KemCiphertextInfo | Description: id-it-KemCiphertextInfo | |||
Reference: RFC 9810 | Reference: RFC 9810 | |||
The new OID 1.2.840.113533.7.66.16 was registered by Entrust for id- | Note that the new OID 1.2.840.113533.7.66.16 was registered by | |||
KemBasedMac in the arc 1.2.840.113533.7.66. Entrust also registered | Entrust, and not by IANA, for id-KemBasedMac in the arc | |||
the OIDs for id-PasswordBasedMac and id-DHBasedMac there. | 1.2.840.113533.7.66. This was done to match the previous | |||
registrations for id-PasswordBasedMac and id-DHBasedMac, which are | ||||
also on the Entrust private arc. | ||||
All existing references to [RFC2510], [RFC4210], and [RFC9480] at | All existing references to [RFC2510], [RFC4210], and [RFC9480] at | |||
<https://www.iana.org/assignments/smi-numbers> except those in the | <https://www.iana.org/assignments/smi-numbers> except those in the | |||
"SMI Security for PKIX Module Identifier" registry have been replaced | "SMI Security for PKIX Module Identifier" registry have been replaced | |||
with references to this document. | with references to this document. | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[MvOV97] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook | ||||
of Applied Cryptography", CRC Press ISBN 0-8493-8523-7, | ||||
1996, <https://cacr.uwaterloo.ca/hac/>. | ||||
[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>. | ||||
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | |||
Classes and Attribute Types Version 2.0", RFC 2985, | Classes and Attribute Types Version 2.0", RFC 2985, | |||
DOI 10.17487/RFC2985, November 2000, | DOI 10.17487/RFC2985, November 2000, | |||
<https://www.rfc-editor.org/info/rfc2985>. | <https://www.rfc-editor.org/info/rfc2985>. | |||
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | |||
Request Syntax Specification Version 1.7", RFC 2986, | Request Syntax Specification Version 1.7", RFC 2986, | |||
DOI 10.17487/RFC2986, November 2000, | DOI 10.17487/RFC2986, November 2000, | |||
<https://www.rfc-editor.org/info/rfc2986>. | <https://www.rfc-editor.org/info/rfc2986>. | |||
skipping to change at line 4099 ¶ | skipping to change at line 4101 ¶ | |||
<https://www.rfc-editor.org/info/rfc5652>. | <https://www.rfc-editor.org/info/rfc5652>. | |||
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, | [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, | |||
DOI 10.17487/RFC5958, August 2010, | DOI 10.17487/RFC5958, August 2010, | |||
<https://www.rfc-editor.org/info/rfc5958>. | <https://www.rfc-editor.org/info/rfc5958>. | |||
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) | [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) | |||
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, | Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, | |||
<https://www.rfc-editor.org/info/rfc6402>. | <https://www.rfc-editor.org/info/rfc6402>. | |||
[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>. | ||||
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax | [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax | |||
(CMS) for Algorithm Identifier Protection", RFC 8933, | (CMS) for Algorithm Identifier Protection", RFC 8933, | |||
DOI 10.17487/RFC8933, October 2020, | DOI 10.17487/RFC8933, October 2020, | |||
<https://www.rfc-editor.org/info/rfc8933>. | <https://www.rfc-editor.org/info/rfc8933>. | |||
[RFC9045] Housley, R., "Algorithm Requirements Update to the | [RFC9045] Housley, R., "Algorithm Requirements Update to the | |||
Internet X.509 Public Key Infrastructure Certificate | Internet X.509 Public Key Infrastructure Certificate | |||
Request Message Format (CRMF)", RFC 9045, | Request Message Format (CRMF)", RFC 9045, | |||
DOI 10.17487/RFC9045, June 2021, | DOI 10.17487/RFC9045, June 2021, | |||
<https://www.rfc-editor.org/info/rfc9045>. | <https://www.rfc-editor.org/info/rfc9045>. | |||
skipping to change at line 4121 ¶ | skipping to change at line 4127 ¶ | |||
"Certificate Management Protocol (CMP) Algorithms", | "Certificate Management Protocol (CMP) Algorithms", | |||
RFC 9481, DOI 10.17487/RFC9481, November 2023, | RFC 9481, DOI 10.17487/RFC9481, November 2023, | |||
<https://www.rfc-editor.org/info/rfc9481>. | <https://www.rfc-editor.org/info/rfc9481>. | |||
[RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key | [RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key | |||
Encapsulation Mechanism (KEM) Algorithms in the | Encapsulation Mechanism (KEM) Algorithms in the | |||
Cryptographic Message Syntax (CMS)", RFC 9629, | Cryptographic Message Syntax (CMS)", RFC 9629, | |||
DOI 10.17487/RFC9629, August 2024, | DOI 10.17487/RFC9629, August 2024, | |||
<https://www.rfc-editor.org/info/rfc9629>. | <https://www.rfc-editor.org/info/rfc9629>. | |||
[MvOV97] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook | 10.2. Informative References | |||
of Applied Cryptography", CRC Press ISBN 0-8493-8523-7, | ||||
1996. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [AIS31] Killmann, W. and W. Schindler, "A proposal for: | |||
Requirement Levels", BCP 14, RFC 2119, | Functionality classes for random number generators - | |||
DOI 10.17487/RFC2119, March 1997, | Version 2.0", Federal Office for Information Security | |||
<https://www.rfc-editor.org/info/rfc2119>. | (BSI), September 2011, | |||
<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ | ||||
Zertifizierung/Interpretationen/AIS_31_Functionality_class | ||||
es_for_random_number_generators_e.pdf>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [CVE-2008-0166] | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | National Institute of Science and Technology (NIST), | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | "National Vulnerability Database - CVE-2008-0166", May | |||
2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>. | ||||
10.2. Informative References | [ETSI-3GPP.33.310] | |||
3GPP, "Network Domain Security (NDS); Authentication | ||||
Framework (AF)", 3GPP TS 33.310 16.6.0, December 2020, | ||||
<http://www.3gpp.org/ftp/Specs/html-info/33310.htm>. | ||||
[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate | [Fujisaki] Fujisaki, E. and T. Okamoto, "Secure Integration of | |||
Management Protocol (CMP) Updates", RFC 9480, | Asymmetric and Symmetric Encryption Schemes", Journal of | |||
DOI 10.17487/RFC9480, November 2023, | Cryptology, vol. 26, no. 1, pp. 80-101, | |||
<https://www.rfc-editor.org/info/rfc9480>. | DOI 10.1007/s00145-011-9114-1, December 2011, | |||
<https://doi.org/10.1007/s00145-011-9114-1>. | ||||
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained | [Gueneysu] Gueneysu, T., Hodges, P., Land, G., Ounsworth, M., | |||
Application Protocol (CoAP) Transfer for the Certificate | Stebila, D., and G. Zaverucha, "Proof-of-possession for | |||
Management Protocol", RFC 9482, DOI 10.17487/RFC9482, | KEM certificates using verifiable generation", Cryptology | |||
November 2023, <https://www.rfc-editor.org/info/rfc9482>. | ePrint Archive, Paper 2022/703, 2022, | |||
<https://eprint.iacr.org/2022/703>. | ||||
[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight | [Hofheinz] Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular | |||
Certificate Management Protocol (CMP) Profile", RFC 9483, | Analysis of the Fujisaki-Okamoto Transformation", Theory | |||
DOI 10.17487/RFC9483, November 2023, | of Cryptography (TCC 2017), Lecture Notes in Computer | |||
<https://www.rfc-editor.org/info/rfc9483>. | Science, vol. 10677, pp. 341-371, | |||
DOI 10.1007/978-3-319-70500-2_12, November 2017, | ||||
<https://doi.org/10.1007/978-3-319-70500-2_12>. | ||||
[RFC9811] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray, | [IEEE.802.1AR-2018] | |||
"Internet X.509 Public Key Infrastructure -- HTTP Transfer | IEEE, "IEEE Standard for Local and Metropolitan Area | |||
for the Certificate Management Protocol (CMP)", RFC 9811, | Networks - Secure Device Identity", IEEE Std 802.1AR-2018, | |||
June 2025, <https://www.rfc-editor.org/info/rfc9811>. | DOI 10.1109/ieeestd.2018.8423794, August 2018, | |||
<https://doi.org/10.1109/ieeestd.2018.8423794>. | ||||
[ISO.20543-2019] | ||||
ISO/IEC, "Information technology -- Security techniques -- | ||||
Test and analysis methods for random bit generators within | ||||
ISO/IEC 19790 and ISO/IEC 15408", ISO/IEC 20543:2019, | ||||
October 2019, <https://www.iso.org/standard/68296.html>. | ||||
[MiningPsQs] | ||||
Heninger, N., Durumeric, Z., Wustrow, E., and J. A. | ||||
Halderman, "Mining Your Ps and Qs: Detection of Widespread | ||||
Weak Keys in Network Devices", 21st USENIX Security | ||||
Symposium (USENIX Security 12), August 2012, | ||||
<https://www.usenix.org/conference/usenixsecurity12/ | ||||
technical-sessions/presentation/heninger>. | ||||
[ML-KEM] Turner, S., Kampanakis, P., Massimo, J., and B. | ||||
Westerbaan, "Internet X.509 Public Key Infrastructure - | ||||
Algorithm Identifiers for the Module-Lattice-Based Key- | ||||
Encapsulation Mechanism (ML-KEM)", Work in Progress, | ||||
Internet-Draft, draft-ietf-lamps-kyber-certificates-10, 16 | ||||
April 2025, <https://datatracker.ietf.org/doc/html/draft- | ||||
ietf-lamps-kyber-certificates-10>. | ||||
[NIST.SP.800_90Ar1] | ||||
Barker, E. B. and J. M. Kelsey, "Recommendation for Random | ||||
Number Generation Using Deterministic Random Bit | ||||
Generators", NIST SP 800-90Ar1, | ||||
DOI 10.6028/NIST.SP.800-90Ar1, June 2015, | ||||
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | ||||
NIST.SP.800-90Ar1.pdf>. | ||||
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | |||
"Security Multiparts for MIME: Multipart/Signed and | "Security Multiparts for MIME: Multipart/Signed and | |||
Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, | Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, | |||
October 1995, <https://www.rfc-editor.org/info/rfc1847>. | October 1995, <https://www.rfc-editor.org/info/rfc1847>. | |||
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key | [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key | |||
Infrastructure Certificate Management Protocols", | Infrastructure Certificate Management Protocols", | |||
RFC 2510, DOI 10.17487/RFC2510, March 1999, | RFC 2510, DOI 10.17487/RFC2510, March 1999, | |||
<https://www.rfc-editor.org/info/rfc2510>. | <https://www.rfc-editor.org/info/rfc2510>. | |||
skipping to change at line 4245 ¶ | skipping to change at line 4291 ¶ | |||
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The | [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The | |||
Datagram Transport Layer Security (DTLS) Protocol Version | Datagram Transport Layer Security (DTLS) Protocol Version | |||
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, | 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, | |||
<https://www.rfc-editor.org/info/rfc9147>. | <https://www.rfc-editor.org/info/rfc9147>. | |||
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate | [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate | |||
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, | Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, | |||
December 2021, <https://www.rfc-editor.org/info/rfc9162>. | December 2021, <https://www.rfc-editor.org/info/rfc9162>. | |||
[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate | ||||
Management Protocol (CMP) Updates", RFC 9480, | ||||
DOI 10.17487/RFC9480, November 2023, | ||||
<https://www.rfc-editor.org/info/rfc9480>. | ||||
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained | ||||
Application Protocol (CoAP) Transfer for the Certificate | ||||
Management Protocol", RFC 9482, DOI 10.17487/RFC9482, | ||||
November 2023, <https://www.rfc-editor.org/info/rfc9482>. | ||||
[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight | ||||
Certificate Management Protocol (CMP) Profile", RFC 9483, | ||||
DOI 10.17487/RFC9483, November 2023, | ||||
<https://www.rfc-editor.org/info/rfc9483>. | ||||
[RFC9733] von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "BRSKI | [RFC9733] von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "BRSKI | |||
with Alternative Enrollment (BRSKI-AE)", RFC 9733, | with Alternative Enrollment (BRSKI-AE)", RFC 9733, | |||
DOI 10.17487/RFC9733, March 2025, | DOI 10.17487/RFC9733, March 2025, | |||
<https://www.rfc-editor.org/info/rfc9733>. | <https://www.rfc-editor.org/info/rfc9733>. | |||
[ML-KEM] Turner, S., Kampanakis, P., Massimo, J., and B. | [RFC9811] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray, | |||
Westerbaan, "Internet X.509 Public Key Infrastructure - | "Internet X.509 Public Key Infrastructure -- HTTP Transfer | |||
Algorithm Identifiers for the Module-Lattice-Based Key- | for the Certificate Management Protocol (CMP)", RFC 9811, | |||
Encapsulation Mechanism (ML-KEM)", Work in Progress, | July 2025, <https://www.rfc-editor.org/info/rfc9811>. | |||
Internet-Draft, draft-ietf-lamps-kyber-certificates-10, 16 | ||||
April 2025, <https://datatracker.ietf.org/doc/html/draft- | ||||
ietf-lamps-kyber-certificates-10>. | ||||
[NIST.SP.800_90Ar1] | ||||
Barker, E. B. and J. M. Kelsey, "Recommendation for Random | ||||
Number Generation Using Deterministic Random Bit | ||||
Generators", NIST SP 800-90Ar1, | ||||
DOI 10.6028/NIST.SP.800-90Ar1, June 2015, | ||||
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | ||||
NIST.SP.800-90Ar1.pdf>. | ||||
[IEEE.802.1AR-2018] | ||||
IEEE, "IEEE Standard for Local and Metropolitan Area | ||||
Networks - Secure Device Identity", IEEE Std 802.1AR-2018, | ||||
DOI 10.1109/ieeestd.2018.8423794, August 2018, | ||||
<https://doi.org/10.1109/ieeestd.2018.8423794>. | ||||
[CVE-2008-0166] | ||||
National Institute of Science and Technology (NIST), | ||||
"National Vulnerability Database - CVE-2008-0166", May | ||||
2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>. | ||||
[MiningPsQs] | [UNISIG.Subset-137] | |||
Heninger, N., Durumeric, Z., Wustrow, E., and J. A. | UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset- | |||
Halderman, "Mining Your Ps and Qs: Detection of Widespread | 137, V1.0.0, December 2015, | |||
Weak Keys in Network Devices", 21st USENIX Security | <https://www.era.europa.eu/system/files/2023-01/ | |||
Symposium (USENIX Security 12), August 2012, | sos3_index083_-_subset-137_v100.pdf>. | |||
<https://www.usenix.org/conference/usenixsecurity12/ | ||||
technical-sessions/presentation/heninger>. | ||||
[X509.2019] | [X509.2019] | |||
ITU-T, "Information technology - Open Systems | ITU-T, "Information technology - Open Systems | |||
Interconnection - The Directory: Public-key and attribute | Interconnection - The Directory: Public-key and attribute | |||
certificate frameworks", ITU-T Recommendation X.509 | certificate frameworks", ITU-T Recommendation X.509 | |||
(10/2019), October 2019, | (10/2019), October 2019, | |||
<https://handle.itu.int/11.1002/1000/14033>. | <https://handle.itu.int/11.1002/1000/14033>. | |||
[ISO.20543-2019] | ||||
ISO/IEC, "Information technology -- Security techniques -- | ||||
Test and analysis methods for random bit generators within | ||||
ISO/IEC 19790 and ISO/IEC 15408", ISO/IEC 20543:2019, | ||||
October 2019, <https://www.iso.org/standard/68296.html>. | ||||
[AIS31] Killmann, W. and W. Schindler, "A proposal for: | ||||
Functionality classes for random number generators - | ||||
Version 2.0", Federal Office for Information Security | ||||
(BSI), September 2011, | ||||
<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ | ||||
Zertifizierung/Interpretationen/AIS_31_Functionality_class | ||||
es_for_random_number_generators_e.pdf>. | ||||
[Gueneysu] Gueneysu, T., Hodges, P., Land, G., Ounsworth, M., | ||||
Stebila, D., and G. Zaverucha, "Proof-of-possession for | ||||
KEM certificates using verifiable generation", Cryptology | ||||
ePrint Archive, Paper 2022/703, 2022, | ||||
<https://eprint.iacr.org/2022/703>. | ||||
[Fujisaki] Fujisaki, E. and T. Okamoto, "Secure Integration of | ||||
Asymmetric and Symmetric Encryption Schemes", 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>. | ||||
[Hofheinz] Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular | ||||
Analysis of the Fujisaki-Okamoto Transformation", Theory | ||||
of Cryptography (TCC 2017), Lecture Notes in Computer | ||||
Science, vol. 10677, pp. 341-371, | ||||
DOI 10.1007/978-3-319-70500-2_12, November 2017, | ||||
<https://doi.org/10.1007/978-3-319-70500-2_12>. | ||||
[ETSI-3GPP.33.310] | ||||
3GPP, "Network Domain Security (NDS); Authentication | ||||
Framework (AF)", 3GPP TS 33.310 16.6.0, December 2020, | ||||
<http://www.3gpp.org/ftp/Specs/html-info/33310.htm>. | ||||
[UNISIG.Subset-137] | ||||
UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset- | ||||
137, V1.0.0, December 2015, | ||||
<https://www.era.europa.eu/system/files/2023-01/ | ||||
sos3_index083_-_subset-137_v100.pdf>. | ||||
Appendix A. Reasons for the Presence of RAs | Appendix A. Reasons for the Presence of RAs | |||
The reasons that justify the presence of an RA can be split into | The reasons that justify the presence of an RA can be split into | |||
those that are due to technical factors and those that are | those that are due to technical factors and those that are | |||
organizational in nature. Technical reasons include the following. | organizational in nature. Technical reasons include the following. | |||
* If hardware tokens are in use, then not all end entities will have | * If hardware tokens are in use, then not all end entities will have | |||
the equipment needed to initialize these; the RA equipment can | the equipment needed to initialize these; the RA equipment can | |||
include the necessary functionality (this may also be a matter of | include the necessary functionality (this may also be a matter of | |||
policy). | policy). | |||
skipping to change at line 4511 ¶ | skipping to change at line 4504 ¶ | |||
* certificate request | * certificate request | |||
* key update | * key update | |||
C.1. General Rules for Interpretation of These Profiles | C.1. General Rules for Interpretation of These Profiles | |||
1. Where OPTIONAL or DEFAULT fields are not mentioned in individual | 1. Where OPTIONAL or DEFAULT fields are not mentioned in individual | |||
profiles, they SHOULD be absent from the relevant message (i.e., | profiles, they SHOULD be absent from the relevant message (i.e., | |||
a receiver can validly reject a message containing such fields as | a receiver can validly reject a message containing such fields as | |||
being syntactically incorrect). Mandatory fields are not | being syntactically incorrect). Mandatory fields are not | |||
mentioned if they have an obvious value. The pvno MUST be set as | mentioned if they have an obvious value. The protocol version | |||
specified in Section 7). | number MUST be set as specified in Section 7). | |||
2. Where structures occur in more than one message, they are | 2. Where structures occur in more than one message, they are | |||
separately profiled as appropriate. | separately profiled as appropriate. | |||
3. The algorithmIdentifiers from PKIMessage structures are profiled | 3. The algorithmIdentifiers from PKIMessage structures are profiled | |||
separately. | separately. | |||
4. A "special" X.500 DN is called the "NULL-DN"; this means a DN | 4. A "special" X.500 DN is called the "NULL-DN"; this means a DN | |||
containing a zero-length SEQUENCE OF RelativeDistinguishedNames | containing a zero-length SEQUENCE OF RelativeDistinguishedNames | |||
(its DER encoding is then '3000'H). | (its DER encoding is then '3000'H). | |||
skipping to change at line 4545 ¶ | skipping to change at line 4538 ¶ | |||
names these using a "dot" notation (e.g., "certTemplate.subject" | names these using a "dot" notation (e.g., "certTemplate.subject" | |||
means the subject field within a field called certTemplate). | means the subject field within a field called certTemplate). | |||
8. Where a "SEQUENCE OF types" is part of a message, a zero-based | 8. Where a "SEQUENCE OF types" is part of a message, a zero-based | |||
array notation is used to describe fields within the SEQUENCE OF | array notation is used to describe fields within the SEQUENCE OF | |||
(e.g., crm[0].certReq.certTemplate.subject refers to a subfield | (e.g., crm[0].certReq.certTemplate.subject refers to a subfield | |||
of the first CertReqMsg contained in a request message). | of the first CertReqMsg contained in a request message). | |||
9. All PKI message exchanges in Appendices C.4 to C.6 require a | 9. All PKI message exchanges in Appendices C.4 to C.6 require a | |||
certConf message to be sent by the initiating entity and a | certConf message to be sent by the initiating entity and a | |||
PKIConfirm to be sent by the responding entity. The PKIConfirm | pkiconf message to be sent by the responding entity. The pkiconf | |||
is not included in some of the profiles given since its body is | is not included in some of the profiles given since its body is | |||
NULL and its header contents are clear from the context. Any | NULL and its header contents are clear from the context. Any | |||
authenticated means can be used for the protectionAlg (e.g., | authenticated means can be used for the protectionAlg (e.g., | |||
password-based MAC, if shared secret information is known, or | password-based MAC, if shared secret information is known, or | |||
signature). | signature). | |||
C.2. Algorithm Use Profile | C.2. Algorithm Use Profile | |||
For specifications of algorithm identifiers and respective | For specifications of algorithm identifiers and respective | |||
conventions for conforming implementations, please refer to | conventions for conforming implementations, please refer to | |||
Section 7.1 of CMP Algorithms [RFC9481]. | Section 7.1 of CMP Algorithms [RFC9481]. | |||
C.3. Proof-of-Possession Profile | C.3. POP Profile | |||
POP fields for use (in signature field of pop field of | The table below describes the POP fields for use (in signature field | |||
ProofOfPossession structure) when proving possession of a private | of pop field of ProofOfPossession structure) when proving possession | |||
signing key that corresponds to a public verification key for which a | of a private signing key that corresponds to a public verification | |||
certificate has been requested. | key for which a certificate has been requested. | |||
+=====================+=============+===========================+ | +=====================+=============+===========================+ | |||
| Field | Value | Comment | | | Field | Value | Comment | | |||
+=====================+=============+===========================+ | +=====================+=============+===========================+ | |||
| algorithmIdentifier | MSG_SIG_ALG | only signature protection | | | algorithmIdentifier | MSG_SIG_ALG | only signature protection | | |||
| | | is allowed for this proof | | | | | is allowed for this proof | | |||
+---------------------+-------------+---------------------------+ | +---------------------+-------------+---------------------------+ | |||
| signature | present | bits calculated using | | | signature | present | bits calculated using | | |||
| | | MSG_SIG_ALG | | | | | MSG_SIG_ALG | | |||
+---------------------+-------------+---------------------------+ | +---------------------+-------------+---------------------------+ | |||
Table 2 | Table 2 | |||
Note: For examples of MSG_SIG_ALG OIDs, see Section 3 of CMP | Note: For examples of MSG_SIG_ALG OIDs, see Section 3 of CMP | |||
Algorithms [RFC9481]. | Algorithms [RFC9481]. | |||
Proof-of-possession of a private decryption key that corresponds to a | POP of a private decryption key that corresponds to a public | |||
public encryption key for which a certificate has been requested does | encryption key for which a certificate has been requested does not | |||
not use this profile; the CertHash field of the certConf message is | use this profile; the CertHash field of the certConf message is used | |||
used instead. | instead. | |||
Not every CA/RA will do Proof-of-Possession (of signing key, | Not every CA/RA will do POP (of signing key, decryption key, or key | |||
decryption key, or key agreement key) in the PKIX-CMP in-band | agreement key) in the PKIX-CMP in-band certification request protocol | |||
certification request protocol (how POP is done MAY ultimately be a | (how POP is done MAY ultimately be a policy issue that is made | |||
policy issue that is made explicit for any given CA in its publicized | explicit for any given CA in its publicized Policy OID and | |||
Policy OID and Certification Practice Statement). However, this | Certification Practice Statement). However, this specification | |||
specification mandates that CA/RA entities MUST do POP (by some | mandates that CA/RA entities MUST do POP (by some means) as part of | |||
means) as part of the certification process. All end entities MUST | the certification process. All end entities MUST be prepared to | |||
be prepared to provide POP (i.e., these components of the PKIX-CMP | provide POP (i.e., these components of the PKIX-CMP protocol MUST be | |||
protocol MUST be supported). | supported). | |||
C.4. Initial Registration/Certification (Basic Authenticated Scheme) | C.4. Initial Registration/Certification (Basic Authenticated Scheme) | |||
An (uninitialized) end entity requests a (first) certificate from a | An (uninitialized) end entity requests a (first) certificate from a | |||
CA. When the CA responds with a message containing a certificate, | CA. When the CA responds with a message containing a certificate, | |||
the end entity replies with a certificate confirmation. The CA sends | the end entity replies with a certificate confirmation. The CA sends | |||
a PKIConfirm back, closing the transaction. All messages are | a pkiconf message back, closing the transaction. All messages are | |||
authenticated. | authenticated. | |||
This scheme allows the end entity to request certification of a | This scheme allows the end entity to request certification of a | |||
locally generated public key (typically a signature key). The end | locally generated public key (typically a signature key). The end | |||
entity MAY also choose to request the centralized generation and | entity MAY also choose to request the centralized generation and | |||
certification of another key pair (typically an encryption key pair). | certification of another key pair (typically an encryption key pair). | |||
Certification may only be requested for one locally generated public | Certification may only be requested for one locally generated public | |||
key (for more, use separate PKIMessages). | key (for more, use separate PKIMessages). | |||
The end entity MUST support proof-of-possession of the private key | The end entity MUST support POP of the private key associated with | |||
associated with the locally generated public key. | the locally generated public key. | |||
Preconditions: | Preconditions: | |||
1. The end entity can authenticate the CA's signature based on out- | 1. The end entity can authenticate the CA's signature based on out- | |||
of-band means. | of-band means. | |||
2. The end entity and the CA share a symmetric MACing key. | 2. The end entity and the CA share a symmetric MACing key. | |||
Message Flow: | Message Flow: | |||
skipping to change at line 4634 ¶ | skipping to change at line 4627 ¶ | |||
--------------------------------------------------------------------- | --------------------------------------------------------------------- | |||
1 format ir | 1 format ir | |||
2 --> ir --> | 2 --> ir --> | |||
3 handle ir | 3 handle ir | |||
4 format ip | 4 format ip | |||
5 <-- ip <-- | 5 <-- ip <-- | |||
6 handle ip | 6 handle ip | |||
7 format certConf | 7 format certConf | |||
8 --> certConf --> | 8 --> certConf --> | |||
9 handle certConf | 9 handle certConf | |||
10 format PKIConf | 10 format pkiconf | |||
11 <-- PKIConf <-- | 11 <-- pkiconf <-- | |||
12 handle PKIConf | 12 handle pkiconf | |||
For this profile, we mandate that the end entity MUST include all | For this profile, we mandate that the end entity MUST include all | |||
(i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI | (i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI | |||
(CA) MUST produce a single response PKIMessage that contains the | (CA) MUST produce a single response PKIMessage that contains the | |||
complete response (i.e., including the OPTIONAL second key pair, if | complete response (i.e., including the OPTIONAL second key pair, if | |||
it was requested and if centralized key generation is supported). | it was requested and if centralized key generation is supported). | |||
For simplicity, we also mandate that this message MUST be the final | For simplicity, we also mandate that this message MUST be the final | |||
one (i.e., no use of "waiting" status value). | one (i.e., no use of "waiting" status value). | |||
The end entity has an out-of-band interaction with the CA/RA. This | The end entity has an out-of-band interaction with the CA/RA. This | |||
transaction established the shared secret, the referenceNumber and | transaction established the shared secret, the referenceNumber, and | |||
OPTIONALLY the distinguished name used for both the sender and | optionally the DN used for both the sender and subject name in the | |||
subject name in the certificate template. See Section 8.7 for | certificate template. See Section 8.7 for security considerations on | |||
security considerations on quality of shared secret information. | quality of shared secret information. | |||
Initialization Request -- ir | Initialization Request -- ir | |||
Field Value | Field Value | |||
recipient CA name | recipient CA name | |||
-- the name of the CA who is being asked to produce a certificate | -- the name of the CA who is being asked to produce a certificate | |||
protectionAlg MSG_MAC_ALG | protectionAlg MSG_MAC_ALG | |||
-- only MAC protection is allowed for this request, based | -- only MAC protection is allowed for this request, based | |||
-- on initial authentication key | -- on initial authentication key | |||
skipping to change at line 4693 ¶ | skipping to change at line 4686 ¶ | |||
crm[0].certReq. fixed value of zero | crm[0].certReq. fixed value of zero | |||
certReqId | certReqId | |||
-- this is the index of the template within the message | -- this is the index of the template within the message | |||
crm[0].certReq present | crm[0].certReq present | |||
certTemplate | certTemplate | |||
-- MUST include subject public key value, otherwise unconstrained | -- MUST include subject public key value, otherwise unconstrained | |||
crm[0].pop... optionally present if public key | crm[0].pop... optionally present if public key | |||
POPOSigningKey from crm[0].certReq.certTemplate is | POPOSigningKey from crm[0].certReq.certTemplate is | |||
a signing key | a signing key | |||
-- proof-of-possession MAY be required in this exchange | -- POP MAY be required in this exchange | |||
-- (see Appendix D.3 for details) | -- (see Appendix D.3 for details) | |||
crm[0].certReq. optionally present | crm[0].certReq. optionally present | |||
controls.archiveOptions | controls.archiveOptions | |||
-- the end entity MAY request that the locally generated | -- the end entity MAY request that the locally generated | |||
-- private key be archived | -- private key be archived | |||
crm[0].certReq. optionally present | crm[0].certReq. optionally present | |||
controls.publicationInfo | controls.publicationInfo | |||
-- the end entity MAY ask for publication of resulting cert. | -- the end entity MAY ask for publication of resulting cert. | |||
skipping to change at line 4830 ¶ | skipping to change at line 4823 ¶ | |||
-- the name of the CA who was asked to produce a certificate | -- the name of the CA who was asked to produce a certificate | |||
transactionID present | transactionID present | |||
-- value from corresponding ir and ip messages | -- value from corresponding ir and ip messages | |||
senderNonce present | senderNonce present | |||
-- 128 (pseudo-)random bits | -- 128 (pseudo-)random bits | |||
recipNonce present | recipNonce present | |||
-- value from senderNonce in corresponding ip message | -- value from senderNonce in corresponding ip message | |||
protectionAlg MSG_MAC_ALG | protectionAlg MSG_MAC_ALG | |||
-- only MAC protection is allowed for this message. The | -- only MAC protection is allowed for this message. The | |||
-- MAC is based on the initial authentication key shared | -- MAC is based on the initial authentication key shared | |||
-- between the EE and the CA. | -- between the end entity and the CA. | |||
senderKID referenceNum | senderKID referenceNum | |||
-- the reference number that the CA has previously issued | -- the reference number that the CA has previously issued | |||
-- to the end entity (together with the MACing key) | -- to the end entity (together with the MACing key) | |||
body certConf | body certConf | |||
-- see Section 5.3.18, "PKI Confirmation Content", for the | -- see Section 5.3.18, "PKI Confirmation Content", for the | |||
-- contents of the certConf fields. | -- contents of the certConf fields. | |||
-- Note: two CertStatus structures are required if both an | -- Note: two CertStatus structures are required if both an | |||
-- encryption and a signing certificate were sent. | -- encryption and a signing certificate were sent. | |||
protection present | protection present | |||
-- bits calculated using MSG_MAC_ALG | -- bits calculated using MSG_MAC_ALG | |||
Confirmation -- PKIConf | Confirmation -- pkiconf | |||
Field Value | Field Value | |||
sender present | sender present | |||
-- same as in ip | -- same as in ip | |||
recipient present | recipient present | |||
-- sender name from certConf | -- sender name from certConf | |||
transactionID present | transactionID present | |||
-- value from certConf message | -- value from certConf message | |||
senderNonce present | senderNonce present | |||
-- 128 (pseudo-)random bits | -- 128 (pseudo-)random bits | |||
recipNonce present | recipNonce present | |||
-- value from senderNonce from certConf message | -- value from senderNonce from certConf message | |||
protectionAlg MSG_MAC_ALG | protectionAlg MSG_MAC_ALG | |||
-- only MAC protection is allowed for this message. | -- only MAC protection is allowed for this message. | |||
senderKID referenceNum | senderKID referenceNum | |||
body PKIConf | body pkiconf | |||
protection present | protection present | |||
-- bits calculated using MSG_MAC_ALG | -- bits calculated using MSG_MAC_ALG | |||
C.5. Certificate Request | C.5. Certificate Request | |||
An (initialized) end entity requests a certificate from a CA (for any | An (initialized) end entity requests a certificate from a CA (for any | |||
reason). When the CA responds with a message containing a | reason). When the CA responds with a message containing a | |||
certificate, the end entity replies with a certificate confirmation. | certificate, the end entity replies with a certificate confirmation. | |||
The CA replies with a PKIConfirm to close the transaction. All | The CA replies with a pkiconf message to close the transaction. All | |||
messages are authenticated. | messages are authenticated. | |||
The profile for this exchange is identical to that given in | The profile for this exchange is identical to that given in | |||
Appendix C.4, with the following exceptions: | Appendix C.4, with the following exceptions: | |||
* sender name SHOULD be present; | * sender name SHOULD be present; | |||
* protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY | * protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY | |||
also be supported) in request, response, certConfirm, and | also be supported) in request, response, certConf, and pkiconf | |||
PKIConfirm messages; | messages; | |||
* senderKID and recipKID are only present if required for message | * senderKID and recipKID are only present if required for message | |||
verification; | verification; | |||
* body is cr or cp; | * body is cr or cp; | |||
* body may contain one or two CertReqMsg structures, but either | * body may contain one or two CertReqMsg structures, but either | |||
CertReqMsg may be used to request certification of a locally | CertReqMsg may be used to request certification of a locally | |||
generated public key or a centrally generated public key (i.e., | generated public key or a centrally generated public key (i.e., | |||
the position-dependence requirement of Appendix C.4 is removed); | the position-dependence requirement of Appendix C.4 is removed); | |||
skipping to change at line 4909 ¶ | skipping to change at line 4902 ¶ | |||
An (initialized) end entity requests a certificate from a CA (to | An (initialized) end entity requests a certificate from a CA (to | |||
update the key pair and/or corresponding certificate that it already | update the key pair and/or corresponding certificate that it already | |||
possesses). When the CA responds with a message containing a | possesses). When the CA responds with a message containing a | |||
certificate, the end entity replies with a certificate confirmation. | certificate, the end entity replies with a certificate confirmation. | |||
The CA replies with a PKIConfirm to close the transaction. All | The CA replies with a PKIConfirm to close the transaction. All | |||
messages are authenticated. | messages are authenticated. | |||
The profile for this exchange is identical to that given in | The profile for this exchange is identical to that given in | |||
Appendix C.4, with the following exceptions: | Appendix C.4, with the following exceptions: | |||
1. sender name SHOULD be present; | * sender name SHOULD be present; | |||
2. protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY | * protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY | |||
also be supported) in request, response, certConfirm, and | also be supported) in request, response, certConfirm, and | |||
PKIConfirm messages; | PKIConfirm messages; | |||
3. senderKID and recipKID are only present if required for message | * senderKID and recipKID are only present if required for message | |||
verification; | verification; | |||
4. body is kur or kup; | * body is kur or kup; | |||
5. body may contain one or two CertReqMsg structures, but either | * body may contain one or two CertReqMsg structures, but either | |||
CertReqMsg may be used to request certification of a locally | CertReqMsg may be used to request certification of a locally | |||
generated public key or a centrally generated public key | generated public key or a centrally generated public key (i.e.,the | |||
(i.e.,the position-dependence requirement of Appendix C.4 is | position-dependence requirement of Appendix C.4 is removed); | |||
removed); | ||||
6. protection bits are calculated according to the protectionAlg | * protection bits are calculated according to the protectionAlg | |||
field; and | field; and | |||
7. regCtrl OldCertId SHOULD be used (unless it is clear to both the | * regCtrl OldCertId SHOULD be used (unless it is clear to both the | |||
sender and receiver -- by means not specified in this document -- | sender and receiver -- by means not specified in this document -- | |||
that it is not needed). | that it is not needed). | |||
Appendix D. PKI Management Message Profiles (OPTIONAL) | Appendix D. PKI Management Message Profiles (OPTIONAL) | |||
This appendix contains detailed profiles for those PKIMessages that | This appendix contains detailed profiles for those PKIMessages that | |||
MAY be supported by implementations. | MAY be supported by implementations. | |||
Profiles for the PKIMessages used in the following PKI management | Profiles for the PKIMessages used in the following PKI management | |||
operations are provided: | operations are provided: | |||
* root CA key update | * root CA key update | |||
skipping to change at line 4969 ¶ | skipping to change at line 4961 ¶ | |||
D.1. General Rules for Interpretation of These Profiles | D.1. General Rules for Interpretation of These Profiles | |||
Identical to Appendix C.1. | Identical to Appendix C.1. | |||
D.2. Algorithm Use Profile | D.2. Algorithm Use Profile | |||
Identical to Appendix C.2. | Identical to Appendix C.2. | |||
D.3. Self-Signed Certificates | D.3. Self-Signed Certificates | |||
Profile of how a certificate structure may be "self-signed". These | The table below is a profile of how a certificate structure may be | |||
structures are used for distribution of new root CA public keys. | "self-signed". These structures are used for distribution of new | |||
This can occur in one of three ways (see Section 4.4 above for a | root CA public keys. This can occur in one of three ways (see | |||
description of the use of these structures): | Section 4.4 above for a description of the use of these structures): | |||
+============+=============================================+ | +============+=============================================+ | |||
| Type | Function | | | Type | Function | | |||
+============+=============================================+ | +============+=============================================+ | |||
| newWithNew | a "self-signed" certificate; the contained | | | newWithNew | a "self-signed" certificate; the contained | | |||
| | public key MUST be usable to verify the | | | | public key MUST be usable to verify the | | |||
| | signature (though this provides only | | | | signature (though this provides only | | |||
| | integrity and no authentication whatsoever) | | | | integrity and no authentication whatsoever) | | |||
+------------+---------------------------------------------+ | +------------+---------------------------------------------+ | |||
| oldWithNew | previous root CA public key signed with new | | | oldWithNew | previous root CA public key signed with new | | |||
skipping to change at line 5000 ¶ | skipping to change at line 4992 ¶ | |||
A newWithNew certificate (including relevant extensions) must contain | A newWithNew certificate (including relevant extensions) must contain | |||
"sensible" values for all fields. For example, when present, | "sensible" values for all fields. For example, when present, | |||
subjectAltName MUST be identical to issuerAltName, and, when present, | subjectAltName MUST be identical to issuerAltName, and, when present, | |||
keyIdentifiers must contain appropriate values, et cetera. | keyIdentifiers must contain appropriate values, et cetera. | |||
D.4. Root CA Key Update | D.4. Root CA Key Update | |||
A root CA updates its key pair. It then produces a CA key update | A root CA updates its key pair. It then produces a CA key update | |||
announcement message that can be made available (via some transport | announcement message that can be made available (via some transport | |||
mechanism) to the relevant end entities. A confirmation message is | mechanism) to the relevant entities. A confirmation message is not | |||
not required from the end entities. | required from the end entities. | |||
ckuann message: | ckuann message: | |||
+============+================================+=====================+ | +============+================================+=====================+ | |||
| Field | Value | Comment | | | Field | Value | Comment | | |||
+============+================================+=====================+ | +============+================================+=====================+ | |||
| sender | CA name CA name | | | | sender | CA name CA name | | | |||
+------------+--------------------------------+---------------------+ | +------------+--------------------------------+---------------------+ | |||
| body | ckuann(RootCaKeyUpdateContent) | | | | body | ckuann(RootCaKeyUpdateContent) | | | |||
+------------+--------------------------------+---------------------+ | +------------+--------------------------------+---------------------+ | |||
skipping to change at line 5119 ¶ | skipping to change at line 5111 ¶ | |||
-- the CA MAY provide a copy of a complete CRL (i.e., | -- the CA MAY provide a copy of a complete CRL (i.e., | |||
-- fullest possible one) | -- fullest possible one) | |||
protection present | protection present | |||
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG | -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG | |||
extraCerts optionally present | extraCerts optionally present | |||
-- can be used to send some certificates to the end | -- can be used to send some certificates to the end | |||
-- entity. An RA MAY add its certificate here. | -- entity. An RA MAY add its certificate here. | |||
D.6. Cross-Certification Request/Response (1-way) | D.6. Cross-Certification Request/Response (1-way) | |||
Creation of a single cross-certificate (i.e., not two at once). The | This section describes the creation of a single cross-certificate | |||
requesting CA MAY choose who is responsible for publication of the | (i.e., not two at once). The requesting CA MAY choose who is | |||
cross-certificate created by the responding CA through use of the | responsible for publication of the cross-certificate created by the | |||
PKIPublicationInfo control. | responding CA through use of the PKIPublicationInfo control. | |||
Preconditions: | Preconditions: | |||
1. Responding CA can verify the origin of the request (possibly | 1. Responding CA can verify the origin of the request (possibly | |||
requiring out-of-band means) before processing the request. | requiring out-of-band means) before processing the request. | |||
2. Requesting CA can authenticate the authenticity of the origin of | 2. Requesting CA can authenticate the authenticity of the origin of | |||
the response (possibly requiring out-of-band means) before | the response (possibly requiring out-of-band means) before | |||
processing the response. | processing the response. | |||
skipping to change at line 5199 ¶ | skipping to change at line 5191 ¶ | |||
validity present | validity present | |||
-- MUST be completely specified (i.e., both fields present) | -- MUST be completely specified (i.e., both fields present) | |||
issuer present | issuer present | |||
-- may be NULL-DN only if issuerAltNames extension value proposed | -- may be NULL-DN only if issuerAltNames extension value proposed | |||
publicKey present | publicKey present | |||
-- the key to be certified (which must be for a signing algorithm) | -- the key to be certified (which must be for a signing algorithm) | |||
extensions optionally present | extensions optionally present | |||
-- a requesting CA must propose values for all extensions | -- a requesting CA must propose values for all extensions | |||
-- that it requires to be in the cross-certificate | -- that it requires to be in the cross-certificate | |||
POPOSigningKey present | POPOSigningKey present | |||
-- see Appendix C.3: Proof-of-Possession Profile | -- see Appendix C.3: POP Profile | |||
protection present | protection present | |||
-- bits calculated using MSG_SIG_ALG | -- bits calculated using MSG_SIG_ALG | |||
extraCerts optionally present | extraCerts optionally present | |||
-- MAY contain any additional certificates that requester wishes | -- MAY contain any additional certificates that requester wishes | |||
-- to include | -- to include | |||
ccp: | ccp: | |||
Field Value | Field Value | |||
skipping to change at line 5268 ¶ | skipping to change at line 5260 ¶ | |||
extraCerts optionally present | extraCerts optionally present | |||
-- MAY contain any additional certificates that responder wishes | -- MAY contain any additional certificates that responder wishes | |||
-- to include | -- to include | |||
D.7. In-Band Initialization Using External Identity Certificate | D.7. In-Band Initialization Using External Identity Certificate | |||
An (uninitialized) end entity wishes to initialize into the PKI with | An (uninitialized) end entity wishes to initialize into the PKI with | |||
a CA, CA-1. It uses, for authentication purposes, a pre-existing | a CA, CA-1. It uses, for authentication purposes, a pre-existing | |||
identity certificate issued by another (external) CA, CA-X. A trust | identity certificate issued by another (external) CA, CA-X. A trust | |||
relationship must already have been established between CA-1 and CA-X | relationship must already have been established between CA-1 and CA-X | |||
so that CA-1 can validate the EE identity certificate signed by CA-X. | so that CA-1 can validate the end entity identity certificate signed | |||
Furthermore, some mechanism must already have been established within | by CA-X. Furthermore, some mechanism must already have been | |||
the Trusted Execution Environment (TEE), also known as Personal | established within the TEE, also known as PSE, of the end entity that | |||
Security Environment (PSE), of the EE that would allow it to | would allow it to authenticate and verify PKIMessages signed by CA-1 | |||
authenticate and verify PKIMessages signed by CA-1 (as one example, | (as one example, the TEE may contain a certificate issued for the | |||
the TEE may contain a certificate issued for the public key of CA-1, | public key of CA-1, signed by another CA that the end entity trusts | |||
signed by another CA that the EE trusts on the basis of out-of-band | on the basis of out-of-band authentication techniques). | |||
authentication techniques). | ||||
The EE sends an initialization request to start the transaction. | The end entity sends an initialization request to start the | |||
When CA-1 responds with a message containing the new certificate, the | transaction. When CA-1 responds with a message containing the new | |||
end entity replies with a certificate confirmation. CA-1 replies | certificate, the end entity replies with a certificate confirmation. | |||
with a PKIConfirm to close the transaction. All messages are signed | CA-1 replies with a pkiconf message to close the transaction. All | |||
(the EE messages are signed using the private key that corresponds to | messages are signed (the end entity messages are signed using the | |||
the public key in its external identity certificate; the CA-1 | private key that corresponds to the public key in its external | |||
messages are signed using the private key that corresponds to the | identity certificate; the CA-1 messages are signed using the private | |||
public key in a certificate that can be chained to a trust anchor in | key that corresponds to the public key in a certificate that can be | |||
the EE's TEE). | chained to a trust anchor in the end entity's TEE). | |||
The profile for this exchange is identical to that given in | The profile for this exchange is identical to that given in | |||
Appendix C.4, with the following exceptions: | Appendix C.4, with the following exceptions: | |||
* the EE and CA-1 do not share a symmetric MACing key (i.e., there | * the end entity and CA-1 do not share a symmetric MACing key (i.e., | |||
is no out-of-band shared secret information between these | there is no out-of-band shared secret information between these | |||
entities); | entities); | |||
* sender name in ir MUST be present (and identical to the subject | * sender name in ir MUST be present (and identical to the subject | |||
name present in the external identity certificate); | name present in the external identity certificate); | |||
* protectionAlg of MSG_SIG_ALG MUST be used in all messages; | * protectionAlg of MSG_SIG_ALG MUST be used in all messages; | |||
* external identity certificate MUST be carried in ir extraCerts | * external identity certificate MUST be carried in ir extraCerts | |||
field | field | |||
skipping to change at line 5327 ¶ | skipping to change at line 5318 ¶ | |||
of a KEM key. There are two cases to distinguish, namely whether the | of a KEM key. There are two cases to distinguish, namely whether the | |||
PKI entity or the PKI management entity owns a KEM key pair. If both | PKI entity or the PKI management entity owns a KEM key pair. If both | |||
sides own KEM key pairs, the flows need to be combined such that for | sides own KEM key pairs, the flows need to be combined such that for | |||
each direction a shared secret key is established. | each direction a shared secret key is established. | |||
In the following message flows, Alice indicates the PKI entity that | In the following message flows, Alice indicates the PKI entity that | |||
uses a KEM key pair for message authentication and Bob provides the | uses a KEM key pair for message authentication and Bob provides the | |||
KEM ciphertext using Alice's public KEM key, as described in | KEM ciphertext using Alice's public KEM key, as described in | |||
Section 5.1.3.4. | Section 5.1.3.4. | |||
Message Flow when the PKI entity has a KEM key pair and certificate: | ||||
Step# PKI entity PKI management entity | Step# PKI entity PKI management entity | |||
(Alice) (Bob) | (Alice) (Bob) | |||
--------------------------------------------------------------------- | --------------------------------------------------------------------- | |||
1 format unprotected genm | 1 format unprotected genm | |||
of type | of type | |||
KemCiphertextInfo | KemCiphertextInfo | |||
without value, and | without value, and | |||
KEM certificate in | KEM certificate in | |||
extraCerts | extraCerts | |||
2 --> genm --> | 2 --> genm --> | |||
skipping to change at line 5371 ¶ | skipping to change at line 5360 ¶ | |||
available key material | available key material | |||
14 <-- response <-- | 14 <-- response <-- | |||
15 verify protection | 15 verify protection | |||
provided by the | provided by the | |||
PKI management entity | PKI management entity | |||
16 Further messages of this PKI management operation | 16 Further messages of this PKI management operation | |||
can be exchanged with MAC-based protection by the PKI | can be exchanged with MAC-based protection by the PKI | |||
entity using the established shared secret key (ssk) | entity using the established shared secret key (ssk) | |||
Figure 3: Message Flow When the PKI Entity Has a KEM Key Pair | Figure 3: Message Flow When the PKI Entity Has a KEM Key Pair and | |||
Certificate | ||||
Message Flow when the PKI entity knows that the PKI management entity | ||||
uses a KEM key pair and has the authentic public key: | ||||
Step# PKI entity PKI management entity | Step# PKI entity PKI management entity | |||
(Bob) (Alice) | (Bob) (Alice) | |||
--------------------------------------------------------------------- | --------------------------------------------------------------------- | |||
1 perform KEM Encapsulate | 1 perform KEM Encapsulate | |||
2 format request providing | 2 format request providing | |||
KEM ciphertext in | KEM ciphertext in | |||
generalInfo of type | generalInfo of type | |||
KemCiphertextInfo, | KemCiphertextInfo, | |||
and with protection | and with protection | |||
skipping to change at line 5415 ¶ | skipping to change at line 5402 ¶ | |||
Figure 4: Message Flow When the PKI Entity Knows That the PKI | Figure 4: Message Flow When the PKI Entity Knows That the PKI | |||
Management Entity Uses a KEM Key Pair and Has the Authentic | Management Entity Uses a KEM Key Pair and Has the Authentic | |||
Public Key | Public Key | |||
Note: Figure 4 describes the situation where KEM-based message | Note: Figure 4 describes the situation where KEM-based message | |||
protection may not require more than one message exchange. In this | protection may not require more than one message exchange. In this | |||
case, the transactionID MUST also be used by the PKI entity (Bob) to | case, the transactionID MUST also be used by the PKI entity (Bob) to | |||
ensure domain separation between different PKI management operations. | ensure domain separation between different PKI management operations. | |||
Message Flow when the PKI entity does not know that the PKI | ||||
management entity uses a KEM key pair: | ||||
Step# PKI entity PKI management entity | Step# PKI entity PKI management entity | |||
(Bob) (Alice) | (Bob) (Alice) | |||
--------------------------------------------------------------------- | --------------------------------------------------------------------- | |||
1 format request with | 1 format request with | |||
protection depending | protection depending | |||
on available key | on available key | |||
material | material | |||
2 --> request --> | 2 --> request --> | |||
3 format unprotected error | 3 format unprotected error | |||
with status "rejection" | with status "rejection" | |||
skipping to change at line 5447 ¶ | skipping to change at line 5431 ¶ | |||
Figure 5: Message Flow When the PKI Entity Does Not Know That the PKI | Figure 5: Message Flow When the PKI Entity Does Not Know That the PKI | |||
Management Entity Uses a KEM Key Pair | Management Entity Uses a KEM Key Pair | |||
Appendix F. Compilable ASN.1 Definitions | Appendix F. Compilable ASN.1 Definitions | |||
This section contains the updated 2002 ASN.1 module from [RFC5912], | This section contains the updated 2002 ASN.1 module from [RFC5912], | |||
which was updated in [RFC9480]. This module replaces the module in | which was updated in [RFC9480]. This module replaces the module in | |||
Section 9 of [RFC5912]. The module contains those changes to the | Section 9 of [RFC5912]. The module contains those changes to the | |||
normative ASN.1 module from Appendix F of [RFC4210] that were | normative ASN.1 module from Appendix F of [RFC4210] that were | |||
specified in [RFC9480], as well as changes made in this document. | specified in [RFC9480], as well as changes made in this document. | |||
This module makes reference to ASN.1 structures defined in [RFC6268], | ||||
as well as the UTF-8 encoding defined in [RFC3629]. | ||||
PKIXCMP-2023 | PKIXCMP-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-cmp2023-02(116) } | id-mod-cmp2023-02(116) } | |||
DEFINITIONS EXPLICIT TAGS ::= | DEFINITIONS EXPLICIT TAGS ::= | |||
BEGIN | BEGIN | |||
IMPORTS | IMPORTS | |||
AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE | AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE | |||
skipping to change at line 5590 ¶ | skipping to change at line 5576 ¶ | |||
-- believes that the transport will be "suitable", i.e., | -- believes that the transport will be "suitable", i.e., | |||
-- that the time will still be meaningful upon receipt) | -- that the time will still be meaningful upon receipt) | |||
protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} | protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} | |||
OPTIONAL, | OPTIONAL, | |||
-- algorithm used for calculation of protection bits | -- algorithm used for calculation of protection bits | |||
senderKID [2] KeyIdentifier OPTIONAL, | senderKID [2] KeyIdentifier OPTIONAL, | |||
recipKID [3] KeyIdentifier OPTIONAL, | recipKID [3] KeyIdentifier OPTIONAL, | |||
-- to identify specific keys used for protection | -- to identify specific keys used for protection | |||
transactionID [4] OCTET STRING OPTIONAL, | transactionID [4] OCTET STRING OPTIONAL, | |||
-- identifies the transaction, i.e., this will be the same in | -- identifies the transaction, i.e., this will be the same in | |||
-- corresponding request, response, certConf, and PKIConf | -- corresponding request, response, certConf, and pkiconf | |||
-- messages | -- messages | |||
senderNonce [5] OCTET STRING OPTIONAL, | senderNonce [5] OCTET STRING OPTIONAL, | |||
recipNonce [6] OCTET STRING OPTIONAL, | recipNonce [6] OCTET STRING OPTIONAL, | |||
-- nonces used to provide replay protection, senderNonce | -- nonces used to provide replay protection, senderNonce | |||
-- is inserted by the creator of this message; recipNonce | -- is inserted by the creator of this message; recipNonce | |||
-- is a nonce previously inserted in a related message by | -- is a nonce previously inserted in a related message by | |||
-- the intended recipient of this message. | -- the intended recipient of this message. | |||
freeText [7] PKIFreeText OPTIONAL, | freeText [7] PKIFreeText OPTIONAL, | |||
-- this may be used to indicate context-specific instructions | -- this may be used to indicate context-specific instructions | |||
-- (this field is intended for human consumption) | -- (this field is intended for human consumption) | |||
skipping to change at line 5654 ¶ | skipping to change at line 5640 ¶ | |||
body PKIBody } | body PKIBody } | |||
id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) | id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) | |||
usa(840) nt(113533) nsn(7) algorithms(66) 13 } | usa(840) nt(113533) nsn(7) algorithms(66) 13 } | |||
PBMParameter ::= SEQUENCE { | PBMParameter ::= SEQUENCE { | |||
salt OCTET STRING, | salt OCTET STRING, | |||
-- Note: Implementations MAY wish to limit acceptable sizes | -- Note: Implementations MAY wish to limit acceptable sizes | |||
-- of this string to values appropriate for their environment | -- of this string to values appropriate for their environment | |||
-- in order to reduce the risk of denial-of-service attacks. | -- in order to reduce the risk of denial-of-service attacks. | |||
owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, | owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, | |||
-- AlgId for the One-Way Function | -- AlgId for the OWF | |||
iterationCount INTEGER, | iterationCount INTEGER, | |||
-- number of times the OWF is applied | -- number of times the OWF is applied | |||
-- Note: Implementations MAY wish to limit acceptable sizes | -- Note: Implementations MAY wish to limit acceptable sizes | |||
-- of this integer to values appropriate for their environment | -- of this integer to values appropriate for their environment | |||
-- in order to reduce the risk of denial-of-service attacks. | -- in order to reduce the risk of denial-of-service attacks. | |||
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} | mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} | |||
-- AlgId of the Message Authentication Code algorithm | -- AlgId of the MAC algorithm | |||
} | } | |||
id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) | id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) | |||
usa(840) nt(113533) nsn(7) algorithms(66) 30 } | usa(840) nt(113533) nsn(7) algorithms(66) 30 } | |||
DHBMParameter ::= SEQUENCE { | DHBMParameter ::= SEQUENCE { | |||
owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, | owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, | |||
-- AlgId for a One-Way Function | -- AlgId for an OWF | |||
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} | mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} | |||
-- AlgId of the Message Authentication Code algorithm | -- AlgId of the MAC algorithm | |||
} | } | |||
-- id-KemBasedMac and KemBMParameter were added in [RFC9810] | -- id-KemBasedMac and KemBMParameter were added in [RFC9810] | |||
id-KemBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) | id-KemBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) | |||
usa(840) nt(113533) nsn(7) algorithms(66) 16 } | usa(840) nt(113533) nsn(7) algorithms(66) 16 } | |||
KemBMParameter ::= SEQUENCE { | KemBMParameter ::= SEQUENCE { | |||
kdf AlgorithmIdentifier{KEY-DERIVATION, {...}}, | kdf AlgorithmIdentifier{KEY-DERIVATION, {...}}, | |||
-- AlgId of the Key Derivation Function algorithm | -- AlgId of the Key Derivation Function algorithm | |||
kemContext [0] OCTET STRING OPTIONAL, | kemContext [0] OCTET STRING OPTIONAL, | |||
-- MAY contain additional algorithm-specific context information | -- MAY contain additional algorithm-specific context information | |||
len INTEGER (1..MAX), | len INTEGER (1..MAX), | |||
-- Defines the length of the keying material output of the KDF | -- Defines the length of the keying material output of the KDF | |||
-- SHOULD be the maximum key length of the MAC function | -- SHOULD be the maximum key length of the MAC function | |||
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} | mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} | |||
-- AlgId of the Message Authentication Code algorithm | -- AlgId of the MAC algorithm | |||
} | } | |||
PKIStatus ::= INTEGER { | PKIStatus ::= INTEGER { | |||
accepted (0), | accepted (0), | |||
-- you got exactly what you asked for | -- you got exactly what you asked for | |||
grantedWithMods (1), | grantedWithMods (1), | |||
-- you got something like what you asked for; the | -- you got something like what you asked for; the | |||
-- requester is responsible for ascertaining the differences | -- requester is responsible for ascertaining the differences | |||
rejection (2), | rejection (2), | |||
-- you don't get it, more information elsewhere in the message | -- you don't get it, more information elsewhere in the message | |||
skipping to change at line 5738 ¶ | skipping to change at line 5724 ¶ | |||
-- the data submitted has the wrong format | -- the data submitted has the wrong format | |||
wrongAuthority (6), | wrongAuthority (6), | |||
-- the authority indicated in the request is different from the | -- the authority indicated in the request is different from the | |||
-- one creating the response token | -- one creating the response token | |||
incorrectData (7), | incorrectData (7), | |||
-- the requester's data is incorrect (for notary services) | -- the requester's data is incorrect (for notary services) | |||
missingTimeStamp (8), | missingTimeStamp (8), | |||
-- when the timestamp is missing but should be there | -- when the timestamp is missing but should be there | |||
-- (by policy) | -- (by policy) | |||
badPOP (9), | badPOP (9), | |||
-- the proof-of-possession failed | -- the POP failed | |||
certRevoked (10), | certRevoked (10), | |||
-- the certificate has already been revoked | -- the certificate has already been revoked | |||
certConfirmed (11), | certConfirmed (11), | |||
-- the certificate has already been confirmed | -- the certificate has already been confirmed | |||
wrongIntegrity (12), | wrongIntegrity (12), | |||
-- KEM ciphertext missing for MAC-based protection of response, | -- KEM ciphertext missing for MAC-based protection of response, | |||
-- or not valid integrity of message received (password based | -- or not valid integrity of message received (password based | |||
-- instead of signature or vice versa) | -- instead of signature or vice versa) | |||
badRecipientNonce (13), | badRecipientNonce (13), | |||
-- not valid recipient nonce, either missing or wrong value | -- not valid recipient nonce, either missing or wrong value | |||
skipping to change at line 5811 ¶ | skipping to change at line 5797 ¶ | |||
-- encryptedRand was added in [RFC9810] | -- encryptedRand was added in [RFC9810] | |||
Challenge ::= SEQUENCE { | Challenge ::= SEQUENCE { | |||
owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} | owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} | |||
OPTIONAL, | OPTIONAL, | |||
-- MUST be present in the first Challenge; MAY be omitted in | -- MUST be present in the first Challenge; MAY be omitted in | |||
-- any subsequent Challenge in POPODecKeyChallContent (if | -- any subsequent Challenge in POPODecKeyChallContent (if | |||
-- omitted, then the owf used in the immediately preceding | -- omitted, then the owf used in the immediately preceding | |||
-- Challenge is to be used). | -- Challenge is to be used). | |||
witness OCTET STRING, | witness OCTET STRING, | |||
-- the result of applying the one-way function (owf) to a | -- the result of applying the OWF to a | |||
-- randomly generated INTEGER, A. (Note that a different | -- randomly generated INTEGER, A. (Note that a different | |||
-- INTEGER MUST be used for each Challenge.) | -- INTEGER MUST be used for each Challenge.) | |||
challenge OCTET STRING, | challenge OCTET STRING, | |||
-- MUST be used for cmp2000(2) popdecc messages and MUST be | -- MUST be used for cmp2000(2) popdecc messages and MUST be | |||
-- the encryption of Rand (using a mechanism depending on the | -- the encryption of Rand (using a mechanism depending on the | |||
-- private key type). | -- private key type). | |||
-- MUST be an empty OCTET STRING for cmp2021(3) popdecc messages. | -- MUST be an empty OCTET STRING for cmp2021(3) popdecc messages. | |||
-- Note: Using challenge omitting the optional encryptedRand is | -- Note: Using challenge omitting the optional encryptedRand is | |||
-- bit-compatible to the syntax without adding this optional | -- bit-compatible to the syntax without adding this optional | |||
-- field. | -- field. | |||
skipping to change at line 6018 ¶ | skipping to change at line 6004 ¶ | |||
issuer [1] GeneralNames } | issuer [1] GeneralNames } | |||
CRLStatus ::= SEQUENCE { | CRLStatus ::= SEQUENCE { | |||
source CRLSource, | source CRLSource, | |||
thisUpdate Time OPTIONAL } | thisUpdate Time OPTIONAL } | |||
-- KemCiphertextInfo and KemOtherInfo were added in [RFC9810] | -- KemCiphertextInfo and KemOtherInfo were added in [RFC9810] | |||
KemCiphertextInfo ::= SEQUENCE { | KemCiphertextInfo ::= SEQUENCE { | |||
kem AlgorithmIdentifier{KEM-ALGORITHM, {...}}, | kem AlgorithmIdentifier{KEM-ALGORITHM, {...}}, | |||
-- AlgId of the Key Encapsulation Mechanism algorithm | -- AlgId of the KEM algorithm | |||
ct OCTET STRING | ct OCTET STRING | |||
-- Ciphertext output from the Encapsulate function | -- Ciphertext output from the Encapsulate function | |||
} | } | |||
KemOtherInfo ::= SEQUENCE { | KemOtherInfo ::= SEQUENCE { | |||
staticString PKIFreeText, | staticString PKIFreeText, | |||
-- MUST be "CMP-KEM" | -- MUST be "CMP-KEM" | |||
transactionID OCTET STRING, | transactionID OCTET STRING, | |||
-- MUST contain the values from the message previously received | -- MUST contain the values from the message previously received | |||
-- containing the ciphertext (ct) in KemCiphertextInfo | -- containing the ciphertext (ct) in KemCiphertextInfo | |||
skipping to change at line 6129 ¶ | skipping to change at line 6115 ¶ | |||
-- id-it OBJECT IDENTIFIER ::= {id-pkix 4} | -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} | |||
-- | -- | |||
-- | -- | |||
-- This construct MAY also be used to define new PKIX Certificate | -- This construct MAY also be used to define new PKIX Certificate | |||
-- Management Protocol request and response messages or | -- Management Protocol request and response messages or | |||
-- general-purpose (e.g., announcement) messages for future needs | -- general-purpose (e.g., announcement) messages for future needs | |||
-- or for specific environments. | -- or for specific environments. | |||
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue | GenMsgContent ::= SEQUENCE OF InfoTypeAndValue | |||
-- May be sent by EE, RA, or CA (depending on message content). | -- May be sent by end entity, RA, or CA (depending on message | |||
-- The OPTIONAL infoValue parameter of InfoTypeAndValue will | -- content). The OPTIONAL infoValue parameter of InfoTypeAndValue | |||
-- typically be omitted for some of the examples given above. | -- will typically be omitted for some of the examples given above. | |||
-- The receiver is free to ignore any contained OIDs that it | -- The receiver is free to ignore any contained OIDs that it | |||
-- does not recognize. If sent from EE to CA, the empty set | -- does not recognize. If sent from end entity to CA, the empty set | |||
-- indicates that the CA may send | -- indicates that the CA may send | |||
-- any/all information that it wishes. | -- any/all information that it wishes. | |||
GenRepContent ::= SEQUENCE OF InfoTypeAndValue | GenRepContent ::= SEQUENCE OF InfoTypeAndValue | |||
-- The receiver MAY ignore any contained OIDs that it does not | -- The receiver MAY ignore any contained OIDs that it does not | |||
-- recognize. | -- recognize. | |||
ErrorMsgContent ::= SEQUENCE { | ErrorMsgContent ::= SEQUENCE { | |||
pKIStatusInfo PKIStatusInfo, | pKIStatusInfo PKIStatusInfo, | |||
errorCode INTEGER OPTIONAL, | errorCode INTEGER OPTIONAL, | |||
skipping to change at line 6173 ¶ | skipping to change at line 6159 ¶ | |||
PollReqContent ::= SEQUENCE OF SEQUENCE { | PollReqContent ::= SEQUENCE OF SEQUENCE { | |||
certReqId INTEGER } | certReqId INTEGER } | |||
PollRepContent ::= SEQUENCE OF SEQUENCE { | PollRepContent ::= SEQUENCE OF SEQUENCE { | |||
certReqId INTEGER, | certReqId INTEGER, | |||
checkAfter INTEGER, -- time in seconds | checkAfter INTEGER, -- time in seconds | |||
reason PKIFreeText OPTIONAL } | reason PKIFreeText OPTIONAL } | |||
-- | -- | |||
-- Extended key usage extension for PKI entities used in CMP | -- EKU extension for PKI entities used in CMP | |||
-- operations, added due to the changes made in [RFC9480] | -- operations, added due to the changes made in [RFC9480] | |||
-- The EKUs for the CA and RA are reused from CMC, as defined in | -- The EKUs for the CA and RA are reused from CMC, as defined in | |||
-- [RFC6402] | -- [RFC6402] | |||
-- | -- | |||
-- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } | -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } | |||
-- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } | -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } | |||
id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } | id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } | |||
END | END | |||
End of changes. 219 change blocks. | ||||
666 lines changed or deleted | 652 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |