Re: [lamps] Comments on CMP Updates, draft-ietf-lamps-rfc4210bis-07

[Tomas Gustavsson <[e-mail]>]

Thank you.

Additional: In section 4.3 I think it's good to explicitly call out raVerified POP in a subsection. It is quite commonly used.
It is mentioned in 5.1.1.3 and 5.2.8.4 and deserves a description under 4.3 imho.

Regards,
Tomas


________________________________
From: Brockhaus, Hendrik <[e-mail]>
Sent: Thursday, January 25, 2024 5:30 PM
To: Tomas Gustavsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: AW: Comments on CMP Updates, draft-ietf-lamps-rfc4210bis-07

Hi Tomas Thank you for your feedback. There is still some work ongoing completing the work on rfc4210bis. You can see the latest editor’s copy on github. https: //lamps-wg. github. io/cmp-updates/#go. draft-ietf-lamps-rfc4210bis. html I will


Hi Tomas



Thank you for your feedback.

There is still some work ongoing completing the work on rfc4210bis. You can see the latest editor’s copy on github.

https://lamps-wg.github.io/cmp-updates/#go.draft-ietf-lamps-rfc4210bis.html<https://urldefense.com/v3/__https://lamps-wg.github.io/cmp-updates/*go.draft-ietf-lamps-rfc4210bis.html__;Iw!!BjbSd3t9V7AnTp3tuV-82YaK!wjf3KcqAVljkHXjOHmGMBJfUPsO8NIvzo9Z_LU9ayytZ-YUOP0BoKM4zskjsCOoHw2SapMtyiuwWlo5T8LMZgmHhHfcuUJlT7vwV$>



I will respond to your comments in detail later.



Hendrik



Von: Spasm <[e-mail]> Im Auftrag von Tomas Gustavsson
Gesendet: Donnerstag, 25. Januar 2024 15:49
An: [e-mail]
Betreff: [lamps] Comments on CMP Updates, draft-ietf-lamps-rfc4210bis-07



Hi,



I'm not sure how much work is currently going on on this draft? I started reading it and have a bunch of comments. Perhaps it's being thought of already, but posting it here if anyone is interested.

I acknowledge that updating CMP, to something that includes new things like KEMs, and yet makes CMP easier to use and deploy on scale, is a truly monumentous task.



Here some points for discussion after reading through parts of the draft.



  1.  Section 4.2.2.1 describes it as mandatory that the CA can send a CMP message to the end entity directly. I think this is an extremely rare case, and very hard to interpret. CAs can virtually never make an on-line connection to end entities, so this scheme assumes an out-of-band deliver of the CMP message, which is hard to envision imho. At least without stating that this is outside of the scop. The most basic cases I know of always involve some RA that initiates the request to the CA. This is confusing to me.

  1.  Section 4.4 on root CA key update seems very verbose.

It discusses the odd case of CA rollback to great lengths, which I'm sure is extremely rare.

We discussed during the period of RFC9480, about the need for OldWithNew, which is why RFC9480 have both NewWithOld and OldWithNew as optional in 5.3.19.15. I don't think it is good to bring that back here in the form of: "Thus, when a CA updates its key pair it must generate two extra cACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld, OldWithNew, NewWithOld, and NewWithNew).".

Using an x.500 directory as reference I don't think is a good one.

  *   Keeping these optional enables us to cut down on the verbose wording quite some. You can basically remove the whole section 4.4.1, or shorten it substantially.

  *   It would be good if section 4.4 gave more advice on the standard use case of CA Renewal

  *   Section 4.4.2.x seems to assume an LDAP directory. Also nothing that is common, I don't think the CMP draft should specify which LDAP attributes to look up ("Look up the cACertificate attribute in the repository"). Either CMP have a mechanism to distribute new certificates, or it's out of scop and we can remove those words.

  *   The section assumes support for X.509 v1, without extensions. I don't think this is appropriate. CMPv3 makes extensive use of extensions in the specification so assuming X.509v3 with extensions I think would be better. CMPv3 will not work without extensions anyhow.



  1.  Section 5.1.3.4 talks about Alice and Bob. I think the CMP specification should make use of CMP terminology. I.e. from RFC4210, is it an End Entity, CA, RA or KGA.

     *   This flows into Appendix E as well

  1.  Section 5.2.5 should be removed imho. It says it is out of scope, why define ASN.1 data structures for something that is out of scope of the document? I think it's right to keep it out of scope, but then the whole section can be removed.

     *   KEM keys and message protection:Sections 5.1.3.4, Appendix E: For message protection I wish some more guidance could be provided, or I fear there will be much confusion and many alternatives asked. I think the case of an end entity possessing solely a KEM key will be rare. The more common case is probably that the end entity have both a signature key and a KEM key. In that case isn't it more efficient to use the signature key/cert to authenticate also the request for a KEM key? In essence the same way an IDevID is used to request an operational certificate. The way it is worded in 5.1.3.4 "In case the sender of a message has a KEM key pair". Given the extra roundtrip outlined in Appendix E, I would prefer "In case the sender of a message only has a KEM key pair". I would like it described the case where KEM key certificates are requested, using normal signature based protection, and hope that could be the preferred scenario.

        *   Migrating existing systems to that model is much easier than to move to only using KEMs and extra rountrips (or suppliing every RA and CA with KEM certificates just to avoid a round-trip).



Best regards,

Tomas