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

From: Roman Danyliw <[email-masked]>
Date: Fri, 4 Feb 2022 19:25:37 +0000

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.

** Thanks for addressing RFC4210's errata .  How should #5731 be handled (https://www.rfc-editor.org/verify_errata_select.php?eid=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.

** Section 2.6. Editorial. s/or add new extensions/or adds new extensions/

** 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?

** 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?

** Section 5.2.2.  Should "Therefore, it is recommended to use EnvelopedData" used the normative "RECOMMENDED" language?

** Section 2.9.  Editorial.  s/neither in the OID nor in the parameters/either in the OID or in the parameters/

** Section 2.18. Typo. s/.././

** 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?

** 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.

** 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.

** 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?

** 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."?

** Section 2.25.  Editorial. s/For use of EnvelopeData/When EnvelopeData is used/

** 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 ...

** 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?

Regards,
Roman

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Sat, 5 Feb 2022 08:34:01 +0000

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.

> 
> ** 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%2Fverify_errata_select.php%3Feid%3D5731&amp;data=04%7C01
> %7Chendrik.brockhaus%40siemens.com%7Ca37aca92ed6248c3e67608d9e814
> 297d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637795996026
> 897354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=hon%2FB2VCj
> 2BNS9dKO7evYpFgN3ST9EYyX8sqx30Zk3A%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?

>  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.

> 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.
> 
> 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.

> 
> ** Section 5.2.2.  Should "Therefore, it is recommended to use
> EnvelopedData" used the normative "RECOMMENDED" language?

Yes, I will change it.

> in the OID or in the parameters/

Thanks

> ** Section 2.18. Typo. s/.././

Thanks

> anchor (e.g., a root CA certificate) using caPubs or genm (a) that is  not
> concluded in a timely manner
> 

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.

> 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.

> 
> ** 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.

> 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.

> 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:

> ** Section 2.25.  Editorial. s/For use of EnvelopeData/When EnvelopeData is

Thanks

> 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

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 15 Feb 2022 15:50:59 +0000

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
> 
> > 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.
> >
> > 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.
> 
> 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.

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://www.rfc-editor.org/errata/eid5731)?
> 
> 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.

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):

> >  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.
> 
> > ** 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?
> 
> 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
> > 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.
> >
> 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 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.

> 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
> > 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.
> 

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.

> > 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.
> 
> 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.
> 

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.

> 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.
> > 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:

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.

> > 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 ...
> 
> > ** 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:

Regards,
Hendrik