Re: [lamps] Francesca Palombini's No Objection on draft-ietf-lamps-cmp-updates-22: (with COMMENT)

["Brockhaus, Hendrik" <[e-mail]>]

Hi Francesca

In CMP Algorithms Section 7 there are two Algorithm Use Profiles. In Section 7.2 there is a profile to be used with the Lightweight CMP Profile supporting automated machine-2-machine PKI management operations. Here we decided not to give mandatory requirements, but only guidance, as the set of algorithms to use heavily depend on the keys and certificates to be managed and therefor on the capabilities of the target devices.
This consequently means, it is up to the industrial solution to define the set of algorithms that must be supported.

Hendrik

Von: Francesca Palombini <[e-mail]>
Gesendet: Mittwoch, 29. Juni 2022 20:45
An: Brockhaus, Hendrik (T CST SEA-DE) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: Re: Francesca Palombini's No Objection on draft-ietf-lamps-cmp-updates-22: (with COMMENT)

Hi Hendrik,

Thanks for the quick reply! All sounds good to me, thanks for addressing my comments. I do have one additional question, regarding 1. - thanks for clarifying that my interpretation was incorrect and that MAY was actually the correct term here. Then I have a follow up question: if the algorithm used is not one defined in CMP Algorithms, what other options are there, and how to make sure that both parties agree? Is that also established out-of-bands?

Francesca

From: Brockhaus, Hendrik <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 29 June 2022 at 19:14
To: Francesca Palombini <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: AW: Francesca Palombini's No Objection on draft-ietf-lamps-cmp-updates-22: (with COMMENT)
Francesca

After sleeping the topic on IANA Considerations over, I agree with you proposal of deleting Section 2.25 and 3.4 completely.
When doing the -bis documents, we will not any more patch the IANA Considerations sections of the original RFCs because the IANA action was already taken by this upcoming RFC. Therefore, we can safely delete the two sections containing the change instructions.
Thank you for this comment!

Hendrik

> Von: Brockhaus, Hendrik (T CST SEA-DE)
>
> Francesca
>
> Thank you for providing you comments and your voting.
>
> > Von: Francesca Palombini via Datatracker <[e-mail]<mailto:[e-mail]>>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you for the work on this document.
> >
> > I have a few minor comments, hopefully easy to fix; answers are appreciated.
> >
> > Francesca
> >
> > 1. -----
> >
> >    previous PKI management operation).  PKIProtection will contain a MAC
> >    value and the protectionAlg MAY be one of the options described in
> >    CMP Algorithms [I-D.ietf-lamps-cmp-algorithms].  The
> > PasswordBasedMac
> >
> > FP: I think the correct term here is MUST rather than MAY, otherwise
> > this seem to imply that the protectionAlg can be something different as well.
>
> CMP Algorithms dose not aim to provide a complete list of all possible
> algorithms to be used with CMP.
> As stated in the Abstract of CMP Algorithms:
>    This document describes the conventions for using several
>    cryptographic algorithms with the Certificate Management Protocol
>    (CMP).
> And in its Introduction:
>    This document lists current cryptographic algorithms usable with CMP
>    to offer an easier way maintaining the list of suitable algorithms
>    over time.
> As I would read MUST, it would unnecessarily limit an implementation to only
> use algorithms from CMP Algorithms.
>
> >
> > 2. -----
> >
> >    Note: In case several EC curves are supported, several id-ecPublicKey
> >    elements need to be given, one per named curve.
> >
> > FP: I could not find id-ecPublicKey in RFC 4210, could you give more
> > context where this element is defined?
>
> AlgorithmIdentifier used id-ecPublicKey to specify named curved as defined in
> RFC 5480.
>
> New text:
> Note: In case several EC curves are supported, several id-ecPublicKey elements
> as defined in RFC 5480 [RFC5480] need to be given, one per named curve.
>
> >
> > 3. -----
> >
> > Section 2.25 and 3.4 - IANA considerations
> >
> > FP: Given that Section 4 does now a full update of the IANA
> > considerations (as a result from Paul's comment, which I believe was a
> > necessary improvement), it seems to me as Section 2.25 and 3.4 have
> > become useless. I suggest to just remove those to avoid the redundancy
> > (and the risk for future updates that will modify one section but not the other).
>
> I see your point.
> But deleting Section 2.25 and 3.4 completely would contradict the style of the
> document and the reasoning of the changes to the IANA Considerations sections
> of RFC 4210 and RFC 6712 would be lost.
>
> If people think it eases reading, I could replace the content of the changes in
> Section 2.25 and 3.4 with references to Section 4.
> For more clarity I would put the text in Section 4 in separates subsections.
>
> New text:
> 2.25.  Update Section 9 - IANA Considerations
>
>    Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of
>    that document.  As this document defines a new Extended Key Usage,
>    the IANA Considerations need to be updated accordingly.
>
>    Replace the fourth paragraph of this section with the text provided in Section
> 4.1.
>
> 3.4.  Update Section 6. - IANA Considerations
>
>    Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of
>    that document.  As this document defines a new well-known URI suffix,
>    the IANA Considerations need to be updated accordingly.
>
>    Replace the second paragraph of this section with the text provided in Section
> 4.2.
>
> But still the two new subsections (6.1 and 6.2) introduced in Section 3.4  would
> get lost.
> Therefore, I personally dislike this approach.
>
> As there was no objection to the original text in -21 by the IANA experts, I would
> prefer deleting the copied text from Section 4 :-) To make it the text more
> explicit, I could change the original text in -21 in Section 4.
>
> Old text:
>    This document contains an update to the IANA Consideration sections
>    to be added to [RFC4210] and [RFC6712].
>
> New text:
>    This document contains an update to the IANA Consideration sections
>    to be added to [RFC4210] in Section 2.25 and [RFC6712] in 3.4.
>
> Which approach do people prefer?
>
> >
> > 4. -----
> >
> >    [RFC4210].  This document redirects to the new algorithm profile as
> >    specified in Appendix A.1 of CMP Algorithms
> >    [I-D.ietf-lamps-cmp-algorithms].
> >
> > ...
> >
> >    For specifications of algorithm identifiers and respective
> >    conventions for conforming implementations, please refer to CMP
> >    Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms].
> >
> > FP: There is no Appendix A.1 of [I-D.ietf-lamps-cmp-algorithms]. Did
> > you mean Section 7?
>
> Very good point. Thank you for spotting this.
> I will change Appendix A.1 to Section 7.1.
>
> >
> > 5. -----
> >
> > FP: Nits reports the following:
> >
> >   == Unused Reference: 'RFC2510' is defined on line 1580, but no explicit
> >      reference was found in the text
> >
> > RFC 2510 does appear in the document, but only in the section header,
> > I would suggest adding the reference in the text as well.
>
> I will update Section 2.21.
>
> New text:
>    Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a
>    client sending a cmp2000 message talking to a cmp1999 server as specified
>    RFC 2510 [RFC2510].  This document extends the section to clients with any
>    higher version than cmp1999.