From 6bf856a4522de4c78d5bde31e8cd2de3b4915c12 Mon Sep 17 00:00:00 2001 From: Brockhaus Date: Thu, 31 Oct 2024 18:02:24 +0100 Subject: [PATCH] Partly addressing HTTPDIR comments on rfc6712bis --- draft-ietf-lamps-rfc6712bis.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/draft-ietf-lamps-rfc6712bis.md b/draft-ietf-lamps-rfc6712bis.md index 178ef0a..7c48cee 100644 --- a/draft-ietf-lamps-rfc6712bis.md +++ b/draft-ietf-lamps-rfc6712bis.md @@ -75,11 +75,12 @@ informative: RFC6712: RFC8446: RFC9110: + RFC9112: RFC9205: normative: RFC1945: RFC8615: - RFC9112: + RFC9530: I-D.ietf-lamps-rfc4210bis: ITU.X690.1994: @@ -198,11 +199,11 @@ conveying CMP messages. ## HTTP Versions {: id="sect-3.1"} -Implementations MUST support at least [HTTP/1.0](#RFC1945). This is because +Implementations MUST support at least HTTP/1.0 {{RFC1945}}. This is because the POST method and the Content-Type header field are available since version 1.0. -Implementations SHOULD support [HTTP/1.1](#RFC9112). This is because the +Implementations SHOULD support HTTP/1.1 {{RFC9110}} and {{RFC9112}}. This is because the Keep-Alive feature is used since version 1.1 by default, which helps transferring messages in transactions with more than one request/response pair more efficiently. @@ -229,8 +230,8 @@ in isolation. {: id="sect-3.3"} A DER-encoded {{ITU.X690.1994}} PKIMessage {{I-D.ietf-lamps-rfc4210bis}} MUST be sent as the -entity-body of an HTTP POST request. If this HTTP request is -successful, the server returns the CMP response in the body of the +content of an HTTP POST request. If this HTTP request is +successful, the server returns the CMP response in the content of the HTTP response. The HTTP response status code in this case MUST be 200; other "Successful 2xx" codes MUST NOT be used for this purpose. HTTP responses to pushed CMP Announcement messages (i.e., CA @@ -260,7 +261,7 @@ message. In line with {{Section 8.6 of RFC9110}}, the "Content-Length" header field should be provided whenever a PKIMessage is sent, giving the -length of the ASN.1-encoded PKIMessage. +length of the ASN.1 DER-encoded PKIMessage. ## Communication Workflow @@ -329,7 +330,7 @@ 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. When pushing Announcement messages, PKIMessage structures MUST be sent as -the entity-body of an HTTP POST request. +the content of an HTTP POST request. Suitable recipients for CMP announcements might, for example, be repositories storing the announced information, such as directory @@ -349,14 +350,14 @@ element. CMP Announcement messages do not require any CMP response. However, 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 successful. If applicable, the sending side MAY try sending the Announcement again after waiting for an appropriate time span. If the announced issue was successfully stored in a database or was already present, the answer MUST be an HTTP response with a "201 Created" -status code and an empty message body. +status code and an empty content. In case the announced information was only accepted for further processing, the status code of the returned HTTP response MAY also be @@ -384,7 +385,7 @@ field with the "100-continue" expectation and wait for a "100 Continue" status as described in {{Section 10.1.1 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. +reject a message without evaluating the content. @@ -411,10 +412,13 @@ users: fully completed. 1. Without being encapsulated in effective security protocols, such - as Transport Layer Security (TLS) {{RFC5246}} or {{RFC8446}}, there is no + as Transport Layer Security (TLS) {{RFC5246}} or {{RFC8446}}, or + without using HTTP digest {{RFC9530}} there is no integrity protection at the HTTP protocol level. Therefore, information from the HTTP protocol should not be used to change - state of the transaction. + 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). 1. Client users should be aware that storing the target location of an HTTP response with the "301 Moved Permanently" status code @@ -438,7 +442,7 @@ users: an initial authentication of the RA/CA before the first CMP message is transmitted ensures the privacy of the End Entities requesting certificates. Therefore, users of the HTTP transfer for CMP messages - SHOULD consider using HTTP over TLS according to o {{RFC9110}} or virtual + should consider using HTTP over TLS according to {{RFC9110}} and {{RFC9110}} or using virtual private networks created, for example, by utilizing Internet Protocol Security according to {{RFC4301}}. @@ -472,7 +476,7 @@ Note: This appendix will be deleted in the final version of the document. From version 07 -> 08: -* Addressed SECDIR, OPSDIR and ARTART review comments +* Addressed SECDIR, OPSDIR and ARTART review comments and also at least partly the HTTPDIR comments * Added normative language in Sections 3.3 and 3.7 for clarity