On Tue, 5 Nov 2024, Brockhaus, Hendrik wrote:
Claudio
Thank you for your review and your comments. I am sorry for responding
so late. The co-authors and I wanted to consolidate the feedback to the
different reviews.
Please see my responses to your comments inline below.
The latest version of the draft ready for submission and a diff to the latest version on datatracker are available on github:
- https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.html
- https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-rfc6712bis&url_2=https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.txt
Please let me know if the proposed changes sufficiently address your
comments.
Hello Hendrik and all,
yes I think with the updates all my comments are addressed !
for me now it is "ready to go" :-)
all the best
Hendrik
Von: Claudio Allocchio via Datatracker <noreply@xxxxxxxx>
Gesendet: Montag, 21. Oktober 2024 08:16
Reviewer: Claudio Allocchio
Review result: Almost Ready
Good morning, I'm the assigned reviewer from the ARTART area.
This draft is almost ready but I have some suggestions before it is published.
1) as any document "updating" a series of previous RFCs, ensuring an easy and
crystal clear reading of it compared to the other documents being obsoleted or
updated is tricky. I generally suggest some further detailed wording, or a detailed
dedicated "updates and obsolets" section where it is clearly listed which sections of
the previous documents are affected: something like
* RFCxxxx section x.y.z, <text> is obsoleted
etc...
[HB] Thank you for pointing this out. I changed the Abstract and Section 1.2 to improve this.
Abstract
OLD
It includes the updates on RFC 6712 specified in CMP Updates RFC 9480
Section 3 and obsoleted both documents. These updates introduce CMP
URIs using a Well-known prefix.
NEW
It includes the updates to RFC 6712 specified in RFC 9480 Section 3. These
updates introduce CMP URIs using a Well-known prefix. It obsoletes RFC 6712
and together with I-D.ietf-lamps-rfc4210bis and it also obsoletes RFC 9480.
Section 1.1
OLD
CMP Updates [RFC9480] updated [RFC6712], supporting the PKI
management operations specified in the Lightweight CMP Profile
[RFC9483], in the following areas:
NEW
CMP Updates [RFC9480] updated Section 3.6 of [RFC6712],
supporting the PKI management operations specified in the Lightweight
CMP Profile [RFC9483], in the following areas:
Section 1.2
OLD
This document obsoletes RFC 6712 [RFC6712]. It includes the changes
specified by CMP Updates [RFC9480] Section 3 as described in
Section 1.1 and added the requirement on providing the Content-Length
header field in Section 3.4.
NEW
This document obsoletes [RFC6712]. It includes the changes specified in Section
3 of [RFC9480] as described in Section 1.1 of this document, removed the
requirement to support HTTP/1.0 [RFC1945] in accordance with Section 4.1 of
[RFC9205] and removed Section 3.8 of [RFC6712] as it contains information
redundant with current HTTP specification.
2) clarification about the use of the wide range of HTTP protocol options (section
3.8). "SHOULD" is inappropriate normative here --> "should".
Furthermore, it may be more useful to create a list of suggested HTTP features to
use or mandatory HTTP features to use, so that all implementation try to stick with
it, instead of just suggesting not to use the not needed HTTP parts.
[HB] Thank you for pointing this out. We dropped the complete Section 3.8.
3) section 3.6 examples: https instead of http ?
[HB] We would prefer keeping "http". The TLS layer is an optional addition, if needed, because
- CMP does not necessarily require transport layer protection if data-origin authentication using MAC-based or signature-based message protection is applied.
- There are cases where an entity initially has no certificate and no trust anchor. In these cases, it would even be unable to perform TLS server authentication.
See also Section 5 Topic 5.
Anyhow, we added the following note to the end of Section 3.6:
NEW
Note that https can also be used instead of http, see item 5 in the Security
Considerations (Section 5).
4) section 4: shall we suggest also "what to do" (a coherent behaviour) when we hit
implementations with an old non standard approach in transferring CMP over
HTTP?
[HB] We updated Section 4 as follows:
OLD
Implementors should be aware that implementations might exist that
use a different approach for transferring CMP over HTTP, because
RFC 6712 [RFC6712] has been under development for more than a
decade. Further, implementations based on earlier drafts of RFC 6712
[RFC6712] might use an unregistered "application/pkixcmp-poll" MIME
type.
NEW
Implementers should be aware that other implementations might exist that use
a different approach for transferring CMP over HTTP. Further, implementations
based on earlier I-Ds the led to [RFC6712] might use an unregistered
"application/pkixcmp-poll" Media Type. Conforming implementations MAY
handle this type like "application/pkixcmp".
all the rest is ok for me.
all the best
Claudio
------------------------------------------------------------------------------
Claudio Allocchio G A R R Claudio.Allocchio@xxxxxxx
Senior Manager and Advisor
tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio;
fax: +39 040 3758565 Research Network P=garr; A=garr; C=it;
PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
