Diff: draft-ietf-lamps-rfc6712bis-07.txt - draft-ietf-lamps-rfc6712bis-08.txt
 draft-ietf-lamps-rfc6712bis-07.txt   draft-ietf-lamps-rfc6712bis-08.txt 
LAMPS Working Group H. Brockhaus LAMPS Working Group H. Brockhaus
Internet-Draft D. von Oheimb Internet-Draft D. von Oheimb
Obsoletes: 6712 9480 (if approved) Siemens Obsoletes: 6712 9480 (if approved) Siemens
Intended status: Standards Track M. Ounsworth Intended status: Standards Track M. Ounsworth
Expires: 12 April 2025 J. Gray Expires: 22 May 2025 J. Gray
Entrust Entrust
9 October 2024 18 November 2024
Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Internet X.509 Public Key Infrastructure -- HTTP Transfer for the
Certificate Management Protocol (CMP) Certificate Management Protocol (CMP)
draft-ietf-lamps-rfc6712bis-07 draft-ietf-lamps-rfc6712bis-08
Abstract Abstract
This document describes how to layer the Certificate Management This document describes how to layer the Certificate Management
Protocol (CMP) over HTTP. Protocol (CMP) over HTTP.
It includes the updates on RFC 6712 specified in CMP Updates RFC 9480 It includes the updates to RFC 6712 specified in RFC 9480 Section 3.
Section 3 and obsoleted both documents. These updates introduce CMP These updates introduce CMP URIs using a Well-known prefix. It
URIs using a Well-known prefix. obsoletes RFC 6712 and together with I-D.ietf-lamps-rfc4210bis and it
also obsoletes RFC 9480.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 12 April 2025. This Internet-Draft will expire on 22 May 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Changes Made by RFC 9480 . . . . . . . . . . . . . . . . 4 1.1. Changes Made by RFC 9480 . . . . . . . . . . . . . . . . 4
1.2. Changes Made by This Document . . . . . . . . . . . . . . 4 1.2. Changes Made by This Document . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. HTTP-Based Protocol . . . . . . . . . . . . . . . . . . . . . 4 3. HTTP-Based Protocol . . . . . . . . . . . . . . . . . . . . . 4
3.1. HTTP Versions . . . . . . . . . . . . . . . . . . . . . . 4 3.1. HTTP Versions . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Persistent Connections . . . . . . . . . . . . . . . . . 4 3.2. Persistent Connections . . . . . . . . . . . . . . . . . 5
3.3. General Form . . . . . . . . . . . . . . . . . . . . . . 5 3.3. General Form . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Header Fields . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Header Fields . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Communication Workflow . . . . . . . . . . . . . . . . . 5 3.5. Communication Workflow . . . . . . . . . . . . . . . . . 6
3.6. HTTP Request-URI . . . . . . . . . . . . . . . . . . . . 6 3.6. HTTP Request-URI . . . . . . . . . . . . . . . . . . . . 6
3.7. Pushing of Announcements . . . . . . . . . . . . . . . . 6 3.7. Pushing of Announcements . . . . . . . . . . . . . . . . 7
3.8. HTTP Considerations . . . . . . . . . . . . . . . . . . . 7
4. Implementation Considerations . . . . . . . . . . . . . . . . 8 4. Implementation Considerations . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. History of Changes . . . . . . . . . . . . . . . . . 11 Appendix A. History of Changes . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
[RFC Editor: please delete: [RFC Editor: please delete:
During IESG telechat the CMP Updates document was approved on During IESG telechat the CMP Updates document was approved on
condition that LAMPS provides a RFC6712bis document. Version -00 of condition that LAMPS provides a RFC6712bis document. Version -00 of
this document shall be identical to RFC 6712 and version -01 this document shall be identical to RFC 6712 and version -01
incorporates the changes specified in CMP Updates Section 3. incorporates the changes specified in CMP Updates Section 3.
skipping to change at page 3, line 22 skipping to change at page 3, line 22
poll for outstanding PKI messages. Additionally, it was mentioned poll for outstanding PKI messages. Additionally, it was mentioned
that PKI messages could also be conveyed using file-, E-mail-, and that PKI messages could also be conveyed using file-, E-mail-, and
HTTP-based transfer, but those were not specified in detail. HTTP-based transfer, but those were not specified in detail.
Since the second version of the CMP specification [RFC4210] Since the second version of the CMP specification [RFC4210]
incorporated its own polling mechanism and thus the need for a incorporated its own polling mechanism and thus the need for a
transfer protocol providing this functionality vanished. The transfer protocol providing this functionality vanished. The
remaining features CMP requires from its transfer protocols are remaining features CMP requires from its transfer protocols are
connection and error handling. connection and error handling.
CMP can benefit from utilizing a reliable transport and it requires CMP can benefit from utilizing a reliable transport as CMP requires
connection and error handling from the transfer protocol, which is connection and error handling from the transfer protocol. All theses
all covered by HTTP. Additionally, delayed delivery of CMP response features are covered by HTTP. Additionally, delayed delivery of CMP
messages may be handled at transfer level, regardless of the message response messages may be handled at transfer level, regardless of the
contents. Since [RFC9480] extends the polling mechanism specified in message contents. Since [RFC9480] extends the polling mechanism
the second version of CMP [RFC4210] to cover all types of PKI specified in the second version of CMP [RFC4210] to cover all types
management transactions, delays detected at application level may of PKI management transactions, delays detected at application level
also be handled within CMP, using pollReq and pollRep messages. may also be handled within CMP, using pollReq and pollRep messages.
The usage of HTTP for transferring CMP messages exclusively uses the The usage of HTTP (e.g., HTTP/1.1 as specified in [RFC9110] and
POST method for requests, effectively tunneling CMP over HTTP. While [RFC9112]) for transferring CMP messages exclusively uses the POST
this is generally considered bad practice and should not be emulated, method for requests, effectively tunneling CMP over HTTP. While this
there are good reasons to do so for transferring CMP. HTTP is used is generally considered bad practice (see BCP 56 [RFC9205] for best
as it is generally easy to implement and it is able to traverse current practice on building protocols with HTTP) and should not be
network borders utilizing ubiquitous proxies. Most importantly, HTTP emulated, there are good reasons to do so for transferring CMP. HTTP
is already commonly used in existing CMP implementations. Other HTTP is used as it is generally easy-to-implement and it is able to
request methods, such as GET, are not used because PKI management traverse network borders utilizing ubiquitous proxies. Most
operations can only be triggered using CMP's PKI messages, which need importantly, HTTP is already commonly used in existing CMP
to be transferred using a POST request. implementations. Other HTTP request methods, such as GET, are not
used because PKI management operations can only be triggered using
CMP's PKI messages, which need to be transferred using a POST
request.
With its status codes, HTTP provides needed error reporting With its status codes, HTTP provides needed error reporting
capabilities. General problems on the server side, as well as those capabilities. General problems on the server side, as well as those
directly caused by the respective request, can be reported to the directly caused by the respective request, can be reported to the
client. client.
As CMP implements a transaction ID, identifying transactions spanning As CMP implements a transaction identification (transactionID),
over more than just a single request/response pair, the statelessness identifying transactions spanning over more than just a single
of HTTP is not blocking its usage as the transfer protocol for CMP request/response pair, the statelessness of HTTP is not blocking its
messages. usage as the transfer protocol for CMP messages.
1.1. Changes Made by RFC 9480 1.1. Changes Made by RFC 9480
CMP Updates [RFC9480] updated [RFC6712], supporting the PKI CMP Updates [RFC9480] updated Section 3.6 of [RFC6712], supporting
management operations specified in the Lightweight CMP Profile the PKI management operations specified in the Lightweight CMP
[RFC9483], in the following areas: Profile [RFC9483], in the following areas:
* Introduce the HTTP URI path prefix '/.well-known/cmp'. * Introduce the HTTP URI path prefix '/.well-known/cmp'.
* Add options for extending the URI structure with further segments * Add options for extending the URI structure with further segments
and to this end define a new protocol registry group. and define a new protocol registry group to that aim.
1.2. Changes Made by This Document 1.2. Changes Made by This Document
This document obsoletes RFC 6712 [RFC6712]. It includes the changes This document obsoletes [RFC6712]. It includes the changes specified
specified by CMP Updates [RFC9480] Section 3 as described in in Section 3 of [RFC9480] as described in Section 1.1 of this
Section 1.1 and added the requirement on providing the Content-Length document. Additionally it adds the following changes:
header field in Section 3.4.
* Removed the requirement to support HTTP/1.0 [RFC1945] in
accordance with Section 4.1 of [RFC9205].
* Implementations MUST forward CMP messages when an HTTP error
status code occurs, see Section 3.3.
* Removed Section 3.8 of [RFC6712] as it contains information
redundant with current HTTP specification.
2. Conventions Used in This Document 2. Conventions Used in This Document
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
capitals, as shown here. capitals, as shown here.
3. HTTP-Based Protocol 3. HTTP-Based Protocol
For direct interaction between two entities, where a reliable For direct interaction between two entities, where a reliable
transport protocol like TCP is available, HTTP SHOULD be utilized for transport protocol like TCP [RFC9293] is available, HTTP SHOULD be
conveying CMP messages. utilized for conveying CMP messages.
3.1. HTTP Versions 3.1. HTTP Versions
Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support This draft requires uses of the POST method (Section 3.3) and the
HTTP/1.1 [RFC9112]. "Content-Type" header field (Section 3.4) which are available since
HTTP/1.0 [RFC1945]. This specification also specifies use of
persistent connections (Section 3.2). This document refers to
HTTP/1.1 as specified in [RFC9110] and [RFC9112] for further details.
3.2. Persistent Connections 3.2. Persistent Connections
HTTP persistent connections [RFC9112] allow multiple interactions to HTTP persistent connections (Section 9.3 of [RFC9112]) allow multiple
take place on the same HTTP connection. However, neither HTTP nor interactions to take place on the same HTTP connection. However,
the protocol specified in this document are designed to correlate neither HTTP nor the protocol specified in this document are designed
messages on the same connection in any meaningful way; persistent to correlate messages on the same connection in any meaningful way;
connections are only a performance optimization. In particular, persistent connections are only a performance optimization. In
intermediaries can do things like mix connections from different particular, intermediaries can do things like mix connections from
clients into one "upstream" connection, terminate persistent different clients into one upstream connection, terminate persistent
connections, and forward requests as non-persistent requests, etc. connections, and forward requests as non-persistent requests, etc.
As such, implementations MUST NOT infer that requests on the same As such, implementations MUST NOT infer that requests on the same
connection come from the same client (e.g., for correlating PKI connection come from the same client (e.g., for correlating PKI
messages with ongoing transactions); every message is to be evaluated messages with ongoing transactions); every message is to be evaluated
in isolation. in isolation.
3.3. General Form 3.3. General Form
A DER-encoded [ITU.X690.1994] PKIMessage [I-D.ietf-lamps-rfc4210bis] A DER-encoded [ITU.X690.1994] PKIMessage (Section 5.1 of
is sent as the entity-body of an HTTP POST request. If this HTTP [I-D.ietf-lamps-rfc4210bis]) MUST be sent as the content of an HTTP
request is successful, the server returns the CMP response in the POST request. If this HTTP request is successful, the server returns
body of the HTTP response. The HTTP response status code in this the CMP response in the content of the HTTP response. The HTTP
case MUST be 200; other "Successful 2xx" codes MUST NOT be used for response status code in this case MUST be 200 (OK) status code; other
this purpose. HTTP responses to pushed CMP Announcement messages Successful 2xx status codes MUST NOT be used for this purpose. HTTP
(i.e., CA Certificate Announcement, Certificate Announcement, responses to pushed CMP announcement messages described in
Revocation Announcement, and Certificate Revocation List (CRL) Section 3.7 utilize the status codes 201 and 202 to identify whether
Announcement) utilize the status codes 201 and 202 to identify the received information was processed.
whether the received information was processed.
While "Redirection 3xx" status codes MAY be supported by While Redirection 3xx status codes MAY be supported by
implementations, clients should only be enabled to automatically implementations, clients should only be enabled to automatically
follow them after careful consideration of possible security follow them after careful consideration of possible security
implications. As described in Section 5, "301 Moved Permanently" implications. As described in Section 5, 301 (Moved Permanently)
could be misused for permanent denial of service. status code could be misused for permanent denial of service.
All applicable "Client Error 4xx" or "Server Error 5xx" status codes All applicable Client Error 4xx or Server Error 5xx status codes MAY
MAY be used to inform the client about errors. be used to inform the client about errors. Whenever a client
receives an HTTP response with a status code in the 2xx, 4xx, or 5xx
ranges, it MUST support handling response message content containing
a CMP response PKIMessage.
3.4. Header Fields 3.4. Header Fields
The Internet Media Type "application/pkixcmp" MUST be set in the HTTP The Internet Media Type "application/pkixcmp" MUST be set in the HTTP
Content-Type header field when conveying a PKIMessage. "Content-Type" header field when conveying a PKIMessage.
The Content-Length header field SHOULD be provided, giving the length
of the ASN.1-encoded PKIMessage.
3.5. Communication Workflow 3.5. Communication Workflow
In CMP, most communication is initiated by the EEs where every CMP In CMP, most communication is initiated by the EEs where every CMP
request triggers a CMP response message from the CA or RA. request triggers a CMP response message from the CA or RA.
The CMP Announcement messages described in Section 3.7 are an The CMP announcement messages described in Section 3.7 are an
exception. Their creation may be triggered by certain events or done exception. Their creation may be triggered by certain events or done
on a regular basis by a CA. The recipient of the Announcement only on a regular basis by a CA. The recipient of the announcement only
replies with an HTTP status code acknowledging the receipt or replies with an HTTP status code acknowledging the receipt or
indicating an error, but not with a CMP response. indicating an error, but not with a CMP response.
If the receipt of an HTTP request is not confirmed by receiving an If the receipt of an HTTP request is not confirmed by receiving an
HTTP response, it MUST be assumed that the transferred CMP message HTTP response, it MUST be assumed that the transferred CMP message
was not successfully delivered to its destination. was not successfully delivered to its destination.
3.6. HTTP Request-URI 3.6. HTTP Request-URI
Each CMP server on a PKI management entity supporting HTTP or HTTPS Each CMP server on a PKI management entity supporting HTTP or HTTPS
transfer MUST support the use of the path prefix '/.well-known/' as transfer MUST support the use of the path prefix '/.well-known/' as
defined in [RFC8615] and the registered name 'cmp' to ease defined in [RFC8615] and the registered name 'cmp' to ease
interworking in a multi-vendor environment. interworking in a multi-vendor environment.
The CMP client needs to be configured with sufficient information to CMP clients have to be configured with sufficient information to form
form the CMP server URI. This is at least the authority portion of the CMP server URI. This is at least the authority portion of the
the URI, e.g., 'www.example.com:80', or the full operation path URI, e.g., 'www.example.com:80', or the full operation path segment
segment of the PKI management entity. Additionally, path segments of the PKI management entity. Additionally, path segments MAY be
MAY be added after the registered application name as part of the added after the registered application name as part of the full
full operation path to provide further distinction. The path segment operation path to provide further distinction. The path segment 'p'
'p' followed by an arbitraryLabel <name> could, for example, support followed by an arbitraryLabel <name> could, for example, support the
the differentiation of specific CAs or certificate profiles. Further differentiation of specific CAs or certificate profiles. Further
path segments, e.g., as specified in the Lightweight CMP Profile path segments, e.g., as specified in the Lightweight CMP Profile
[RFC9483], could indicate PKI management operations using an [RFC9483], could indicate PKI management operations using an
operationLabel <operation>. A valid, full CMP URI can look like operationLabel <operation>. The following list examples of valid
this: full CMP URIs:
http://www.example.com/.well-known/cmp http://www.example.com/.well-known/cmp
http://www.example.com/.well-known/cmp/<operation> http://www.example.com/.well-known/cmp/<operation>
http://www.example.com/.well-known/cmp/p/<name> http://www.example.com/.well-known/cmp/p/<name>
http://www.example.com/.well-known/cmp/p/<name>/<operation> http://www.example.com/.well-known/cmp/p/<name>/<operation>
Note that https can also be used instead of http, see item 5 in the
Security Considerations (Section 5).
3.7. Pushing of Announcements 3.7. Pushing of Announcements
A CMP server may create event-triggered announcements or generate A CMP server may create event-triggered announcements or generate
them on a regular basis. It MAY utilize HTTP transfer to convey them them on a regular basis. It MAY utilize HTTP transfer to convey them
to a suitable recipient. In this use case, the CMP server acts as an to a suitable recipient. In this use case, the CMP server acts as an
HTTP client, and the recipient needs to utilize an HTTP server. As HTTP client, and the recipient needs to utilize an HTTP server. As
no request messages are specified for those announcements, they can no request messages are specified for those announcements, they can
only be pushed to the recipient. only be pushed to the recipient.
If an EE wants to poll for a potential CA Key Update Announcement or If an EE wants to poll for a potential CA Key Update Announcement or
the current CRL, a PKI Information Request using a General Message as the current CRL, a PKI Information Request using a General Message as
described in Appendix D.5 of [I-D.ietf-lamps-rfc4210bis] can be used. described in Appendix D.5 of [I-D.ietf-lamps-rfc4210bis] can be used.
When pushing Announcement messages, PKIMessage structures are sent as When pushing announcement messages, PKIMessage structures MUST be
the entity-body of an HTTP POST request. sent as the content of an HTTP POST request.
Suitable recipients for CMP announcements might, for example, be Suitable recipients for CMP announcements might, for example, be
repositories storing the announced information, such as directory repositories storing the announced information, such as directory
services. Those services listen for incoming messages, utilizing the services. Those services listen for incoming messages, utilizing the
same HTTP Request-URI scheme as defined in Section 3.6. same HTTP Request-URI scheme as defined in Section 3.6.
The following types of PKIMessage are announcements that may be The following types of PKIMessage are announcements that may be
pushed by a CA. The prefixed numbers reflect ASN.1 numbering of the pushed by a CA. The prefixed numbers reflect ASN.1 tags of the
respective element. PKIBody structure (Section 5.1.2 of [I-D.ietf-lamps-rfc4210bis]).
[15] CA Key Update Announcement [15] CA Key Update Announcement
[16] Certificate Announcement [16] Certificate Announcement
[17] Revocation Announcement [17] Revocation Announcement
[18] CRL Announcement [18] CRL Announcement
CMP Announcement messages do not require any CMP response. However, CMP announcement messages do not require any CMP response. However,
the recipient MUST acknowledge receipt with an HTTP response having the recipient MUST acknowledge receipt with an HTTP response having
an appropriate status code and an empty body. When not receiving an appropriate status code and an empty content. When not receiving
such a response, it MUST be assumed that the delivery was not such a response, it MUST be assumed that the delivery was not
successful. If applicable, the sending side MAY try sending the successful. If applicable, the sending side MAY try sending the
Announcement again after waiting for an appropriate time span. announcement again after waiting for an appropriate time span.
If the announced issue was successfully stored in a database or was If the announced issue was successfully stored in a database or was
already present, the answer MUST be an HTTP response with a "201 already present, the answer MUST be an HTTP response with a 201
Created" status code and an empty message body. (Created) status code and an empty content.
In case the announced information was only accepted for further In case the announced information was only accepted for further
processing, the status code of the returned HTTP response MAY also be processing, the status code of the returned HTTP response MAY also be
"202 Accepted". After an appropriate delay, the sender may then try 202 (Accepted). After an appropriate delay, the sender may then try
to send the Announcement again and may repeat this until it receives to send the announcement again and may repeat this until it receives
a confirmation that it has been successfully processed. The a confirmation that it has been successfully processed. The
appropriate duration of the delay and the option to increase it appropriate duration of the delay and the option to increase it
between consecutive attempts should be carefully considered. between consecutive attempts should be carefully considered.
A receiver MUST answer with a suitable 4xx or 5xx HTTP error code A receiver MUST answer with a suitable 4xx or 5xx error code when a
when a problem occurs. problem occurs.
3.8. HTTP Considerations
While all defined features of the HTTP protocol are available to
implementations, they SHOULD keep the protocol utilization as simple
as possible. For example, there is no benefit in using chunked
Transfer-Encoding, as the length of an ASN.1 sequence is known when
starting to send it.
There is no need for the clients to send an "Expect" request-header
field with the "100-continue" expectation and wait for a "100
Continue" status as described in Section 8.2.3 of [RFC9112]. The CMP
payload sent by a client is relatively small, so having extra
messages exchanged is inefficient, as the server will only seldom
reject a message without evaluating the body.
4. Implementation Considerations 4. Implementation Considerations
Implementors should be aware that implementations might exist that Implementers should be aware that other implementations might exist
use a different approach for transferring CMP over HTTP, because that use a different approach for transferring CMP over HTTP.
RFC 6712 [RFC6712] has been under development for more than a decade. Further, implementations based on earlier I-Ds that led to [RFC6712]
Further, implementations based on earlier drafts of RFC 6712 might use an unregistered "application/pkixcmp-poll" Media Type.
[RFC6712] might use an unregistered "application/pkixcmp-poll" MIME Conforming implementations MAY handle this type like "application/
type. pkixcmp".
5. Security Considerations 5. Security Considerations
The following aspects need to be considered by implementers and The following aspects need to be considered by implementers and
users: users:
1. There is the risk for denial-of-service attacks through resource 1. There is the risk for denial-of-service attacks through resource
consumption by opening many connections to an HTTP server. consumption by opening many connections to an HTTP server.
Therefore, idle connections should be terminated after an Therefore, idle connections should be terminated after an
appropriate timeout; this may also depend on the available free appropriate timeout; this may also depend on the available free
resources. After sending a CMP Error Message with PKIStatus resources. After sending a CMP error message with PKIStatus
other than "waiting", the server should close the connection, other than "waiting", the server should close the connection,
even if the CMP transaction is not yet fully completed. even if the CMP transaction is not yet fully completed.
2. Without being encapsulated in effective security protocols, such 2. Without being encapsulated in effective security protocols, such
as Transport Layer Security (TLS) [RFC5246] or [RFC8446], there as Transport Layer Security (TLS) [RFC5246] or [RFC8446], or
is no integrity protection at the HTTP protocol level. without using HTTP digest [RFC9530] there is no integrity
Therefore, information from the HTTP protocol should not be used protection at the HTTP level. Therefore, information from the
to change state of the transaction. HTTP should not be used to change state of the transaction,
regardless of whether any mechanism was used to ensure the
authenticity or integrity of HTTP messages (e.g., TLS or HTTP
digests).
3. Client users should be aware that storing the target location of 3. Client users should be aware that storing the target location of
an HTTP response with the "301 Moved Permanently" status code an HTTP response with the 301 (Moved Permanently) status code
could be exploited by a man-in-the-middle attacker trying to could be exploited by a meddler-in-the-middle attacker trying to
block them permanently from contacting the correct server. block them permanently from contacting the correct server.
4. If no measures to authenticate and protect the HTTP responses to 4. If no measures to authenticate and protect the HTTP responses to
pushed Announcement messages are in place, their information pushed announcement messages are in place, their information
regarding the Announcement's processing state may not be trusted. regarding the announcement's processing state may not be trusted.
In that case, the overall design of the PKI system must not In that case, the overall design of the PKI system must not
depend on the Announcements being reliably received and processed depend on the announcements being reliably received and processed
by their destination. by their destination.
5. CMP provides inbuilt integrity protection and authentication. 5. CMP provides inbuilt integrity protection and authentication.
The information communicated unencrypted in CMP messages does not The information communicated unencrypted in CMP messages does not
contain sensitive information endangering the security of the PKI contain sensitive information endangering the security of the PKI
when intercepted. However, it might be possible for an when intercepted. However, it might be possible for an
eavesdropper to utilize the available information to gather eavesdropper to utilize the available information to gather
confidential technical or business critical information. confidential personal, technical, or business critical
Therefore, users of the HTTP transfer for CMP messages might want information. The protection of the confidentiality of CMP
to consider using HTTP over TLS according to [RFC9110] or virtual messages together with an initial authentication of the RA/CA
private networks created, for example, by utilizing Internet before the first CMP message is transmitted ensures the privacy
Protocol Security according to [RFC4301]. of the EE requesting certificates. Therefore, users of the HTTP
transfer for CMP messages should consider using HTTP over TLS
according to [RFC9110] or using virtual private networks created,
for example, by utilizing Internet Protocol Security according to
[RFC7296].
6. IANA Considerations 6. IANA Considerations
The reference to [RFC2510] at https://www.iana.org/assignments/media- The reference to [RFC2510] at https://www.iana.org/assignments/media-
types/media-types.xhtml should be replaced with a reference to this types/media-types.xhtml should be replaced with a reference to this
document. document.
The reference to [RFC4210] at https://www.iana.org/assignments/core- The reference to [RFC4210] at https://www.iana.org/assignments/core-
parameters/core-parameters.xhtml should be replaced with a reference parameters/core-parameters.xhtml should be replaced with a reference
to this document. to this document.
skipping to change at page 9, line 36 skipping to change at page 9, line 47
The reference to [RFC9480] at https://www.iana.org/assignments/well- The reference to [RFC9480] at https://www.iana.org/assignments/well-
known-uris/well-known-uris.xhtml and known-uris/well-known-uris.xhtml and
https://www.iana.org/assignments/cmp/cmp.xhtmlshould should be https://www.iana.org/assignments/cmp/cmp.xhtmlshould should be
replaced with a reference to this document. replaced with a reference to this document.
No further action by the IANA is necessary for this document or any No further action by the IANA is necessary for this document or any
anticipated updates. anticipated updates.
7. Acknowledgments 7. Acknowledgments
The authors of this document wish to thank Tomi Kause and Martin The authors wish to thank Tomi Kause and Martin Peylo, the original
Peylo, the original authors of [RFC6712], for their work. authors of [RFC6712], for their work.
We also thank all reviewers of this document for their valuable We also thank all reviewers for their valuable feedback.
feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/rfc/rfc1945>. <https://www.rfc-editor.org/rfc/rfc1945>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>. <https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>. June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.
[I-D.ietf-lamps-rfc4210bis] [I-D.ietf-lamps-rfc4210bis]
Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray, Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate "Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", Work in Progress, Internet- Management Protocol (CMP)", Work in Progress, Internet-
Draft, draft-ietf-lamps-rfc4210bis-13, 2 September 2024, Draft, draft-ietf-lamps-rfc4210bis-14, 9 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
rfc4210bis-13>. rfc4210bis-14>.
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[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 11, line 11 skipping to change at page 11, line 26
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/rfc/rfc2510>. <https://www.rfc-editor.org/rfc/rfc2510>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005, DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/rfc/rfc4210>. <https://www.rfc-editor.org/rfc/rfc4210>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>. <https://www.rfc-editor.org/rfc/rfc5246>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712, Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012, DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/rfc/rfc6712>. <https://www.rfc-editor.org/rfc/rfc6712>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/rfc/rfc7296>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9530, February 2024,
DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9530>.
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/rfc/rfc9205>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
Appendix A. History of Changes Appendix A. 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 07 -> 08:
* Addressed HTTPDIR, SECDIR, OPSDIR and ARTART review comments
* Aligned the terminology with https://httpwg.org/admin/editors/
style-guide
* Implemented editorial changes proposed by OPSDIR reviewer
* Removed requirement to support HTTP/1.0
* Added normative language in Sections 3.3 and 3.7 for clarity
* Added the requirement to provide any HTTP response message content
to the application
* Removed the paragraph on the "Content-Length" header field and
Section 3.8 to reduce redundancy with current versions HTTP/1.1
From version 06 -> 07: From version 06 -> 07:
* Updated the the page header to 'HTTP Transfer for CMP' * Updated the the page header to 'HTTP Transfer for CMP'
* Removed one instruction to RFC Editors * Removed one instruction to RFC Editors
* Deprecated PKIMessages as plural of PKIMessage to prevent * Deprecated PKIMessages as plural of PKIMessage to prevent
confusion with ASN.1 type PKIMessages confusion with ASN.1 type PKIMessages
* Fixed some nits in Section 1 * Fixed some nits in Section 1
 End of changes. 55 change blocks. 
152 lines changed or deleted 191 lines changed or added

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