Re: [lamps] Support for working on the lightweight CMP profile

[Tomas Gustavsson <[e-mail]>]

Hi,

I want to give my reasons for having a CMP profile. From the viewpoint
of a product implementor implementing open standards for PKI.

Sorry for the lengthy post, but I have several arguments :-)

Please don't mention SCEP in this context. SCEP is not an RFC and does
not fulfill even basic needs of today (EC). SCEP is quickly going away
and it's best to leave it alone to die.

CMC I would agree does some of the same functionality, but it's also
dying. Leave it to rest.

We have today two (good) alternatives for standard PKI protocols, CMP
and EST. As a product supplier we see extensive use of both CMP and EST
in the industry and the more interoperable these usages are the better.

EST and CMP have fundamentally different security aspects, making them
suitable for different use cases. It's not one of the other, both are
needed due to the different ways of working:
- EST uses the communication layer (TLS) for security, it is simple and
easy, but depends on TLS (for good and for bad, mostly for good where
this approach is suitable)
- CMP uses message security and is independent of the communication
layer, the messages are self-sufficient (for good and for bad, mostly
for good where this approach is suitable)

EST and CMP are not competing standard, but very much complementary and
as product implementor we like them both.

Unfortunately CMP (RFC4210) is more of a framework and solutions are not
interoperable because they use fields in different ways. Profiling is
needed. The best profiling of CMP that I have seen so far is 3GPP 33.310
in telecom, enabling vendors and telcos to use devices from multiple
manufactures in an interoperable way, using standard products without
custom development.
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2293

There is profiling going on for EST, see EST over Secure CoAP for
example. https://tools.ietf.org/html/draft-ietf-ace-coap-est-11
So it is not unheard of that IETF creates profiles to support different
use cases.

Considering the security aspects of CMP, and that it is used extensively
within the industry today, making a profile is highly valuable to
counter interoperability issues arising from the framework approach of
RFC4210.

I am glad to see that IEC 62351 is using standard protocols and has not
invented it's own. What would be interesting is to compare the proposed
profile agains what 62351 suggest. At least on the wikipedia page:
https://en.wikipedia.org/wiki/IEC_62351
It claims "Certificate enrollment by means of SCEP / CMP / EST", hence
usage of CMP already. How does IEC 62351 profile CMP?

IEC 62351 is a for purchase standard, and those rarely get high traction
except for their limited scope/vertical. In contrast, IETF documents get
traction across the board of protocol users. This is one reason why I
see the suggested profile having the potential to lift CMP up to a more
interoperable level, not only for the IIoT vertical, but actually
re-used for other verticals as well.

IMHO, it should be profiled in openness in IETF, not in closedness in
IEC. It's not a question if the profile (yes stripping down CMP) will
exist or not, just a question of where it is housed. My opinion is that
IETF is the best place. I like IETF standards, and they are highly
referenced and spread, making the world just a little bit more
interoperable.

Regards,
Tomas


On 2019-05-29 08:14, Fries, Steffen wrote:
> Michael Richardson <[e-mail]> wrote:
>> Panos Kampanakis (pkampana) <[e-mail]> wrote:
>>     > Sorry, for insisting. I still have the concern that by adopting this, IETF
>>     > will continue the trend of endorsing different certificate management
>>     > protocols and profiles (SCEP, CMPv2, CMC, EST) that mostly do the same
>>     > things. Specifically for industrial automation we already have SCEP and EST
>>     > in IE 61850/IEC 62351. OPC UA has its own SDP for the same purposes. Now, we
>>     > want to add one more (CMP) in the mix for this vertical.
>>
>> I agree with Panos.
>> I don't really know why we need CMP, let alone a lightweight CMP.
>> Plus we have a bunch of proprietary RESTful interfaces to CAs.
>>
>> I have less of an objection to the IETF doing something, but I won't be reading/editing or implementing.
>>
>> If anything, I'd like to remove features from the protocols we have to simplify them and focus them better.
> That exactly is the intention of lightweight CMP. It intends to strip down functionality from an IETF defined protocol to have less requirements for interoperability for implementing devices. This lightweight approach should make it easier for others to adopt the already standardized functionality instead of defining proprietary approaches with a similar functionality. 
> 
> Best regards
> Steffen
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>