draft-ietf-lamps-lightweight-cmp-profile-09.txt   draft-ietf-lamps-lightweight-cmp-profile-10.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: 20 June 2022 Siemens Expires: 5 August 2022 Siemens
17 December 2021 1 February 2022
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-09 draft-ietf-lamps-lightweight-cmp-profile-10
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 20 June 2022. This Internet-Draft will expire on 5 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4
1.2. Motivation for a lightweight profile of CMP . . . . . . . 5 1.2. Motivation for a lightweight profile of CMP . . . . . . . 5
1.3. Special requirements of industrial and IoT scenarios . . 6 1.3. Special requirements of industrial and IoT scenarios . . 6
1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7
1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7
1.6. Compatibility with existing CMP profiles . . . . . . . . 8 1.6. Compatibility with existing CMP profiles . . . . . . . . 8
1.7. Scope of this document . . . . . . . . . . . . . . . . . 9 1.7. Scope of this document . . . . . . . . . . . . . . . . . 10
1.8. Structure of this document . . . . . . . . . . . . . . . 10 1.8. Structure of this document . . . . . . . . . . . . . . . 10
1.9. Convention and Terminology . . . . . . . . . . . . . . . 11 1.9. Convention and Terminology . . . . . . . . . . . . . . . 11
2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12 2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12
3. Generic aspects of the PKI message . . . . . . . . . . . . . 13 3. Generic aspects of the PKI message . . . . . . . . . . . . . 14
3.1. General description of the CMP message header . . . . . . 14 3.1. General description of the CMP message header . . . . . . 15
3.2. General description of the CMP message protection . . . . 16 3.2. General description of the CMP message protection . . . . 17
3.3. General description of CMP message extraCerts . . . . . . 17 3.3. General description of CMP message extraCerts . . . . . . 17
3.4. Generic PKI management operation prerequisites . . . . . 17 3.4. Generic PKI management operation prerequisites . . . . . 18
3.5. Generic validation of a PKI message . . . . . . . . . . . 19 3.5. Generic validation of a PKI message . . . . . . . . . . . 19
3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21
3.6.1. Reporting error conditions upstream . . . . . . . . . 21 3.6.1. Reporting error conditions upstream . . . . . . . . . 21
3.6.2. Reporting error conditions downstream . . . . . . . . 22 3.6.2. Reporting error conditions downstream . . . . . . . . 22
3.6.3. Handling error conditions on nested messages used for 3.6.3. Handling error conditions on nested messages used for
batching . . . . . . . . . . . . . . . . . . . . . . 22 batching . . . . . . . . . . . . . . . . . . . . . . 22
3.6.4. Reporting error conditions . . . . . . . . . . . . . 22 3.6.4. Reporting error conditions . . . . . . . . . . . . . 23
4. End Entity PKI management operations . . . . . . . . . . . . 24 4. End Entity PKI management operations . . . . . . . . . . . . 24
4.1. Requesting a new certificate from a PKI . . . . . . . . . 27 4.1. Requesting a new certificate from a PKI . . . . . . . . . 27
4.1.1. Requesting a certificate from a new PKI with 4.1.1. Requesting a certificate from a new PKI with
signature-based protection . . . . . . . . . . . . . 28 signature-based protection . . . . . . . . . . . . . 28
4.1.2. Requesting an additional certificate with 4.1.2. Requesting an additional certificate with
signature-based protection . . . . . . . . . . . . . 34 signature-based protection . . . . . . . . . . . . . 34
4.1.3. Updating an existing certificate with signature 4.1.3. Updating an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 35 protection . . . . . . . . . . . . . . . . . . . . . 35
4.1.4. Requesting a certificate from a legacy PKI using a 4.1.4. Requesting a certificate from a legacy PKI using a
PKCS#10 request . . . . . . . . . . . . . . . . . . . 36 PKCS#10 request . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 7, line 37 skipping to change at page 7, line 37
UNISIG has included a CMP profile for enrollment of TLS certificates UNISIG has included a CMP profile for enrollment of TLS certificates
in the Subset-137 specifying the ETRAM/ETCS on-line key management in the Subset-137 specifying the ETRAM/ETCS on-line key management
for train control systems [UNISIG.Subset-137] in 2015. for train control systems [UNISIG.Subset-137] in 2015.
Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and
HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI
management operations for unattended devices and services. management operations for unattended devices and services.
1.5. Use of CMP in SZTP and BRSKI environments 1.5. Use of CMP in SZTP and BRSKI environments
In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other
SZTP-CSR [I-D.ietf-netconf-sztp-csr] includes certificate signing environments using NETCONF/YANG modules, SZTP-CSR
requests (CSR) in device bootstrapping to obtain a public-key [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes
different types of certificate requests to obtain a public-key
certificate for a locally generated key pair. One option is using a certificate for a locally generated key pair. One option is using a
CMP p10cr message. Such a CSR is of form ietf-sztp-types:cmp-csr CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp-
from module ietf-sztp-csr. To allow PKI management entities to also csr from module ietf-ztp-csr and offers both proof-of-possession and
comply with this profile, the p10cr message must be formatted by the proof-of-identity. To allow PKI management entities to also comply
EE as described in Section 4.1.4 of this profile, and it may be with this profile, the p10cr message must be formatted by the EE as
forwarded as specified in Section 5.2. described in Section 4.1.4 of this profile, and it may be forwarded
as specified in Section 5.2.
In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous
Enrollment [I-D.ietf-anima-brski-async-enroll] describes a Enrollment [I-D.ietf-anima-brski-async-enroll] describes a
generalization regarding the employed enrollment protocols to allow generalization regarding the employed enrollment protocols to allow
alternatives to EST [RFC7030]. For the use of CMP, it requires alternatives to EST [RFC7030]. For the use of CMP, it requires
adherence to this profile. adherence to this profile.
1.6. Compatibility with existing CMP profiles 1.6. Compatibility with existing CMP profiles
skipping to change at page 19, line 11 skipping to change at page 19, line 21
specific name patterns for subject DN or SAN portions that may specific name patterns for subject DN or SAN portions that may
identify an RA, and/or by having a dedicated root CA usable only identify an RA, and/or by having a dedicated root CA usable only
for authenticating PKI management entities. for authenticating PKI management entities.
* Each PKI management entity MUST have sufficient information to be * Each PKI management entity MUST have sufficient information to be
able to authorize the downstream PKI entity requesting the PKI able to authorize the downstream PKI entity requesting the PKI
management operation. management operation.
Note: For authorizing an RA the same examples apply as above. The Note: For authorizing an RA the same examples apply as above. The
authorization of EEs can be very specific to the application authorization of EEs can be very specific to the application
domain and may involve information from configuration or inventory domain based on local PKI policy.
database. It may involve, e.g., the issuer information of the EE
certificate, specific contents of the CMP protection certificate
used by the EE such as name patterns of subject DN or SAN
portions, shared secret information, and other types of
credentials and evidence potentially communicated out-of-band.
3.5. Generic validation of a PKI message 3.5. Generic validation of a PKI message
This section describes generic validation steps of each PKI entity This section describes generic validation steps of each PKI entity
receiving a PKI request or response message before any further receiving a PKI request or response message before any further
processing or forwarding. If a PKI management entity decides to processing or forwarding. If a PKI management entity decides to
terminate a PKI management operation because a check failed, it MUST terminate a PKI management operation because a check failed, it MUST
send a negative response or an error message as described in send a negative response or an error message as described in
Section 3.6. The PKIFailureInfo bits given below in parentheses MAY Section 3.6. The PKIFailureInfo bits given below in parentheses MAY
be used in the failInfo field of the PKIStatusInfo as described in be used in the failInfo field of the PKIStatusInfo as described in
skipping to change at page 22, line 28 skipping to change at page 22, line 35
according to the checks described in Section 3.5 it MUST report them according to the checks described in Section 3.5 it MUST report them
downstream in the form of an error message as described in downstream in the form of an error message as described in
Section 3.6.4. Section 3.6.4.
3.6.3. Handling error conditions on nested messages used for batching 3.6.3. Handling error conditions on nested messages used for batching
Batching of messages using nested messages as described in Batching of messages using nested messages as described in
Section 5.2.2.2 requires special error handling. Section 5.2.2.2 requires special error handling.
If the error condition is on an upstream nested message containing If the error condition is on an upstream nested message containing
batched requests, it MUST not attempt to respond to the individual batched requests, it MUST NOT attempt to respond to the individual
requests included in it. requests included in it.
In case a PKI management entity receives an error message in response In case a PKI management entity receives an error message in response
to a nested message, it must propagate the error by responding with to a nested message, it must propagate the error by responding with
an error message to each of the request messages contained in the an error message to each of the request messages contained in the
nested message. nested message.
In case a PKI management entity detects an error condition on the In case a PKI management entity detects an error condition on the
downstream nested message received in response to a nested message downstream nested message received in response to a nested message
sent before, it MAY ignore this error condition and handle the sent before, it MAY ignore this error condition and handle the
skipping to change at page 23, line 39 skipping to change at page 23, line 47
- certRevoked: Revocation requested for a certificate already - certRevoked: Revocation requested for a certificate already
revoked revoked
- badCertTemplate: The contents of a certificate request are not - badCertTemplate: The contents of a certificate request are not
accepted, e.g., a field is missing or has a non-acceptable accepted, e.g., a field is missing or has a non-acceptable
value or the given public key is already in use in some other value or the given public key is already in use in some other
certificate (depending on policy). certificate (depending on policy).
- transactionIdInUse: This is sent by a PKI management entity in - transactionIdInUse: This is sent by a PKI management entity in
case the received request contains a transaction ID that has case the received request contains a transactionID that has
already been used for another transaction. An EE receiving already been used for another transaction. An EE receiving
such error message SHOULD resend the request in a new such error message SHOULD resend the request in a new
transaction using a different transaction ID. transaction using a different transactionID.
- notAuthorized: The sender of a request message is not - notAuthorized: The sender of a request message is not
authorized for requesting the operation. authorized for requesting the operation.
- systemUnavail: This is sent by a PKI management entity in case - systemUnavail: This is sent by a PKI management entity in case
a back-end system is not available. a back-end system is not available.
- systemFailure: This is sent by a PKI management entity in case - systemFailure: This is sent by a PKI management entity in case
a back-end system is currently not functioning correctly. a back-end system is currently not functioning correctly.
skipping to change at page 28, line 23 skipping to change at page 28, line 23
potentially intended restrictions of the key usage. potentially intended restrictions of the key usage.
Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2
[NIST.SP.800-57p1r5] the newly generated private key MAY be used for [NIST.SP.800-57p1r5] the newly generated private key MAY be used for
self-signature, if technically possible, even if the keyUsage self-signature, if technically possible, even if the keyUsage
extension requested in the certificate request prohibits generation extension requested in the certificate request prohibits generation
of digital signatures. of digital signatures.
The requesting EE provides the binding of the proof-of-possession to The requesting EE provides the binding of the proof-of-possession to
its identity by signature-based or MAC-based protection of the CMP its identity by signature-based or MAC-based protection of the CMP
request message containing that POP. As detailed in Section 5.1.1 request message containing that POP. An upstream PKI management
and Section 5.1.2, an upstream PKI management entity should verify entity should verify whether this EE is authorized to obtain a
whether this EE is authorized to obtain a certificate with the certificate with the requested subject and other fields and
requested subject and other fields and extensions. extensions.
The EE MAY indicate the certificate profile to use in the certProfile The EE MAY indicate the certificate profile to use in the certProfile
extension of the generalInfo field in the PKIHeader of the extension of the generalInfo field in the PKIHeader of the
certificate request message as described in Section 3.1. certificate request message as described in Section 3.1.
In case the EE receives a CA certificate in the caPubs field for In case the EE receives a CA certificate in the caPubs field for
installation as a new trust anchor, it MUST properly authenticate the installation as a new trust anchor, it MUST properly authenticate the
message and authorize the sender as trusted source of the new trust message and authorize the sender as trusted source of the new trust
anchor. This authorization is typically indicated using shared anchor. This authorization is typically indicated using shared
secret information for protecting an initialization response (ir) secret information for protecting an initialization response (ir)
skipping to change at page 63, line 38 skipping to change at page 63, line 38
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first response -- MUST use the same credentials as in the first response
-- message of the PKI management operation -- message of the PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has -- MAY be omitted if the message size is critical and the EE has
-- cached the extraCerts from the first response message of -- cached the extraCerts from the first response message of
-- the PKI management operation -- the PKI management operation
Final response any type of response message Final response - any type of response message
Field Value Field Value
header header
-- MUST be the header as described for the response message -- MUST be the header as described for the response message
-- of the respective PKI management operation -- of the respective PKI management operation
body body
-- The response of the PKI management entity to the initial -- The response of the PKI management entity to the initial
skipping to change at page 67, line 50 skipping to change at page 67, line 50
message if this is technically necessary. Concrete PKI system message if this is technically necessary. Concrete PKI system
specifications may define in more detail when to do so. specifications may define in more detail when to do so.
This is particularly relevant in the upstream communication of a This is particularly relevant in the upstream communication of a
request message. request message.
Each forwarding PKI management entity has one or more Each forwarding PKI management entity has one or more
functionalities. It may functionalities. It may
* verify the identities of EEs and make authorization decisions for * verify the identities of EEs and make authorization decisions for
certification request processing based on specific knowledge of certification request processing based on local PKI policy,
the local setup, e.g., by consulting an inventory or asset
management system,
* add or modify fields of certificate request messages, * add or modify fields of certificate request messages,
* store data from a message in a database for later usage or audit * store data from a message in a database for later usage or audit
purposes, purposes,
* provide traversal of a network boundary, * provide traversal of a network boundary,
* replace a MAC-based protection by a signature-based protection * replace a MAC-based protection by a signature-based protection
that can be verified also further upstream, that can be verified also further upstream,
* double-check if the messages transferred back and forth are * double-check if the messages transferred back and forth are
properly protected and well-formed, properly protected and well-formed,
skipping to change at page 71, line 15 skipping to change at page 71, line 15
The PKI management entity responding to the request contained in the The PKI management entity responding to the request contained in the
nested message sends the response message as described in nested message sends the response message as described in
Section 5.1, without wrapping it in a nested message. Section 5.1, without wrapping it in a nested message.
Note: This form of nesting messages is characterized by the fact that Note: This form of nesting messages is characterized by the fact that
the transactionID in the header of the nested message is the same as the transactionID in the header of the nested message is the same as
the one used in the included message. the one used in the included message.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST have the authorization to perform * The PKI management entity MUST be able to validate the respective
the validation and approval of the respective request according to request and have the authorization to perform approval of the
the PKI policies. request according to the PKI policies.
Message flow: Message flow:
Step# PKI management entity PKI management entity Step# PKI management entity PKI management entity
1 format nested 1 format nested
2 -> nested -> 2 -> nested ->
3 handle or forward nested 3 handle or forward nested
4 format or receive response 4 format or receive response
5 <- response <- 5 <- response <-
6 forward response 6 forward response
skipping to change at page 74, line 11 skipping to change at page 74, line 11
This variant of forwarding a message means that a PKI management This variant of forwarding a message means that a PKI management
entity forwards a CMP message with or without modifying the message entity forwards a CMP message with or without modifying the message
header or body while preserving any included proof-of-possession. header or body while preserving any included proof-of-possession.
In case the PKI management entity breaks an existing proof-of- In case the PKI management entity breaks an existing proof-of-
possession, the message adaptation described in Section 5.2.3.2 needs possession, the message adaptation described in Section 5.2.3.2 needs
to be applied instead. to be applied instead.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST have the authorization to perform * The PKI management entity MUST be able to validate the respective
the validation and approval of the respective request according to request and have the authorization to perform approval of the
the PKI policies. request according to the PKI policies.
5.2.3.2. Breaking proof-of-possession 5.2.3.2. Breaking proof-of-possession
This variant of forwarding a message needs to be used if a PKI This variant of forwarding a message needs to be used if a PKI
management entity breaks a signature-based proof-of-possession in a management entity breaks a signature-based proof-of-possession in a
certificate request message, for instance because it forwards an ir certificate request message, for instance because it forwards an ir
or cr message with modifications of the certTemplate, i.e., or cr message with modifications of the certTemplate, i.e.,
modification, addition, or removal of fields. modification, addition, or removal of fields.
The PKI management entity MUST verify the proof-of-possession The PKI management entity MUST verify the proof-of-possession
contained in the original message using the included public key. If contained in the original message using the included public key. If
successful, the PKI management entity MUST change the popo field successful, the PKI management entity MUST change the popo field
value to raVerified. value to raVerified.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST have the authorization to verify * The PKI management entity MUST be authorized to replace the proof-
the proof-of-possession. of-possession (after verifying it) with raVerified.
* The PKI management entity MUST have the authorization to perform * The PKI management entity MUST be able to validate the respective
the validation and approval of the respective request according to request and have the authorization to perform approval of the
the PKI policies. request according to the PKI policies.
The new popo field MUST contain the raVerified choice in the certReq The new popo field MUST contain the raVerified choice in the certReq
structure of the modified message as follows: structure of the modified message as follows:
popo popo
raVerified REQUIRED raVerified REQUIRED
-- MUST have the value NULL and indicates that the PKI -- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original message -- management entity verified the popo of the original message
5.3. Acting on behalf of other PKI entities 5.3. Acting on behalf of other PKI entities
skipping to change at page 79, line 30 skipping to change at page 79, line 30
keys, also confidentiality is a must. These goals are sufficiently keys, also confidentiality is a must. These goals are sufficiently
achieved by CMP itself, also in an end-to-end fashion. If a second achieved by CMP itself, also in an end-to-end fashion. If a second
line of defense is required or general privacy concerns exist, TLS line of defense is required or general privacy concerns exist, TLS
can be used to provide confidentiality on a hop-by-hop basis. can be used to provide confidentiality on a hop-by-hop basis.
TLS SHOULD be used with certificate-based authentication to further TLS SHOULD be used with certificate-based authentication to further
protect the HTTP transfer as described in [RFC2818]. The CMP protect the HTTP transfer as described in [RFC2818]. The CMP
transfer via HTTPS MUST use TLS server authentication and SHOULD use transfer via HTTPS MUST use TLS server authentication and SHOULD use
TLS client authentication. TLS client authentication.
Note: The requirements for checking certificates given in [RFC5280], Note: The requirements for checking certificates given in [RFC5280]
[RFC5246], and [RFC8446] MUST be followed for the TLS layer. and either [RFC5246] or [RFC8446] MUST be followed for the TLS layer.
Certificate status checking SHOULD be used for the TLS certificates Certificate status checking SHOULD be used for the TLS certificates
of all communication partners. of all communication partners.
TLS with mutual authentication based on shared secret information MAY TLS with mutual authentication based on shared secret information MAY
be used in case no suitable certificates for certificate-based be used in case no suitable certificates for certificate-based
authentication are available, e.g., a PKI management operation with authentication are available, e.g., a PKI management operation with
MAC-based protection is used. MAC-based protection is used.
Note: The entropy of the shared secret information is crucial for the Note: The entropy of the shared secret information is crucial for the
level of protection available using shard secret information-based level of protection available using shard secret information-based
skipping to change at page 87, line 17 skipping to change at page 87, line 17
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-08, 17 November 2021, algorithms-09, 22 December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-08>. cmp-algorithms-09>.
[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-15, 17 Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12
December 2021, <https://datatracker.ietf.org/doc/html/ January 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-cmp-updates-15>. draft-ietf-lamps-cmp-updates-17>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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 page 89, line 16 skipping to change at page 89, line 16
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, Progress, Internet-Draft, draft-ietf-anima-brski-prm-00,
25 October 2021, <https://datatracker.ietf.org/doc/html/ 25 October 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-00>. draft-ietf-anima-brski-prm-00>.
[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-12, Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-13,
3 December 2021, <https://datatracker.ietf.org/doc/html/ 31 January 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-12>. draft-ietf-netconf-sztp-csr-13>.
[IEC.62443-3-3] [IEC.62443-3-3]
IEC, "Industrial communication networks - Network and IEC, "Industrial communication networks - Network and
system security - Part 3-3: System security requirements system security - Part 3-3: System security requirements
and security levels", IEC 62443-3-3, August 2013, and security levels", IEC 62443-3-3, August 2013,
<https://webstore.iec.ch/publication/7033>. <https://webstore.iec.ch/publication/7033>.
[IEEE.802.1AR_2018] [IEEE.802.1AR_2018]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", IEEE 802.1AR-2018, networks - Secure Device Identity", IEEE 802.1AR-2018,
skipping to change at page 93, line 12 skipping to change at page 93, line 12
} }
} }
} }
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 09 -> 10:
* Resolved some nits reported by I-D nit checker tool
* Resolve some wording issues
From version 08 -> 09: From version 08 -> 09:
* Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into * Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into
more detailed tables in Section 7 (see thread "WG Last Call for more detailed tables in Section 7 (see thread "WG Last Call for
draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-
cmp-profile-08") cmp-profile-08")
* Updated Section 3.1 and 4.1.1 making implicitConfirm recommended * Updated Section 3.1 and 4.1.1 making implicitConfirm recommended
for ir/cr/p10cr/kur and providing further recommendations on its for ir/cr/p10cr/kur and providing further recommendations on its
use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp- use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp-
updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")
skipping to change at page 96, line 12 skipping to change at page 96, line 21
From version 01 -> 02: From version 01 -> 02:
* Extend Section 1.6 with regard to conflicts with UNISIG Subset- * Extend Section 1.6 with regard to conflicts with UNISIG Subset-
137. 137.
* Minor clarifications on extraCerts in Section 3.3 and * Minor clarifications on extraCerts in Section 3.3 and
Section 4.1.1. Section 4.1.1.
* Complete specification of requesting a certificate from a trusted * Complete specification of requesting a certificate from a trusted
PKI with signature protection in Section 4.1.2. PKI with signature protection in Section 4.1.2.
* Changed from symmetric key-encryption to password-based key * Changed from symmetric key-encryption to password-based key
management technique in section Section 4.1.6.3 as discussed on management technique in Section 4.1.6.3 as discussed on the
the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.1.6.1") profile-01, section 5.1.6.1")
* Changed delayed enrollment described in Section 4.4 from * Changed delayed enrollment described in Section 4.4 from
recommended to optional as decided at IETF 107 recommended to optional as decided at IETF 107
* Introduced the new RootCAKeyUpdate structure for root CA * Introduced the new RootCAKeyUpdate structure for root CA
certificate update in Section 4.3.2 as decided at IETF 107 (also certificate update in Section 4.3.2 as decided at IETF 107 (also
see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
section 5.4.3") section 5.4.3")
* Extend the description of the CertReqTemplate PKI management * Extend the description of the CertReqTemplate PKI management
operation, including an example added in the Appendix. Keep operation, including an example added in the Appendix. Keep
rsaKeyLen as a single integer value in Section 4.3.3 as discussed rsaKeyLen as a single integer value in Section 4.3.3 as discussed
 End of changes. 29 change blocks. 
60 lines changed or deleted 59 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/