draft-ietf-lamps-lightweight-cmp-profile-11.txt   draft-ietf-lamps-lightweight-cmp-profile-12.txt 
LAMPS Working Group H. Brockhaus, Ed. LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft D. von Oheimb Internet-Draft D. von Oheimb
Intended status: Standards Track S. Fries Intended status: Standards Track S. Fries
Expires: 17 October 2022 Siemens Expires: 14 November 2022 Siemens
15 April 2022 13 May 2022
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-11 draft-ietf-lamps-lightweight-cmp-profile-12
Abstract Abstract
This document aims at simple, interoperable, and automated PKI This document aims at simple, interoperable, and automated PKI
management operations covering typical use cases of industrial and management operations covering typical use cases of industrial and
IoT scenarios. This is achieved by profiling the Certificate IoT scenarios. This is achieved by profiling the Certificate
Management Protocol (CMP), the related Certificate Request Message Management Protocol (CMP), the related Certificate Request Message
Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
but sufficiently detailed and self-contained way. To make secure but sufficiently detailed and self-contained way. To make secure
certificate management for simple scenarios and constrained devices certificate management for simple scenarios and constrained devices
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 October 2022. This Internet-Draft will expire on 14 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 49 skipping to change at page 2, line 49
3.6.4. PKIStatusInfo and Error Messages . . . . . . . . . . 23 3.6.4. PKIStatusInfo and Error Messages . . . . . . . . . . 23
4. PKI Management Operations . . . . . . . . . . . . . . . . . . 25 4. PKI Management Operations . . . . . . . . . . . . . . . . . . 25
4.1. Enrolling End Entities . . . . . . . . . . . . . . . . . 27 4.1. Enrolling End Entities . . . . . . . . . . . . . . . . . 27
4.1.1. Enrolling an End Entity to a New PKI . . . . . . . . 28 4.1.1. Enrolling an End Entity to a New PKI . . . . . . . . 28
4.1.2. Enrolling an End Entity to a Known PKI . . . . . . . 34 4.1.2. Enrolling an End Entity to a Known PKI . . . . . . . 34
4.1.3. Updating a Valid Certificate . . . . . . . . . . . . 35 4.1.3. Updating a Valid Certificate . . . . . . . . . . . . 35
4.1.4. Enrolling an End Entity Using a PKCS#10 Request . . . 36 4.1.4. Enrolling an End Entity Using a PKCS#10 Request . . . 36
4.1.5. Using MAC-Based Protection for Enrollment . . . . . . 38 4.1.5. Using MAC-Based Protection for Enrollment . . . . . . 38
4.1.6. Adding Central Key Pair Generation to Enrollment . . 39 4.1.6. Adding Central Key Pair Generation to Enrollment . . 39
4.1.6.1. Using Key Agreement Key Management Technique . . 45 4.1.6.1. Using Key Agreement Key Management Technique . . 45
4.1.6.2. Using Key Transport Key Managemen Technique . . . 46 4.1.6.2. Using Key Transport Key Management Technique . . 46
4.1.6.3. Using Password-Based Key Management Technique . . 47 4.1.6.3. Using Password-Based Key Management Technique . . 47
4.2. Revoking a Certificate . . . . . . . . . . . . . . . . . 48 4.2. Revoking a Certificate . . . . . . . . . . . . . . . . . 48
4.3. Support Messages . . . . . . . . . . . . . . . . . . . . 50 4.3. Support Messages . . . . . . . . . . . . . . . . . . . . 50
4.3.1. Get CA Certificates . . . . . . . . . . . . . . . . . 53 4.3.1. Get CA Certificates . . . . . . . . . . . . . . . . . 53
4.3.2. Get Root CA Certificate Update . . . . . . . . . . . 53 4.3.2. Get Root CA Certificate Update . . . . . . . . . . . 53
4.3.3. Get Certificate Request Template . . . . . . . . . . 55 4.3.3. Get Certificate Request Template . . . . . . . . . . 55
4.3.4. CRL Update Retrieval . . . . . . . . . . . . . . . . 57 4.3.4. CRL Update Retrieval . . . . . . . . . . . . . . . . 57
4.4. Handling Delayed Delivery . . . . . . . . . . . . . . . . 59 4.4. Handling Delayed Delivery . . . . . . . . . . . . . . . . 59
5. PKI Management Entity Operations . . . . . . . . . . . . . . 64 5. PKI Management Entity Operations . . . . . . . . . . . . . . 64
5.1. Responding to Requests . . . . . . . . . . . . . . . . . 64 5.1. Responding to Requests . . . . . . . . . . . . . . . . . 64
skipping to change at page 3, line 30 skipping to change at page 3, line 30
5.2.2.2. Batching Messages . . . . . . . . . . . . . . . . 71 5.2.2.2. Batching Messages . . . . . . . . . . . . . . . . 71
5.2.3. Replacing Protection . . . . . . . . . . . . . . . . 73 5.2.3. Replacing Protection . . . . . . . . . . . . . . . . 73
5.2.3.1. Not Changing Proof-of-Possession . . . . . . . . 73 5.2.3.1. Not Changing Proof-of-Possession . . . . . . . . 73
5.2.3.2. Using raVerified . . . . . . . . . . . . . . . . 74 5.2.3.2. Using raVerified . . . . . . . . . . . . . . . . 74
5.3. Acting on Behalf of other PKI Entities . . . . . . . . . 74 5.3. Acting on Behalf of other PKI Entities . . . . . . . . . 74
5.3.1. Requesting a Certificate . . . . . . . . . . . . . . 75 5.3.1. Requesting a Certificate . . . . . . . . . . . . . . 75
5.3.2. Revoking a Certificate . . . . . . . . . . . . . . . 75 5.3.2. Revoking a Certificate . . . . . . . . . . . . . . . 75
6. CMP Message Transfer Mechanisms . . . . . . . . . . . . . . . 76 6. CMP Message Transfer Mechanisms . . . . . . . . . . . . . . . 76
6.1. HTTP Transfer . . . . . . . . . . . . . . . . . . . . . . 77 6.1. HTTP Transfer . . . . . . . . . . . . . . . . . . . . . . 77
6.2. CoAP Transfer . . . . . . . . . . . . . . . . . . . . . . 79 6.2. CoAP Transfer . . . . . . . . . . . . . . . . . . . . . . 79
6.3. Piggybacking on other Reliable Transfer . . . . . . . . . 81 6.3. Piggybacking on Other Reliable Transfer . . . . . . . . . 81
6.4. Offline Transfer . . . . . . . . . . . . . . . . . . . . 81 6.4. Offline Transfer . . . . . . . . . . . . . . . . . . . . 81
6.4.1. File-Based Transfer . . . . . . . . . . . . . . . . . 82 6.4.1. File-Based Transfer . . . . . . . . . . . . . . . . . 82
6.4.2. Other Asynchronous Transfer Protocols . . . . . . . . 82 6.4.2. Other Asynchronous Transfer Protocols . . . . . . . . 82
7. Conformance Requirements . . . . . . . . . . . . . . . . . . 82 7. Conformance Requirements . . . . . . . . . . . . . . . . . . 82
7.1. PKI Management Operations . . . . . . . . . . . . . . . . 82 7.1. PKI Management Operations . . . . . . . . . . . . . . . . 82
7.2. Message Transfer . . . . . . . . . . . . . . . . . . . . 85 7.2. Message Transfer . . . . . . . . . . . . . . . . . . . . 85
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
9. Security Considerations . . . . . . . . . . . . . . . . . . . 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
skipping to change at page 39, line 29 skipping to change at page 39, line 29
implementation which PKI management entity will act as Key Generation implementation which PKI management entity will act as Key Generation
Authority (KGA) and perform the key generation. This PKI management Authority (KGA) and perform the key generation. This PKI management
entity MUST use a certificate containing the additional extended key entity MUST use a certificate containing the additional extended key
usage extension id-kp-cmKGA in order to be accepted by the EE as a usage extension id-kp-cmKGA in order to be accepted by the EE as a
legitimate key generation authority. legitimate key generation authority.
As described in Section 5.3.1, the KGA can use one of the PKI As described in Section 5.3.1, the KGA can use one of the PKI
management operations described in the sections above to request the management operations described in the sections above to request the
certificate for this key pair on behalf of the EE. certificate for this key pair on behalf of the EE.
Note: When performing central key generation for a certificate
update, the KGA cannot use the old EE credentials for protection.
Therefore, the PKI management operation described in Section 4.1.2
SHOULD be used instead of Section 4.1.3 to request a certificate for
the newly generated key pair on behalf of the EE.
Generally speaking, in machine-to-machine scenarios it is strongly Generally speaking, in machine-to-machine scenarios it is strongly
preferable to generate public-private key pairs locally at the EE. preferable to generate public-private key pairs locally at the EE.
Together with proof-of-possession of the private key in the Together with proof-of-possession of the private key in the
certificate request, this is advisable to make sure that the entity certificate request, this is advisable to make sure that the entity
identified in the newly issued certificate is the only entity that identified in the newly issued certificate is the only entity that
knows the private key. knows the private key.
Reasons for central key generation may include the following: Reasons for central key generation may include the following:
* Lack of sufficient initial entropy. * Lack of sufficient initial entropy.
skipping to change at page 46, line 43 skipping to change at page 46, line 43
-- MUST contain the rKeyId choice -- MUST contain the rKeyId choice
rKeyId REQUIRED rKeyId REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST contain the same value as the senderKID in the -- MUST contain the same value as the senderKID in the
-- respective request message header -- respective request message header
encryptedKey encryptedKey
REQUIRED REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
4.1.6.2. Using Key Transport Key Managemen Technique 4.1.6.2. Using Key Transport Key Management Technique
This variant can be applied in combination with the PKI management This variant can be applied in combination with the PKI management
operations specified in Section 4.1.1 to Section 4.1.3 using operations specified in Section 4.1.1 to Section 4.1.3 using
signature-based protection of CMP messages. The EE certificate used signature-based protection of CMP messages. The EE certificate used
for the signature-based protection of the request message MUST allow for the signature-based protection of the request message MUST allow
for the key usage "keyEncipherment" and not for "keyAgreement". for the key usage "keyEncipherment" and not for "keyAgreement".
Therefore, the related key pair MUST be used for encipherment of the Therefore, the related key pair MUST be used for encipherment of the
content-encryption key. For this key management technique, the content-encryption key. For this key management technique, the
KeyTransRecipientInfo structure MUST be used in the contentInfo KeyTransRecipientInfo structure MUST be used in the contentInfo
field. field.
skipping to change at page 58, line 43 skipping to change at page 58, line 43
Note: If the EE does not want to request a specific CRL it MAY use Note: If the EE does not want to request a specific CRL it MAY use
instead a general message with OID id-it-currentCrl as specified in instead a general message with OID id-it-currentCrl as specified in
RFC 4210 Section 5.3.19.6 [RFC4210]. RFC 4210 Section 5.3.19.6 [RFC4210].
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-crlStatusList in the request and 1 the infoType OID to use is id-it-crlStatusList in the request and
id-it-crls in the response id-it-crls in the response
2 the infoValue of the request MUST be present and contain a 2 the infoValue of the request MUST be present and contain exactly
CRLStatus structure one CRLStatus structure
3 if present, the infoValue of the response MUST contain a CRL 3 if present, the infoValue of the response MUST contain exactly one
CRL
Detailed Description of infoValue Field of genm: Detailed Description of infoValue Field of genm:
CRLSource REQUIRED CRLSource REQUIRED
-- MUST contain exactly one CRLSource structure -- MUST contain exactly one CRLSource structure
-- MUST contain the dpn choice of type DistributionPointName if -- MUST contain the dpn choice of type DistributionPointName if
-- the CRL distribution point name is available -- the CRL distribution point name is available
-- Otherwise, MUST contain the issuer choice identifying the CA -- Otherwise, MUST contain the issuer choice identifying the CA
-- that issues the CRL. It MUST contain the issuer DN in the -- that issues the CRL. It MUST contain the issuer DN in the
-- directoryName field of a GeneralName element. -- directoryName field of a GeneralName element.
thisUpdate OPTIONAL thisUpdate OPTIONAL
-- SHOULD contain the thisUpdate field of the latest CRL form -- SHOULD contain the thisUpdate field of the latest CRL form
-- the issuer specified in the given dpn or issuer field, -- the issuer specified in the given dpn or issuer field,
-- in case such a CRL is already known by the EE -- in case such a CRL is already known by the EE
Detailed Description of infoValue Field of genp: Detailed Description of infoValue Field of genp:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CRL to be returned is available -- MUST be absent if no CRL to be returned is available
-- MUST contain one CRL update from the referenced source, if a -- MUST contain exactly one CRL update from the referenced
-- thisUpdate value was not given or a more recent CRL is -- source, if a thisUpdate value was not given or a more recent
-- available -- CRL is available
4.4. Handling Delayed Delivery 4.4. Handling Delayed Delivery
This is a variant of all PKI management operations described in this This is a variant of all PKI management operations described in this
document. It is initiated in case a PKI management entity cannot document. It is initiated in case a PKI management entity cannot
respond to a request message in a timely manner, typically due to respond to a request message in a timely manner, typically due to
offline or asynchronous upstream communication, or due to delays in offline or asynchronous upstream communication, or due to delays in
handling the request. The polling mechanism has been specified in handling the request. The polling mechanism has been specified in
RFC 4210 Section 5.3.22 [RFC4210] and updated by RFC 4210 Section 5.3.22 [RFC4210] and updated by
[I-D.ietf-lamps-cmp-updates]. [I-D.ietf-lamps-cmp-updates].
skipping to change at page 70, line 32 skipping to change at page 70, line 32
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
5.2.2.1. Adding Protection to a Request Message 5.2.2.1. Adding Protection to a Request Message
This variant means that a PKI management entity forwards a CMP This variant means that a PKI management entity forwards a CMP
message while authentically indicating successful validation and message while authentically indicating successful validation and
approval of a request message without changing the original message. approval of a request message without changing the original message.
By adding a protection using its own CMP protecting key the PKI By adding a protection using its own CMP protection key the PKI
management entity provides a proof of verifying and approving the management entity provides a proof of verifying and approving the
message as described above. Thus, the PKI management entity acts as message as described above. Thus, the PKI management entity acts as
an actual Registration Authority (RA), which implements important an actual Registration Authority (RA), which implements important
security functionality of the PKI. Applying an additional protection security functionality of the PKI. Applying an additional protection
is specifically relevant when forwarding a message that requests a is specifically relevant when forwarding a message that requests a
certificate update or central key generation. This is because the certificate update or central key generation. This is because the
original protection of the EE must be preserved while adding an original protection of the EE must be preserved while adding an
indication of approval by the PKI management entity. indication of approval by the PKI management entity.
The PKI management entity wrapping the original request message in a The PKI management entity wrapping the original request message in a
skipping to change at page 73, line 12 skipping to change at page 73, line 12
5 <- nested <- 5 <- nested <-
6 handle nested 6 handle nested
5.2.3. Replacing Protection 5.2.3. Replacing Protection
The following two alternatives can be used by any PKI management The following two alternatives can be used by any PKI management
entity forwarding a CMP message with or without changes while entity forwarding a CMP message with or without changes while
providing its own protection and in this way asserting approval of providing its own protection and in this way asserting approval of
the message. the message.
By replacing the existing protection using its own CMP protecting key By replacing the existing protection using its own CMP protection key
the PKI management entity provides a proof of verifying and approving the PKI management entity provides a proof of verifying and approving
the message as described above. Thus, the PKI management entity acts the message as described above. Thus, the PKI management entity acts
as an actual Registration Authority (RA), which implements important as an actual Registration Authority (RA), which implements important
security functionality of the PKI. security functionality of the PKI.
Before replacing the existing protection by a new protection, the PKI Before replacing the existing protection by a new protection, the PKI
management entity MUST verify the protection provided and approve its management entity MUST verify the protection provided and approve its
content, including any modifications that it may perform. It MUST content, including any modifications that it may perform. It MUST
also check that the sender, as authenticated by the message also check that the sender, as authenticated by the message
protection, is authorized for the given operation. protection, is authorized for the given operation.
skipping to change at page 81, line 26 skipping to change at page 81, line 26
In case a PKI management entity receives an unexpected CoAP status In case a PKI management entity receives an unexpected CoAP status
code from upstream, it MUST respond downstream with an error message code from upstream, it MUST respond downstream with an error message
as described in Section 3.6 using a failInfo bit corresponding to the as described in Section 3.6 using a failInfo bit corresponding to the
status code, e.g., systemFailure. status code, e.g., systemFailure.
Like for HTTP transfer , to offer a second line of defense or to Like for HTTP transfer , to offer a second line of defense or to
provide hop-by-hop privacy protection, DTLS MAY be utilized as provide hop-by-hop privacy protection, DTLS MAY be utilized as
described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport].
6.3. Piggybacking on other Reliable Transfer 6.3. Piggybacking on Other Reliable Transfer
CMP messages MAY also be transfer on some other reliable protocol, CMP messages MAY also be transfer on some other reliable protocol,
e.g., EAP or MQTT. Connection, delay, and error handling mechanisms e.g., EAP or MQTT. Connection, delay, and error handling mechanisms
similar to those specified for HTTP in Section 6.1 need to be similar to those specified for HTTP in Section 6.1 need to be
implemented. implemented.
A more detailed specification is out of scope of this document and A more detailed specification is out of scope of this document and
would need to be given for instance in the scope of the transfer would need to be given for instance in the scope of the transfer
protocol used. protocol used.
skipping to change at page 83, line 9 skipping to change at page 83, line 9
certificate management operation towards the CA not using CMP. certificate management operation towards the CA not using CMP.
Section 5.2 describes different options how an RA can forward a CMP Section 5.2 describes different options how an RA can forward a CMP
message using CMP. Section 5.3 offers the option that an RA operates message using CMP. Section 5.3 offers the option that an RA operates
on behalf on an EE and therefore takes the role of the EE in on behalf on an EE and therefore takes the role of the EE in
Section 4. Section 4.
+==========+=============================+========+========+========+ +==========+=============================+========+========+========+
| ID | PKI Management Operations | EE | RA | CA | | ID | PKI Management Operations | EE | RA | CA |
| | and Variants | | | | | | and Variants | | | |
+==========+=============================+========+========+========+ +==========+=============================+========+========+========+
| Generic | Generic Aspects of PKI | MUST | MAY | MUST | | Generic | Generic Aspects of PKI | MUST | MUST | MUST |
| | Messages and PKI | | | | | | Messages and PKI | | | |
| | Management Operations, | | | | | | Management Operations, | | | |
| | Section 3 | | | | | | Section 3 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| IR | Enrolling an End Entity | MUST | MAY | MUST | | IR | Enrolling an End Entity | MUST | MAY | MUST |
| | to a New PKI, | | | | | | to a New PKI, | | | |
| | Section 4.1.1 | | | | | | Section 4.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CR | Enrolling an End Entity | MAY | MAY | MAY | | CR | Enrolling an End Entity | MAY | MAY | MAY |
| | to a Known PKI, | | | | | | to a Known PKI, | | | |
skipping to change at page 86, line 17 skipping to change at page 86, line 17
+=========+=======================+========+========+========+ +=========+=======================+========+========+========+
| ID | Message Transfer Type | EE | RA | CA | | ID | Message Transfer Type | EE | RA | CA |
+=========+=======================+========+========+========+ +=========+=======================+========+========+========+
| HTTP | HTTP Transfer, | SHOULD | SHOULD | SHOULD | | HTTP | HTTP Transfer, | SHOULD | SHOULD | SHOULD |
| | Section 6.1 | | | | | | Section 6.1 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
| CoAP | CoAP Transfer, | MAY | MAY | MAY | | CoAP | CoAP Transfer, | MAY | MAY | MAY |
| | Section 6.2 | | | | | | Section 6.2 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
| Piggyb | Piggybacking on other | MAY | MAY | MAY | | Piggyb | Piggybacking on Other | MAY | MAY | MAY |
| | Reliable Transfer, | | | | | | Reliable Transfer, | | | |
| | Section 6.3 | | | | | | Section 6.3 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
| Offline | Offline Transfer, | MAY | MAY | MAY | | Offline | Offline Transfer, | MAY | MAY | MAY |
| | Section 6.4 | | | | | | Section 6.4 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
Table 4: Level of Support for Message Transfer Types Table 4: Level of Support for Message Transfer Types
8. IANA Considerations 8. IANA Considerations
skipping to change at page 88, line 43 skipping to change at page 88, line 43
Sahni, M. and S. Tripathi, "CoAP Transfer for the Sahni, M. and S. Tripathi, "CoAP Transfer for the
Certificate Management Protocol", Work in Progress, Certificate Management Protocol", Work in Progress,
Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8
November 2021, <https://datatracker.ietf.org/doc/html/ November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-ace-cmpv2-coap-transport-04>. draft-ietf-ace-cmpv2-coap-transport-04>.
[I-D.ietf-lamps-cmp-algorithms] [I-D.ietf-lamps-cmp-algorithms]
Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms", Work "Certificate Management Protocol (CMP) Algorithms", Work
in Progress, Internet-Draft, draft-ietf-lamps-cmp- in Progress, Internet-Draft, draft-ietf-lamps-cmp-
algorithms-12, 6 April 2022, algorithms-13, 13 May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-12>. cmp-algorithms-13>.
[I-D.ietf-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
Management Protocol (CMP) Updates", Work in Progress, Management Protocol (CMP) Updates", Work in Progress,
Internet-Draft, draft-ietf-lamps-cmp-updates-18, 6 April Internet-Draft, draft-ietf-lamps-cmp-updates-18, 6 April
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cmp-updates-18>. lamps-cmp-updates-18>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 90, line 33 skipping to change at page 90, line 33
Oheimb, D. V., Fries, S., Brockhaus, H., and E. Lear, Oheimb, D. V., Fries, S., Brockhaus, H., and E. Lear,
"BRSKI-AE: Alternative Enrollment Protocols in BRSKI", "BRSKI-AE: Alternative Enrollment Protocols in BRSKI",
Work in Progress, Internet-Draft, draft-ietf-anima-brski- Work in Progress, Internet-Draft, draft-ietf-anima-brski-
ae-01, 6 April 2022, ae-01, 6 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima- <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
brski-ae-01>. brski-ae-01>.
[I-D.ietf-anima-brski-prm] [I-D.ietf-anima-brski-prm]
Fries, S., Werner, T., Lear, E., and M. C. Richardson, Fries, S., Werner, T., Lear, E., and M. C. Richardson,
"BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-02, 4 Progress, Internet-Draft, draft-ietf-anima-brski-prm-03,
March 2022, <https://datatracker.ietf.org/doc/html/draft- 29 April 2022, <https://datatracker.ietf.org/doc/html/
ietf-anima-brski-prm-02>. draft-ietf-anima-brski-prm-03>.
[I-D.ietf-netconf-sztp-csr] [I-D.ietf-netconf-sztp-csr]
Watsen, K., Housley, R., and S. Turner, "Conveying a Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14,
2 March 2022, <https://datatracker.ietf.org/doc/html/ 2 March 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-14>. draft-ietf-netconf-sztp-csr-14>.
[IEC.62443-3-3] [IEC.62443-3-3]
skipping to change at page 94, line 42 skipping to change at page 94, line 42
INTEGER 2048 INTEGER 2048
} }
} }
} }
Appendix B. History of Changes Appendix B. History of Changes
Note: This appendix will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
From version 11 -> 12:
* Added a note to Section 4.1.6 to clarify the combination of
central key generation with certificate update
* Updated Section 4.3.4 for clarification that only one CRL per
round-trip is requested
* Updated Section 7.1 to fix a wrong change from the last update in
the first two rows of Table 3
From version 10 -> 11: From version 10 -> 11:
* Updated Section 3.2, 3.5, and 3.6.4 to define more clearly * Updated Section 3.2, 3.5, and 3.6.4 to define more clearly
signature-based protection as the default and the exception for signature-based protection as the default and the exception for
not protecting error messages as mentioned at IETF 113 not protecting error messages as mentioned at IETF 113
* Streamlined headlines in Section 4.1 * Streamlined headlines in Section 4.1
* Updates Section 6.1 and Section 6.2 regarding new well-known path * Updates Section 6.1 and Section 6.2 regarding new well-known path
segment for profile labels as discussed during IETF 113 segment for profile labels as discussed during IETF 113
* Updated Section 7.1. on the support of PKI management operations * Updated Section 7.1. on the support of PKI management operations
required for EEs, RAs, and CAs as mentioned at IETF 113 required for EEs, RAs, and CAs as mentioned at IETF 113
 End of changes. 19 change blocks. 
23 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/