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

["Brockhaus, Hendrik" <[e-mail]>]

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.

 

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

 

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

a.	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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-rfc4210bis-07%23section-5.1.3.4-
2&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C93b29ddd31bc45c548aa08dc1
e9a4829%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638418895199625346%7CUn
known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gBaFzG7nRVt4M85JveobmpBgFU11rlO8EjoJab4TdzA
%3D&reserved=0> ¶

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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-rfc4210bis-07%23section-5.1.3.4-
2&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C93b29ddd31bc45c548aa08dc1
e9a4829%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638418895199635588%7CUn
known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w7DfQWUTs39oV44ooki0ziN1ZgHXv9vs7m6MehaPXkg
%3D&reserved=0> ¶

Do you think this makes it clearer?

Any other proposal is also welcome.

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

 

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

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