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

[Tomas Gustavsson <[e-mail]>]

I'm fine with the updates. Except that #45 is not settled right?

I can update the PR linked in issue 45 if you like? Restoring section 4.4 (back from appendix) and suggesting some text.

Regards;
Tomas

________________________________
From: Brockhaus, Hendrik
Sent: Monday, March 04, 2024 4:25 PM
To: Tomas Gustavsson
Cc: [e-mail]
Subject: AW: Comments on CMP Updates, draft-ietf-lamps-rfc4210bis-07


Tomas



I tried to address your points on Sections 5.1.3.4 and 5.2.8 with the recent update. Are you fine with these updates?



As already discussed, I want to bring your comments on Sections 4.2, 4.4, and 5.2.5 up during next IETF. They are also captured on github.

  *   https://github.com/lamps-wg/cmp-updates/issues/43
  *   https://github.com/lamps-wg/cmp-updates/issues/45



Hendrik



Von: Spasm <[e-mail]> Im Auftrag von Brockhaus, Hendrik
Gesendet: Freitag, 26. Januar 2024 19:12
An: Tomas Gustavsson <[e-mail]>
Cc: [e-mail]
Betreff: Re: [lamps] Comments on CMP Updates, draft-ietf-lamps-rfc4210bis-07



Tomas



Thank you for your feedback. Please see my responses inline.





Von: Tomas Gustavsson <[e-mail]<mailto:[e-mail]>>
Gesendet: Freitag, 26. Januar 2024 09:24

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.



[HB] You are right, the raVerified POP method is only described briefly in Section 5.2.8.4. This text may be extended.

Section 4.3 is describing which POP methods to uses for which key-types. Section 5.2.8 describes different POP structures and methods and is the more appropriate place describing raVerified. Currently an additional subsection for raVerified would not fit well into the existing structure of Section 5.2.8. But if we decide to restructure the section, it could nicely fit. To be honest, the current structure is a bit odd anyhow, but as it originates from RFC 2510, I tried to change as little as possible.

A new structure could look like this:

5.2.8.  Proof-of-Possession Structures

  5.2.8.1 raVerified

  5.2.8.2 POPOSigningKey Structure

  5.2.8.3 POPOPrivKey Structure

     5.2.8.3.1.  Inclusion of the Private Key

     5.2.8.3.2.  Encrypted Certificate - Indirect Method

     5.2.8.3.3.  Challenge-Response Protocol – Direct Method

  5.2.8.4.  Summary of PoP Options





Von: Spasm <[e-mail]<mailto:[e-mail]>> Im Auftrag von Tomas Gustavsson
Gesendet: Donnerstag, 25. Januar 2024 15:49

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.



[HB] Thank you. Comments are always welcome.



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.

[HB]  I fully support your point. As you know, RFC 9483 also addresses PKI Management Operations between RA and CA.

But as I read Section 4.2.2 the only mandators scheme is specified in Section 4.2.2.2. The Centralizes Scheme specified in Section 4.2.2.1 is optional. But I can envision this scheme for example in a factory with a local CA providing key generation and certificate issuance on behalf of the device. But you are perfectly right, this is not a scenario CMP would be used for.

I see Section 4.2 more as a first illustration how enrollment could look like. As there is the profile for enrollment of person-certificate in the Appendix and the profile for machine-to-machine enrollment in RFC 9483, it would be fine removing normative language from Section 4.2 completely, if the WG agrees.



  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.

[HB] I absolutely support your point. I see Section 4.4 more as a historic and explanatory section. I cannot say, if it has any relevance today. But I know that at least Section 4.1.3 of RFC 7030 is referring to the CA rollover model of CMP pointing to Section 4.4 of RFC 4210. Therefore, I was hesitating to change anything further on this section.

Finally, this section does not use normative language (except twice where it is not critical). Therefore, I do not see the need for implementing this as specified here for RFC compliance.

But as said, I am open for proposals how to update the section to express the issues you described. Maybe we can also move historic text of this section to an Appendix if people do not want to drop it completely.

Could you contribute text for an updates Section 4.4?



  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

[HB] You are right, we should use CMP terminology if possible. As this section intends to specify KEM-based message protection in a generic manner regardless of if the client or the server is using the KEM private key. We tried to explain and motivate this in the note right at the beginning of the section.

Note: In this section both entities in the communication need to send and receive messages. For ease of explanation we use the term "Alice" to denote the entity possessing the KEM key pair and who wishes to authenticate messages sent, and "Bob" to denote the entity who needs to authenticate the messages received.¶<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-07#section-5.1.3.4-2>

Maybe I should add as second sentence the following:

... Also, the client as well as the server side of the communication could wish to protect messages using KEM keys. ...¶<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-07#section-5.1.3.4-2>

Do you think this makes it clearer?

Any other proposal is also welcome.

  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.

[HB] I do not know, why this section and the ASN.1 definition were added to the document, but they were already part of RFC 2510  :-)

I could imagine moving this section together with parts of Section 4.4 to an appendix. Could you address this in your proposal for an updated Section 4.4 as well?



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

[HB] I agree that the specification of KEM-based message protection is difficult to read. I have hoped that providing a generic description in the main body of the document together with more specific text in the appendix would help.

We had the use case in mind, that the EE only has a KEM key pair and is only capable of validation PQC signatures. You are right that an entity that holds both a signature key pair as well as a KEM key pair could easily use the cr message type protected using the signature key to request its KEM certificate. This is definitely much easier than implementing KEM-based message protection as specified in Section 4.1.3.4 requiring an extra roundtrip. But, without supporting KEM-based message protection the entity cannot use kur message type to update the KEM certificate or rr message type to revoke its KEM certificate.

Finally, Section 4.1.3.4 only specifies KEM-based message protection in a generic way. When and how it is to be applied is up to a more concrete profile. Such profile could then also address the case when an entity has a signature key pair and a KEM key pair.



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

[HB] Section 5.1.3 is very generic, specifying message protection depending on the key-type used. It is not meant to specify any concert enrollment scenario. Therefore, I feel like this change does not fit the spirit of this section.

As said above, I think, it is up to a more concrete profile specifying this level of detail.



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

[HB] I would also love to avoid the extra roundtrip. But I think not every scenario allows for using signature keys for managing KEM certificates. But such specification would perfectly fit into a profile for managing KEM certificates using the mechanisms specified in this document. It could potentially be based upon RFC 9483. I did not plan for such profile so fare, but if you want to start working on such draft, I would like to contribute.

If you or anyone else thinks my scoping of Section 5.1.3 is not appropriate, please let me know.



Tomas, thanks a lot for your effort providing feedback. I would love to continue the discussion also with others.



Hendrik