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

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

> Von: Peter Gutmann <[e-mail]>
> Gesendet: Samstag, 25. April 2020 01:37
> 
> 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?  

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.

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

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