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

[Roman Danyliw <[e-mail]>]

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