Subject: [lamps] draft-ietf-lamps-lightweight-cmp-profile-01, section 5.4.4

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 24 Apr 2020 07:24:20 +0000

In section 5.4.4 a general message is specified to request requirements for an upcoming certificate request by the end entity from a PKI management component.
During IETF107's LAMPS meeting the rsaKeyLen parameter as discussed. Currently the rsaKeyLen field is specified as a single INTEGER. The question was, if a SEQUENCE OF INTEGER should be specified instead to offer a set of allowed RSA key length values.
During the meeting no one was in favor of this change and I would also tend to stick to the single INTEGER, as the certTemplate also offers only single values for the different attributes and extensions.

Is there anyone voting against specifying rsaKeyLen as single INTEGER?

-- Hendrik

---

From: Mohit Sahni <[email-masked]>
Date: Fri, 24 Apr 2020 00:50:54 -0700

Hi Hendrik
I am not against or for using the sequence but shouldn't this field be
generic to support ECDSA/ DSA or RSA key length?

-Mohit

On Fri, Apr 24, 2020 at 12:25 AM Brockhaus, Hendrik <
[email-masked]> wrote:

> In section 5.4.4 a general message is specified to request requirements
> for an upcoming certificate request by the end entity from a PKI management
> component.
> During IETF107's LAMPS meeting the rsaKeyLen parameter as discussed.
> Currently the rsaKeyLen field is specified as a single INTEGER. The
> question was, if a SEQUENCE OF INTEGER should be specified instead to offer
> a set of allowed RSA key length values.
> During the meeting no one was in favor of this change and I would also
> tend to stick to the single INTEGER, as the certTemplate also offers only
> single values for the different attributes and extensions.
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 24 Apr 2020 09:27:59 +0000

Von: Mohit Sahni <[email-masked]> 
Gesendet: Freitag, 24. April 2020 09:51

> Hi Hendrik
> I am not against or for using the sequence but shouldn't this field be generic to support ECDSA/ DSA or RSA key length? 

The situation is different for ECDSA and RSA. For ECDSA we use different OIDs in the certTemplate to specify the different curves and therefore also for the different key length. For RSA there is only one OID available and this is not specifying a specific key length. Therefore we think it is sufficient to separately specify only the key length for RSA.

-- Hendrik

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 24 Apr 2020 23:36:30 +0000

I wasn't aware of this work until now, is there any plan to address the large
number of problems in CMP that make it almost impossible to create two
interoperable CMP implementations purely from the spec?  See for example
section 5.2 of:

https://www.usenix.org/conference/12th-usenix-security-symposium/plug-and-play-pki-pki-your-mother-can-use

(Given how fundamentally broken CMP is, rather than profiling it a far simpler
option than trying to duct-tape it together would be to just redefine it to
use CMS, which would fix most of the problems in one stroke, but I'm not sure
if that's an option).

Peter.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 27 Apr 2020 06:31:13 +0000

> Von: Peter Gutmann <[email-masked]>
> Gesendet: Samstag, 25. April 2020 01:37
> 
> interoperable CMP implementations purely from the spec?  

Next to the Lightweight CMP Profile there is the Updates CMP draft (https://datatracker.ietf.org/doc/draft-brockhaus-lamps-cmp-updates/). This draft addresses some changes and general clarification on CMP. 
The scope of the Lightweight CMP Profile draft is to profile the existing protocol to foster interoperable implementations. See section 2 (https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-01#section-2) of the document for more details on the scope. Especially interoperability with existing profile in the industrial space like in ETSI-3GPP and UNISIG is a goal of the profile. See section 2.3 and 2.4.

> See for example section 5.2 of:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.usen
> ix.org%2Fconference%2F12th-usenix-security-symposium%2Fplug-and-play-pki-
> pki-your-mother-can-
> use&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cf11d5fbf2
> 10a4e96cce008d7e8a8554f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C1%7C637233682004627707&amp;sdata=O9VyYVvf9uxPkhAGLEQ3ghAJTw7gZL
> 695a744HQ%2BP%2Fs%3D&amp;reserved=0
> 
Thanks for this link.
If you have concrete suggestions on what is worth adding to the CMP Updates  or the Lightweight CMP Profile, you are welcome. If possibly complete portions of test are helpful for me. Then your concrete suggestion becomes more clear to me.

> option than trying to duct-tape it together would be to just redefine it to use
> CMS, which would fix most of the problems in one stroke, but I'm not sure if
> that's an option).

Generally speaking, this is an option if you would drop interoperability with existing implementations in ETCI-3GPP and UNISIG. CMS is definitely a good format for the content of certificate management messages. But currently there are already several approaches (2 RFCs as well as 2 drafts) out there that use CMS. I think, adding another flavor of certificate management will not foster interoperability. Therefore our approach was, to take a protocol that is in industrial use for a long time and profile it to clarify its use and ease interoperable implementations. 
Any suggestions for further clarification are very welcome.

-- Hendrik