Subject: Re: [lamps] AD Review of draft-ietf-lamps-cmp-updates-17

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 2 Mar 2022 12:44:35 +0000

Roman, Russ

I would like to submit an update of the I-D next Monday.
Is there any feedback on the changes proposed below?

Hendrik

> Von: Spasm <[email-masked]> Im Auftrag von Brockhaus, Hendrik
> Gesendet: Dienstag, 15. Februar 2022 16:51
> 
> Roman
> 
> After aligning with John and David, I like to update and complete our
> proposals to address your comments.
> If you are fine with our proposals, I will submit an update of the document.
> 
> @Russ, could you look into Romans first comment and consider adding this
> point to the shepherd report.
> 
> > Von: Spasm <[email-masked]> Im Auftrag von Brockhaus, Hendrik
> > Gesendet: Samstag, 5. Februar 2022 09:34
> >
> > Roman
> >
> > Many thanks for your review and for your valuable comments.
> > Please see my responses below. Any feedback is welcome.
> >
> > @Lijun, please have a look at Romans comment regarding errata #5731.
> >
> > > Von: Spasm <[email-masked]> Im Auftrag von Roman Danyliw
> > > Gesendet: Freitag, 4. Februar 2022 20:26
> > >
> > > Hi!
> > >
> > > I performed an AD review on draft-ietf-lamps-cmp-updates-17.  Thanks
> > > for this update to CMP and the careful edits this required.  My
> > > feedback is below.
> > >
> > > ** I predict that the IESG will have strong feedback on number
> > > OLD/NEW style updates this text is performing on RFC4120 and the
> > > complexity in trying to understand how to apply them; and to a much
> > > lesser degree the same feedback on RFC6712.  Can the rational for this
> "patch-style"
> > > approach instead of publishing a new bis document(s) be documented
> > > in this thread and/or in the shepherd report.
> >
> > Thank you for this feedback.
> > I agree, a RFC4210bis document would have been easier to read. The
> > idea of providing the CMP Updates document was to only provide those
> > changes to normative text of RFC4210 required for the Lightweight CMP
> > Profile in a separate document and not to rework the hole RFC.
> > There was discussion on this within the working group and specifically
> > with Jim Schaad. Back then, Jim proposed to use the approach he used
> > for updating CMC with RFC6402. I mentioned this briefly in the
> > Acknowledgements section.
> > This explanation could be added to the shepherd report.
> 
> We propose to add the following paragraph to Section 1.
> 
> NEW:
> As the main content of RFC4210 and RFC6712 stays unchanged, this
> document lists all sections that are updated, replaced, or added to the
> current text of the  respective RFCs.
> 
> >
> > >
> > > ** Thanks for addressing RFC4210's errata .  How should #5731 be
> > > handled
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .rfc-
> editor.org%2Ferrata%2Feid5731&amp;data=04%7C01%7Chendrik.brockhaus
> %40siemens.com%7C10296a6e49944775258d08d9f09b0441%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C637805370853678364%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=lJ%2BVxXG%2BqRB326qhsZuieV
> XGuxRFi1wdw1satVgQmbk%3D&amp;reserved=0)?
> >
> > I saw the errata and I support the point Lijun made.
> > I addressed this in the Lightweight CMP Profile document. I did not
> > want to make any changes to the profile provided in Appendixes D and E
> > of RFC4210 that focusses more on humans.
> > If required, I could add a generic rule to Section D.1 explaining this.
> >
> > @Lijun, what would be your suggestion?
> 
> After looking closer into this topic, we figured out that we already address
> the consideration Lijun mentions in Section 2.21. "Add Section 8.4 - Private
> keys for certificate signing and CMP message protection". I propose to add a
> reference to errata #5731 to the introduction of this section.
> 
> OLD:
> Insert this section after Section 8.3:
> 
> NEW:
> Insert this section after Section 8.3 (Note: This fixes Errata ID 5731):
> 
> >
> > >
> > > ** Section 2.2. Editorial.
> > > OLD
> > >  The mechanism to prove this delegation explained in this  section
> > > offers an automatic way of checking the authorization of such
> delegation.
> > >
> > > NEW
> > > This section provides a mechanism to both prove this delegation and
> > > enable an automated means for checking the authorization of this
> > delegation.
> >
> > Thanks, I will change the text accordingly.
> >
> > >
> > > ** Section 2.6. Editorial. s/or add new extensions/or adds new
> > > extensions/
> >
> > Thanks
> >
> > >
> > > ** Section 2.6.  Per "the RA MUST set the POP RAVerified", is there
> > > a missing word here.  Perhaps set the POP <field/structure> to
> RAVerified?
> >
> > Thank you for this observation. I hope this makes it clear.
> >
> > OLD:
> > If the changes made by the RA to PKIMessage break the POP of a
> > certificate request, the RA MUST set the POP RAVerified.
> >
> > NEW:
> > If the changes made by the RA to PKIMessage break the POP of a
> > certificate request, the RA MUST set the popo field to RAVerified.
> >
> > >
> > > ** Section 2.6
> > >   The RA collects several messages that are to be forwarded in the
> > >   same direction and forwards them in a batch.  In communication to
> > >   the CA request messages and in communication from the CA response
> > >   or announcement messages will be collected.
> > >
> > > I'm having trouble following the guidance.  The first sentence seems
> > > to be talking about batching messages in the same direction.  I
> > > think this means things sent from the RA-to-the-CA; or from the
> > > CA-to-the-RA.  However, the second sentence doesn't seem to parse.
> > >
> > > Is this second sentence the equivalent of saying:
> > >
> > > NEW
> > > Either the CA request messages from the RA, or the CA response and
> > > announcement messages can be collected and forwarded as a batch?
> >
> > You are right. This was not well expressed.
> >
> > NEW:
> > A PKI management entity collects several messages that are to be
> > forwarded in the same direction and forwards them in a batch.  Request
> > messages can be transferred as batch from the RA-to-the-CA; response
> > or announce messages can be transferred as batch from the CA-to-the-RA.
> >
> 
> After discussion with the co-authors, we would like to propose this new text.
> 
> NEW:
> A PKI management entity collects several messages that are to be forwarded
> in the same direction and forwards them in a batch.  Request messages can
> be transferred as batch upstream (towards the CA); response or announce
> messages can be transferred as batch downstream (towards an RA, but not
> to the EE).
> 
> > >
> > > ** Section 5.2.2.  Should "Therefore, it is recommended to use
> > > EnvelopedData" used the normative "RECOMMENDED" language?
> >
> > Yes, I will change it.
> >
> > >
> > > ** Section 2.9.  Editorial.  s/neither in the OID nor in the
> > > parameters/either in the OID or in the parameters/
> >
> > Thanks
> 
> This should even be more clear.
> 
> Old:
>    The hashAlg field SHOULD be used only in exceptional cases where the
>    signatureAlgorithm of the certificate to be confirmed does not
>    specify a hash algorithm, neither in the OID nor in the parameters.
> 
> New:
>    The hashAlg field SHOULD be used only in exceptional cases where the
>    signatureAlgorithm of the certificate to be confirmed does not
>    specify a hash algorithm in the OID or in the parameters.
> 
> >
> > >
> > > ** Section 2.18. Typo. s/.././
> >
> > Thanks
> >
> > >
> > > ** Section 2.22.
> > >  For the case of a PKI management operation that delivers a new
> > > trust anchor (e.g., a root CA certificate) using caPubs or genm (a)
> > > that is not concluded in a timely manner
> > >
> > > What circumstance is this describing?
> >
> > When messages are MAC-protected, brut force attacks could break the
> > security. When providing a trust anchor in a MAC-protected message not
> > in a timely manner, an attacker has more time to break the MAC-
> protection.
> >
> > >
> > > ** Section 2.22
> > >    For other cases it is recommended to (a) use a shared
> > >    secret information of possibly low security strength (e.g., a
> > >    password) only for a single PKI management operation (b) use a
> > >    shared secret information with an entropy that at least matches the
> > >    security strength of the key material being managed by the
> > >    operation.
> > >
> > > This seems written like it endorses a risky practice.  Perhaps:
> > >
> > > NEW
> > > The shared secret information should have an entropy that at least
> > > matches the security strength of the key material being managed by
> > > the
> > operation.
> > > Certain use cases may require the use of a low security strength
> > > (e.g., a human generated password) secret information.  It is
> > > recommended that such secret information be limited to a a single
> > > PKI
> > management operation.
> >
> > Thanks, I like this wording.
> 
> Hopefully, this proposal is even more clear.
> 
> NEW:
> The shared secret information should have an entropy that at least  matches
> the security strength of the key material being managed by  the operation.
> Certain use cases may require shared secret information that may be of a
> low security strength, e.g., a human generated password. It is
> RECOMMENDED that such secret information be limited to a single PKI
> management operation.
> 
> >
> > >
> > > ** Section 2.23
> > >  The provider of trust anchors, which typically will be an RA
> > > involved in configuration management of its clients, MUST NOT
> > > include to-be- trusted CA certificates in a CMP message unless it
> > > can take responsibility for making the recipient trust them.  When
> > > doing so, it MUST exert the same due diligence as for its own trust
> anchors.
> > >
> > > Could the words around "making the recipient trust them" be clarified?
> > > I'm struggling to understand how the "RA can take responsibility"
> > > for end-point behavior beyond conveying the new configuration.  Is the
> intent:
> > >
> > > NEW
> > > A provider of trust anchors, which typically will be an RA
> > > information in configuration management of its clients, MUST not
> > > include to-be-trusted CA certificates in a CMP message unless the
> > > specific deployment scenario can ensure that the receiving end-point
> > > can successful load these anchors into the appropriate trust store.
> > > Per the second sentence "When doing so ...", could the intent of the
> > > "due diligence" be clarified?  I'm assuming that the RA exercises
> > > some kind of care in loading an initial set of anchors.  Is this
> > > text is repeating that whatever it did last time it should do again
> > > for these new trust anchors?  My thought would have been that this
> > > would have been left to local policy and configuration.
> >
> > Thanks for your suggestion.
> >
> > NEW:
> > A provider of trust anchors, which may be an RA involved in
> > configuration management of its clients, MUST NOT include
> > to-be-trusted CA certificates in a CMP message unless the specific
> > deployment scenario can ensure that the receiving end-point can
> > successful load these anchors into the appropriate trust store.
> >
> > I think this sentence is clear and the second sentence is not strictly needed.
> 
> Hopefully, this proposal is even more clear.
> 
> NEW:
> A provider of trust anchors, which may be an RA involved in configuration
> management of its clients, MUST NOT include to-be-trusted CA certificates in
> a CMP message unless the specific deployment scenario can ensure that it is
> adequate that the receiving EE trusts these certificates, e.g., by loading them
> into its trust store.
> 
> >
> > >
> > > ** Section 2.23
> > >   Moreover, the EE MUST verify that the sender is an authorized source
> > >   of trust anchors.  This authorization is typically indicated using
> > >   shared secret information or with a signature-based message
> > >   protection using a certificate issued by a PKI that is explicitly
> > >   authorized for this purpose.
> > >
> > > Would local policy also play a role in this authorization decision?
> >
> > Yes, such authorization would be governed by local policy.
> >
> > NEW:
> > Moreover, the EE MUST verify that the sender is an authorized source
> > of trust anchors.  This authorization is governed by local policy and
> > typically indicated using shared secret information or with a
> > signature-based message protection using a certificate issued by a PKI
> > that is explicitly authorized for this purpose.
> >
> > >
> > > ** Section 2.24.
> > >    Add the following paragraphs after the third paragraph of the
> > >    section:
> > >
> > > Shouldn't this text replace the fourth paragraph, "No further action
> > > by the IANA is necessary for this document or any anticipated updates."?
> >
> > You are right.
> >
> > NEW:
> > Replace the fourth paragraph of this section with the following text:
> >
> > >
> > > ** Section 2.25.  Editorial. s/For use of EnvelopeData/When
> > > EnvelopeData is used/
> >
> > Thanks
> 
> We also updated the second half of the sentence.
> 
> OLD:
>       For use of EnvelopedData this is in the decrypted bytes of
>       encryptedContent field and for use of EncryptedValue this is in
>       the decrypted bytes of the encValue field.
> 
> NEW:
>       When EnvelopedData is used, this is in the decrypted bytes of
>       encryptedContent field. When EncryptedValue is used, this is in
>       the decrypted bytes of the encValue field.
> 
> >
> > >
> > > ** Section 2.25
> > >     When using EnvelopedData the localKeyId attribute as specified in
> > >     RFC 2985 [RFC2985] and when using EncryptedValue the valueHint
> > >     field MAY contain a key identifier
> > >
> > > Isn't the use of localKeyId (EnvelopedData) and valueHint
> > > (EncrypedValue) mutually exclusive? Is so, the text should likely read:
> > >
> > > NEW
> > > Either the localKeyId attribute of EnvelopedData as specified in RFC
> > > 2985 [RFC2985] or the valueHint field of EncryptedValue MAY contain
> > > a key identifier ...
> >
> > Yes both are mutually exclusive. Thanks for rephrasing.
> >
> > >
> > > ** Section 3.4. Should this text replace the paragraph of "No
> > > further action by the IANA is necessary for this document or any
> > > anticipated updates" in Section 6 of RFC6712 instead of being
> > > appended to the
> > section?
> >
> > Yes.
> >
> > NEW:
> > Replace the second paragraph of this section with the following text:
> 
> Regards,
> Hendrik
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.b
> rockhaus%40siemens.com%7C10296a6e49944775258d08d9f09b0441%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637805370853678364%7C
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=W6fEJJzzzzXTDdK%2BNf
> OZzuk9olvtx7fZDF6y%2Beeeau8%3D&amp;reserved=0

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Mar 2022 13:18:55 -0500

I do not have any concerns, but if Roman has started AD Evaluation, I do not want to reset that process.

Russ

> On Mar 2, 2022, at 7:44 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Roman, Russ
> 
> https://www.ietf.org/mailman/listinfo/spasm