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

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

Francesca

Thank you for providing you comments and your voting.

> Von: Francesca Palombini via Datatracker <[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.