Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 8 May 2019 09:09:41 +0000

Hi Russ, all,

as discussed at IETF104 and on this list we would like to spend further work on updating and profiling CMP focusing on industrial use cases.
To get input, feedback and support from LAMPS we propose the following charter text.

As certificate management gets increasingly important in industrial environments, it needs to be tailored to the specific needs. CMP as existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be enhanced to more efficiently support of industrial use cases, crypto agility and specific communication relations on the one hand and profiled to the necessary functionality on the other hand to ease application and to better facilitate interoperable implementation.

Hendrik

Von: Russ Housley <[email-masked]>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]>
Cc: [email-masked]; Jim Schaad <[email-masked]>; Fries, Steffen (CT RDA ITS) <[email-masked]>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile

Hendrik:

The current re-charter is about two weeks away.  You would need to propose text for the charter on this list, and see if there are people that will review and implement.

Russ

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:

Hi all

Referring to the Email thread 'Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile' and to the outcome of the WG meeting, we want to summarize the current state of the discussion.
The discussion we had with Jim motivate a split of the current draft into a CMP Updates and a CMP Profile document. The update of CMP is needed because we identified at least two point where a change to CMP is needed:
- Change the type of encryptedCert from EncryptedValue to EncryptedKey for ECC and post-quantum algorithm support
- Extend the RootCAUpdate announcement message to e request/response message to enable requesting the update from the client side
The remaining points from the initial email were seen as profiling topic and would therefore be handled in the CMP Profile document.

@Russ, how do you see the status of the current re-chartering process? Would you support to add both, or at least the CMP Updates, activities under the revised charter?

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cb2dc4e66b2644d53d64308d6d34aa72c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636928715140199163&sdata=vbsWP%2FRwxnN6qgWKB2Qbq7aC5CFobDEJCTqJOBkSIJk%3D&reserved=0>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 8 May 2019 14:00:15 +0000

Hi Hendrik,

Long time since we talked.

With such a profile, I have a concern that what happened with SCEP, CMC, CMPv2, EST is likely to happen in constrained environments. Using two or more protocols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation and confuse vendors that want to pick one.

I am not sure I have heard a broad need for a CMP profile in ACE. If this is a single vendor need, does IETF even need to standardize this CMP profile?

Panos

From: Spasm <[email-masked]> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: [email-masked]; Russ Housley <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]
Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ, all,

Hendrik

Von: Russ Housley <[email-masked]<mailto:[email-masked]>>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Jim Schaad <[email-masked]<mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile

Hendrik:

Russ

Hi all

The remaining points from the initial email were seen as profiling topic and would therefore be handled in the CMP Profile document..

- Hendrik

---

From: "Peylo, Martin (Nokia - FI/Espoo)" <[email-masked]>
Date: Wed, 8 May 2019 14:53:59 +0000

Hi,

I see good value of clear CMP profiles for different use cases.

The actual problem why CMP isn't as widely used as it could be is that it aims to cater for every possible and impossible use case. RFC 4210, Appendix D certainly has room for improvement; To be conformant, implementers need to add features very few users would actually want to use, e.g. the second CertReqMsg in an IR. The plethora of options certainly is the main issue for implementing with wide interworking - there are e.g. multiple meaningful ways to implement RA-CA communications. So, clear CMP profiles will be a valuable tool for implementers to provide interoperable clients and servers for defined use cases.

Panos, I haven't followed ACE lately, but I could imagine that also users of the work currently done in ACE could benefit from this. CMP caters very well for the needs of RA-CA communications, and there are many scenarios where PKIs for constrained devices benefit from utilizing RAs. So, also a clear profile for RA-CA communication would certainly be a benefit the constrained-device world, even if it is not directly visible on the constrained devices themselves.

But anyway, it appears quite possible to shrink a CMP implementation for a constrained device. As a PoC, I have implemented a rudimentary CMP client [1] for Mbed(tm) in 2017. As minimal profile, I basically did IR with MSG_SIG_ALG and implicit confirm - that worked well on a FRDM-K64F.

A careful update for RFC 4210 should also allow to refresh the list of mandatory algorithms, not least putting SHA-1 and 3-DES to rest.

I'm looking forward to discussing details of profiles and other enhancements to the protocol specification.

Cheers,
Martin

[1] https://github.com/nokia/CMPclient-embedded-lib

From: Spasm <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, May 8, 2019 5:00 PM
To: [email-masked]; Russ Housley <[email-masked]>; Brockhaus, Hendrik <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Hendrik,

Panos

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; steffen.fries@siemens..com<mailto:steffen.fries@siemens..com>
Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ, all,

Hendrik

Cc: [email-masked]<mailto:[email-masked]>; Jim Schaad <[email-masked]<mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked]<mailto:steffen.fries@siemens..com>>

Hendrik:

Russ

Hi all

- Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 8 May 2019 15:02:18 +0000

Hi Panos,

missed you in Prague.

Steffen had a discussion on the focus of our CMP profile with Jim after the ACE meeting in Prague. May be we did not focus enough on industrial use cases. Our focus in not in the first place on constrained devices, but we believe that CMP would also work perfectly on all those devices capable to run TLS.
Currently CMP is already used in mobile networks and in rail networks. But we see the need to specify the needed uses cases in more detail to get interoperable implementations.
The big advantage of CMP for industrial use is that we do not have any security requirements to the transport of the messages, since CMP messages are self-contained and support end-to-end security.  A hop-by-hop security or asynchronous transport is not always feasible.

Hendrik

Von: Panos Kampanakis (pkampana) <[email-masked]>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: [email-masked]; Russ Housley <[email-masked]>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Fries, Steffen (CT RDA ITS) <[email-masked]>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Hendrik,

Panos

Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C826a1c2e978d47ab1dea08d6d3bd8a02%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929208355269935&sdata=KYX7htjTVg8Eppn8PrwnN0kVojKPnYpCvUpuiI8bn58%3D&reserved=0>

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 8 May 2019 17:12:18 -0600

Hi Hendrik, all,

I too support this effort and I have few use-cases that might be relevant.

First of all, this work is something I needed to do for the EAP-CREDS 
(Credentials Management over EAP) work (we need a simplified profile for 
the EAP-CREDS to work :D).

Another important use case we have is related to medical devices (we 
have been working with CMI for a while now): in that environment we need 
to use reasonably-lived certificates (not the usual 20yrs device cert) 
with frequent renewals: when trying to select a simple protocol, CMP 
seemed the right choice over others because of its ease of 
implementation and flexibility.

Another use-case is within Wireless Broadband Alliance (WBA) - there, we 
are working to define and deploy a RadSec-only deployment for a 
WBA-centric roaming infrastructure, and part of that work is to define 
how to deliver server-side (but, in the future, also client-side via 
EAP-CREDS :D) certificates.

We are also evaluating the deployment of the same (or very similar) 
approach for the DOCSIS(r) standard (Cable Networks).

I also want to point out that CMP is already used in 3gpp (the very 
basic version) in their SIM-based (only for an initial authentication) 
certificate provisioning system (well, just the very basic of the 
protocol here).

Last but not least, I do like CMP because it allows me to use it 
independently from the transport protocol, which is a huge win for me 
(e.g., when granting access to the network and connectivity is not there 
yet, I want to be able to provision/manage the credentials even before 
the device goes online). Something like ACME, for example, it is 
completely useless for all my use-cases (and super inefficient :D).

I will be happy to provide my input for the work, if needed :D

Just my 2 cents...

Cheers,
Max

On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote:
>
> Hi Panos,
>
> missed you in Prague.
>
> Steffen had a discussion on the focus of our CMP profile with Jim 
> after the ACE meeting in Prague. May be we did not focus enough on 
> industrial use cases. Our focus in not in the first place on 
> constrained devices, but we believe that CMP would also work perfectly 
> on all those devices capable to run TLS.
>
> Currently CMP is already used in mobile networks and in rail 
> networks.. But we see the need to specify the needed uses cases in 
> more detail to get interoperable implementations.
>
> The big advantage of CMP for industrial use is that we do not have any 
> security requirements to the transport of the messages, since CMP 
> messages are self-contained and support end-to-end security.  A 
> hop-by-hop security or asynchronous transport is not always feasible.
>
> Hendrik
>
> *Von:* Panos Kampanakis (pkampana) <[email-masked]>
> *Gesendet:* Mittwoch, 8. Mai 2019 16:00
> *An:* [email-masked]; Russ Housley <[email-masked]>; Brockhaus, 
> Hendrik (CT RDA ITS SEA-DE) <[email-masked]>
> *Cc:* Jim Schaad <[email-masked]>; Fries, Steffen (CT RDA ITS) 
> <[email-masked]>
> *Betreff:* RE: Proposed Re-Chartering Text for CMP updates and 
> lightweight profile (RE: Follow-up on lightweight CMP profile)
>
> Hi Hendrik,
>
> With such a profile, I have a concern that what happened with SCEP, 
> CMC, CMPv2, EST is likely to happen in constrained environments. Using 
> two or more protocols (EST-coaps, a CMP profile over different 
> transports, and others) that do similar things would lead to 
> fragmentation and confuse vendors that want to pick one.
>
> I am not sure I have heard a broad need for a CMP profile in ACE. If 
> this is a single vendor need, does IETF even need to standardize this 
> CMP profile?
>
> Panos
>
> *From:*Spasm <[email-masked] <mailto:[email-masked]>> 
> *On Behalf Of *Brockhaus, Hendrik
> *Sent:* Wednesday, May 08, 2019 5:10 AM
> *To:* [email-masked] <mailto:[email-masked]>; Russ Housley 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* Jim Schaad <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* [lamps] Proposed Re-Chartering Text for CMP updates and 
> lightweight profile (RE: Follow-up on lightweight CMP profile)
>
> Hi Russ, all,
>
> as discussed at IETF104 and on this list we would like to spend 
> further work on updating and profiling CMP focusing on industrial use 
> cases.
>
> As certificate management gets increasingly important in industrial 
> environments, it needs to be tailored to the specific needs. CMP as 
> existing protocol offers a vast range of options. As it is already 
> being applied in industrial environments it needs to be enhanced to 
> more efficiently support of industrial use cases, crypto agility and 
> specific communication relations on the one hand and profiled to the 
> necessary functionality on the other hand to ease application and to 
> better facilitate interoperable implementation.
>
> Hendrik
>
> *Von:* Russ Housley <[email-masked] <mailto:[email-masked]>>
> *Gesendet:* Mittwoch, 8. Mai 2019 02:18
> *An:* Brockhaus, Hendrik (CT RDA ITS SEA-DE) 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; Jim Schaad 
> <[email-masked] <mailto:[email-masked]>>; Fries, 
> Steffen (CT RDA ITS) <[email-masked] 
> <mailto:steffen.fries@siemens..com>>
> *Betreff:* Re: [lamps] Follow-up on lightweight CMP profile
>
> Hendrik:
>
> The current re-charter is about two weeks away.  You would need to 
> propose text for the charter on this list, and see if there are people 
> that will review and implement.
>
> Russ
>
>     On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     Hi all
>
>     Referring to the Email thread 'Seeking guidance on proceeding with
>     question from IETF-104 presentation on lightweight CMP profile'
>     and to the outcome of the WG meeting, we want to summarize the
>     current state of the discussion.
>
>     The discussion we had with Jim motivate a split of the current
>     draft into a CMP Updates and a CMP Profile document. The update of
>     CMP is needed because we identified at least two point where a
>     change to CMP is needed:
>
>     - Change the type of encryptedCert from EncryptedValue to
>     EncryptedKey for ECC and post-quantum algorithm support
>
>     - Extend the RootCAUpdate announcement message to e
>     request/response message to enable requesting the update from the
>     client side
>
>     The remaining points from the initial email were seen as profiling
>     topic and would therefore be handled in the CMP Profile document...
>
>     @Russ, how do you see the status of the current re-chartering
>     process? Would you support to add both, or at least the CMP
>     Updates, activities under the revised charter?
>
>     - Hendrik
>
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/spasm
>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C826a1c2e978d47ab1dea08d6d3bd8a02%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929208355269935&sdata=KYX7htjTVg8Eppn8PrwnN0kVojKPnYpCvUpuiI8bn58%3D&reserved=0>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 9 May 2019 17:22:22 +0000

Hi Martin, hi Max,

thank you for your support.

Martin mentioned his Mbed(tm) based CMP implementation. This was a great starting point for us to extend the implementation to support further use cases specified in the CMP profile. It works perfectly fine on the NXP board. We plan to provide the code open source as soon as we have time to do so :-)

Thanks to Max for describing his use cases. I am happy to get his input to our I-D and also like to offer my support on his EAP-CREDS draft, too.

Hendrik

Von: Peylo, Martin (Nokia - FI/Espoo) <[email-masked]>
Gesendet: Mittwoch, 8. Mai 2019 16:54
An: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]; Russ Housley <[email-masked]>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Fries, Steffen (CT RDA ITS) <[email-masked]>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi,

Cheers,
Martin

[1] https://github.com/nokia/CMPclient-embedded-lib<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnokia%2FCMPclient-embedded-lib&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C2a216d814ab94c27e3d508d6d3c50e31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929240648653611&sdata=6yPJdsOGjQgr%2BjT1EFhsuR5DnvGq2qxkW5L7KDTjSd8%3D&reserved=0>

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, May 8, 2019 5:00 PM
To: [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]<mailto:[email-masked]>>; Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Hendrik,

Panos

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C2a216d814ab94c27e3d508d6d3c50e31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929240648653611&sdata=oVX2KXkN%2F35Akt%2F6ShQIh5WO8UWB6jUIszdceVpEOYk%3D&reserved=0>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 9 May 2019 18:55:42 +0000

Hi Hendrik,

Understood. I don't question that CMP has it uses; I wanted to avoid a new profile causing confusion in areas where there were other options.

Another question.  Why is this a LAMPS item? Creating a CMP profile that applies to a specific vertical resembles a recent case where a draft was brought to the TLS WG for V2V certificates in TLS. The TLS WG did not pick up the draft because of lack of interest and the narrow usecase. Why should this item be part of the LAMPS charter and not ISO ICS or IEC that seem more natural homes?

Thanks,
Panos

From: Spasm <[email-masked]> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 11:02 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Cc: Jim Schaad <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Panos,

missed you in Prague.

Steffen had a discussion on the focus of our CMP profile with Jim after the ACE meeting in Prague. May be we did not focus enough on industrial use cases. Our focus in not in the first place on constrained devices, but we believe that CMP would also work perfectly on all those devices capable to run TLS.
Currently CMP is already used in mobile networks and in rail networks.. But we see the need to specify the needed uses cases in more detail to get interoperable implementations.
The big advantage of CMP for industrial use is that we do not have any security requirements to the transport of the messages, since CMP messages are self-contained and support end-to-end security.  A hop-by-hop security or asynchronous transport is not always feasible.

Hendrik

Von: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]<mailto:[email-masked]>>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked]<mailto:[email-masked]>>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Hendrik,

Panos

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

The remaining points from the initial email were seen as profiling topic and would therefore be handled in the CMP Profile document...

- Hendrik

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 9 May 2019 18:55:41 +0000

Hi Max,

> First of all, this work is something I needed to do for the EAP-CREDS (Credentials Management over EAP) work (we need a simplified profile for the EAP-CREDS to work :D).

Is this the same profile proposed in Hendrik's draft or a different one?

I don't question that CMP has it uses, but are the rest of the usecases you listed out interested in using Hendrik's profile or are they just interested in CMP native?

Rgs,
Panos

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Dr. Pala
Sent: Wednesday, May 08, 2019 7:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Hendrik, all,

First of all, this work is something I needed to do for the EAP-CREDS (Credentials Management over EAP) work (we need a simplified profile for the EAP-CREDS to work :D).

Another important use case we have is related to medical devices (we have been working with CMI for a while now): in that environment we need to use reasonably-lived certificates (not the usual 20yrs device cert) with frequent renewals: when trying to select a simple protocol, CMP seemed the right choice over others because of its ease of implementation and flexibility.

Another use-case is within Wireless Broadband Alliance (WBA) - there, we are working to define and deploy a RadSec-only deployment for a WBA-centric roaming infrastructure, and part of that work is to define how to deliver server-side (but, in the future, also client-side via EAP-CREDS :D) certificates.

We are also evaluating the deployment of the same (or very similar) approach for the DOCSIS(r) standard (Cable Networks).

I also want to point out that CMP is already used in 3gpp (the very basic version) in their SIM-based (only for an initial authentication) certificate provisioning system (well, just the very basic of the protocol here).

Last but not least, I do like CMP because it allows me to use it independently from the transport protocol, which is a huge win for me (e.g., when granting access to the network and connectivity is not there yet, I want to be able to provision/manage the credentials even before the device goes online). Something like ACME, for example, it is completely useless for all my use-cases (and super inefficient :D).

Just my 2 cents...

Cheers,
Max

missed you in Prague.

Hendrik

Von: Panos Kampanakis (pkampana) <[email-masked]><mailto:[email-masked]>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]><mailto:[email-masked]>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]><mailto:[email-masked]>
Cc: Jim Schaad <[email-masked]><mailto:[email-masked]>; Fries, Steffen (CT RDA ITS) <[email-masked]><mailto:[email-masked]>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Hendrik,

Panos

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik

Spasm mailing list

[OpenCA Logo]

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 10 May 2019 06:47:09 +0000

Hi Panos

Thank you for your thoughts and feedback.
I hope my comments below explain our approach and idea better.

Hendrik

Von: Panos Kampanakis (pkampana) <[email-masked]>
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]>; [email-masked]
Cc: Jim Schaad <[email-masked]>; Russ Housley <[email-masked]>; Fries, Steffen (CT RDA ITS) <[email-masked]>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Hendrik,
Understood. I don't question that CMP has it uses; I wanted to avoid a new profile causing confusion in areas where there were other options.
[Bro] I don't think the profile causes confusion. It just eases the use of CMP. Finally, it is up to the vertical to decide which enrollment protocol to use. As already discussed, there are use cases for different architectures. Features like binding to a secure transport may be an advantage for some use cases and a disadvantage for others, which rely on end-to-end security in an environment with multiple hops.
Another question.  Why is this a LAMPS item? Creating a CMP profile that applies to a specific vertical resembles a recent case where a draft was brought to the TLS WG for V2V certificates in TLS. The TLS WG did not pick up the draft because of lack of interest and the narrow usecase. Why should this item be part of the LAMPS charter and not ISO ICS or IEC that seem more natural homes?
[Bro] Agreed! We target a generic lightweight profile for CMP which we would like to apply to industry. Similar profiles have already been specified by 3GPP for telecommunication. We write the I-D independent from any vertical, just specifying the certificate management use cases more precisely.
As described in my initial mail, there is some very limited update of CMP needed to allow for the needed crypto agility and possibly to clear up some imprecision. This is like the updates to CMC in RFC6402. We understood LAMPS as maintainer of PKIX RFCs.
As the CMP profile aims to be a general-purpose profile, I also believe that this is an IETF topic. As there is much expertise in LAMPS on these topics, I would also appreciate, if this could be handled in this WG, too.

Thanks,
Panos

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 11:02 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; Russ Housley <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Panos,

missed you in Prague.

Hendrik

Hi Hendrik,

Panos

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C13a5dce99f8142fc6dfb08d6d4aff708%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636930249563542771&sdata=QnmjZmc5c8kaM9a2RsMsWr7zsRrl9pR7EdPch%2B0q6ac%3D&reserved=0>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 10 May 2019 07:11:28 +0000

Hi Panos

I am not sure if I got your point right. Can you explain the difference you make between 'Hendrik's profile' and 'CMP native'.

Regardless of the very limited changes to be covered in a CMP updates I-D, the goal of our profile is not to change CMP but to ease its use. Therefore I would say that our profile also uses CMP native.
If Max has further certificate management uses cases, not yet covered in the profile, I am happy to specify those together with him making use of the existing CMP mechanisms.
The purpose of the CMP profile is to tailor the features of CMP to the needed subset and specify this subset precisely to ease interoperable implementations.

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Dr. Pala <[email-masked]>; [email-masked]
Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Max,

Rgs,
Panos

Hi Hendrik, all,

Just my 2 cents...

Cheers,
Max

missed you in Prague.

Hendrik

Hi Hendrik,

Panos

Hi Russ, all,

Hendrik

Cc: [email-masked]<mailto:[email-masked]>; Jim Schaad <[email-masked]<mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked]<mailto:steffen.fries@siemens...com>>

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C00fbc3cf35894e89e47108d6d4b001e6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636930249744660844&sdata=QUtqW4zfpjkeoO8e9O3%2B8Ci0Ltizci1fWj30WuesQrA%3D&reserved=0>

Spasm mailing list

https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C00fbc3cf35894e89e47108d6d4b001e6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636930249744670853&sdata=G3ur8N2%2Bi8oVhvkozjjwNwZwU%2BoGUr%2FSvM335L81bmw%3D&reserved=0>
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 10 May 2019 17:28:45 +0000

> tailor the features of CMP to the needed subset and specify this subset precisely to ease interoperable implementations

You are creating a profile for CMP with a subset of its feature and minor updates to the protocol itself. I was not sure if the subset you need for industrial automation will match exactly the simplified profile Max needs for the EAP-CREDS.

From: Spasm <[email-masked]> On Behalf Of Brockhaus, Hendrik
Sent: Friday, May 10, 2019 3:11 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; Dr. Pala <[email-masked]>; [email-masked]
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Panos

Hendrik

Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Dr. Pala <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Max,

Rgs,
Panos

Hi Hendrik, all,

Just my 2 cents...

Cheers,
Max

missed you in Prague.

Hendrik

Hi Hendrik,

Panos

Hi Russ, all,

Hendrik

Cc: [email-masked]<mailto:[email-masked]>; Jim Schaad <[email-masked]<mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked]<mailto:steffen.fries@siemens....com>>

Hendrik:

Russ

Hi all

The remaining points from the initial email were seen as profiling topic and would therefore be handled in the CMP Profile document....

- Hendrik

Spasm mailing list

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 13 May 2019 06:30:52 +0000

OK, understood. Thank you for the clarification.
Let us see what is finally needed for Max use cases.
See an explanation on the needed CMP update inline.

Von: Panos Kampanakis (pkampana) <[email-masked]>
Gesendet: Freitag, 10. Mai 2019 19:29
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]>; Dr. Pala <[email-masked]>; [email-masked]
Betreff: RE: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

[Bro] As discussed with Jim, the goal is to keep the very limited changes to CMP in a separate I-D and do the tailoring in the profile document.
Finally there is only one real change to better support ECC and post-quantum algorithms in CMP.
--> Change EncryptedValue to EncryptedKey to also support EnvelopedData.
As EncryptedKey is a choice of EncryptedValue and EnvelopedData this change should be backward compatible. Therefore I do not see much problems there.
Everything else are more clarification topics that are of general value for CMP from my point of view. This is why I would suggest to put them into the CMP updates document, but they could also be shifted to the CMP profile. This can be discussed and decides in the WG then.

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Brockhaus, Hendrik
Sent: Friday, May 10, 2019 3:11 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; Dr. Pala <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Panos

Hendrik

Hi Max,

Rgs,
Panos

Hi Hendrik, all,

Just my 2 cents...

Cheers,
Max

missed you in Prague.

Hendrik

Hi Hendrik,

Panos

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C6c58c593b83943837e5208d6d56cfc74%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636931061407352686&sdata=oZe2KJeg2SNLCGIaQ%2BFmdYTThejJvSAbz8OYNwfRb54%3D&reserved=0>

Spasm mailing list

https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C6c58c593b83943837e5208d6d56cfc74%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636931061407352686&sdata=oZe2KJeg2SNLCGIaQ%2BFmdYTThejJvSAbz8OYNwfRb54%3D&reserved=0>
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 20 May 2019 13:42:48 +0000

Hi Russ

We discussed my proposal on the mailing list. I feel there is quite some support.
Tomas, Max and Martin supported the activity. There were some questions and concerns from Panos, that I hopefully could clarify.

What is the next step?

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch, 8. Mai 2019 11:10
An: [email-masked]; Russ Housley <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Fries, Steffen (CT RDA ITS) <[email-masked]>
Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C743e39b041d4476e826a08d6d3950ad8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929034414755277&sdata=PxGWfXa6%2FzuG2Pi844eXybqzfxwjQf0FAsc2YtDEYiM%3D&reserved=0>

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 21 May 2019 12:25:57 +0000

Hi Russ,

Just to add to the applicability/usability of the lightweight CMP profile. We are currently in the process of implementing this approach, based on openSSL.

Best regards
Steffen

From: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked]>
Sent: Montag, 20. Mai 2019 15:43
To: Russ Housley <[email-masked]>
Cc: Fries, Steffen (CT RDA ITS) <[email-masked]>; [email-masked]
Subject: AW: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ

What is the next step?

Hendrik

Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch, 8. Mai 2019 11:10
An: [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked]<mailto:[email-masked]>>
Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7C%7Cca9e3887e47e4ea6d71108d6dd290bea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636939565703421469&sdata=4jul1I%2FCI5qhJMZV%2FO25FXmKS58iYoJiHD%2Fy6avZgK8%3D&reserved=0>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 27 May 2019 13:03:53 +0000

Hi Russ

Did you have the time to look into my mail below?
I would like to push this topic further forward.

Hendrik

Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE)
Gesendet: Montag, 20. Mai 2019 15:43
An: Russ Housley <[email-masked]>
Cc: Fries, Steffen (CT RDA ITS) <[email-masked]>; [email-masked]
Betreff: AW: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ

What is the next step?

Hendrik

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 May 2019 12:48:30 -0400

Hendrik:

I see people speaking on both sides.  So, I am asking a few questions to see if there is enough support...

1) If this work is added to the charter, will you contribute to the document?

2) If this work is added to the charter, will you review to the document?

3) If this document is published as an RFC, will you implement it?

Russ

> On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Hi Russ
>  
> An: Russ Housley <[email-masked] <mailto:[email-masked]>>
> Cc: Fries, Steffen (CT RDA ITS) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Von: Spasm <[email-masked] <mailto:[email-masked]>> Im Auftrag von [ext] Brockhaus, Hendrik
> An: [email-masked] <mailto:[email-masked]>; Russ Housley <[email-masked] <mailto:[email-masked]>>
> Cc: Jim Schaad <[email-masked] <mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked] <mailto:[email-masked]>>
> Von: Russ Housley <[email-masked] <mailto:[email-masked]>> 
> An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Jim Schaad <[email-masked] <mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS) <[email-masked] <mailto:steffen.fries@siemens..com>>
> On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi all
> 
>  
> 
> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C743e39b041d4476e826a08d6d3950ad8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929034414755277&sdata=PxGWfXa6%2FzuG2Pi844eXybqzfxwjQf0FAsc2YtDEYiM%3D&reserved=0>
>  
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 27 May 2019 20:15:18 +0200

Hi Russ,

Is this question directed to the people who expressed support for the
profile?

> 1) If this work is added to the charter, will you contribute to the

As in writing the actual text of the draft, possibly, but not planned.

> 2) If this work is added to the charter, will you review to the document?

Yes. I have reviewed the suggested draft already and given feedback. And
will continue to do so.

> 3) If this document is published as an RFC, will you implement it?

Yes. Our software acts as CMP server in many industrial use-cases and we
implement several CMP use cases (among them the 3GPP CMP profile).
Therefore we will most likely support the new profile as well.

Regards,
Tomas

On 2019-05-27 18:48, Russ Housley wrote:
>> On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik
>> wrote:
>> *Von:* Brockhaus, Hendrik (CT RDA ITS SEA-DE) 
>> *Gesendet:* Montag, 20. Mai 2019 15:43
>> *An:* Russ Housley <[email-masked] <mailto:[email-masked]>>
>> *Cc:* Fries, Steffen (CT RDA ITS) <[email-masked]
>> <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>
>> *Betreff:* AW: Proposed Re-Chartering Text for CMP updates and
>> Tomas, Max and Martin supported the activity. There were some
>> questions and concerns from Panos, that I hopefully could clarify.
>>  
>> What is the next step?
>>  
>> Hendrik
>>  
>> *Von:* Spasm <[email-masked]
>> <mailto:[email-masked]>> *Im Auftrag von *[ext] Brockhaus, Hendrik
>> *Gesendet:* Mittwoch, 8. Mai 2019 11:10
>> *An:* [email-masked] <mailto:[email-masked]>; Russ Housley
>> <mailto:[email-masked]>>; Fries, Steffen (CT RDA ITS)
>> <[email-masked] <mailto:[email-masked]>>
>> *Betreff:* [lamps] Proposed Re-Chartering Text for CMP updates and
>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C743e39b041d4476e826a08d6d3950ad8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929034414755277&sdata=PxGWfXa6%2FzuG2Pi844eXybqzfxwjQf0FAsc2YtDEYiM%3D&reserved=0>
>>
>>

---

From: "Peylo, Martin (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 28 May 2019 11:00:02 +0000

Hi Russ,

  1.  If this work is added to the charter, will you contribute to the document?

Yes, mainly by means of review, I am planning to only contribute longer chunks of text if it becomes obvious during review that it is beneficial if I would create an explicit text proposal.

  1.  If this work is added to the charter, will you review to the document?

Yes. Based on my 10-year experience being involved with implementing the OpensSSL CMP client, which is amongst others predominantly used in the 3GPP telco-domain.

  1.  If this document is published as an RFC, will you implement it?

Yes, it can be expected that the OpenSSL-based CMP client library/application [1] will very likely support the profiles defined in the process. The application will be useable as compliant RA on the CLI, while the FOSS-code might not support an RA networking interface towards EEs. The library will also be suitable to implement a compliant RA, networked towards the EE, with reasonable effort if the integrated into an (e.g.) HTTP-server framework. It is expected that this code gets introduced into an upcoming OpenSSL version, currently review activities are ongoing.

The Mbed(tm) TLS-based simple CMP client library/application proof-of-concept I have put together [2] might be eventually updated (if needed) to support a simple IoT profile, while I cannot commit priority for that on my side at this time. Anyway, it's FOSS and I will happily support anybody who is interested to drive this forward.

It should be noted that most of the profiling in existing mature CMP server/client implementations will be probably be possible by already existing configuration means. I only expect need for polishing activity of smaller aspects in existing implementations, to remove so far existing difficulties for certain use cases (e.g. if the client is an RA), or where new mandatory algorithms are introduced (e.g. as SHA1 needs to get deprecated) - that should be very reasonable development effort.

[1] https://github.com/mpeylo/cmpossl
[2] https://github.com/nokia/CMPclient-embedded

Cheers,
Martin

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Monday, May 27, 2019 7:49 PM
To: [email-masked]
Cc: Tim Hollebeek <[email-masked]>
Subject: [lamps] Support for working on the lightweight CMP profile

Hendrik:

Russ

On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:

Hi Russ

Hendrik

Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE)
Gesendet: Montag, 20. Mai 2019 15:43
An: Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: Fries, Steffen (CT RDA ITS) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Betreff: AW: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ

What is the next step?

Hendrik

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 28 May 2019 13:18:15 +0000

Hi Russ,

thank you for these questions and thanks to Tomas and Martin for their statements.
I know about some other companies that are interested in this work e.g. from the rail automation industry.

Hendrik

Hendrik:

1) If this work is added to the charter, will you contribute to the document?
[Bro]  Yes, I am willing to be the editor of these documents, but I am also happy to be co-author if there is someone else to be editor of one of the documents. Jim offered to be the editor of the CMP Updates document, but this was in April and I did not hear from him since then.

[Bro] Yes

3) If this document is published as an RFC, will you implement it?
[Bro] Yes. We already implement the profile in C based on OpenSSL and MbedTLS (see also projects listed by Martin which we use and also actively contribute to) and in Java and C# based on Bouncy Castle.

Russ

Hi Russ

Hendrik

Hi Russ

What is the next step?

Hendrik

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C380e23f526e3408743f208d6e2c332f9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636945725337669914&sdata=HwlIZyUri9CcmQk4J%2F7V7w7recpOoNkwoRtgLNZoRCI%3D&reserved=0>

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C380e23f526e3408743f208d6e2c332f9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636945725337669914&sdata=HwlIZyUri9CcmQk4J%2F7V7w7recpOoNkwoRtgLNZoRCI%3D&reserved=0>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 28 May 2019 14:55:29 +0000

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.

So far I have seen one vendor that is driving this new profile. Two CAs that are interested in CMP in general, but it is not clear if they are interested in this exact profile. And I saw one more vendor that is interested in CMP profiles, but I am not exactly sure if it is for this specific profile either.

Rgs,
Panos

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Monday, May 27, 2019 12:49 PM
To: [email-masked]
Cc: Tim Hollebeek <[email-masked]>
Subject: [lamps] Support for working on the lightweight CMP profile

Hendrik:

Russ

Hi Russ

Hendrik

Hi Russ

What is the next step?

Hendrik

Hi Russ, all,

Hendrik

Hendrik:

Russ

Hi all

- Hendrik

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 May 2019 18:37:04 -0400

Panos Kampanakis (pkampana) <[email-masked]> 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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 29 May 2019 06:14:17 +0000

Michael Richardson <[email-masked]> wrote:
> 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

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 29 May 2019 12:43:38 +0200

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

---

From: "Peylo, Martin (Nokia - FI/Espoo)" <[email-masked]>
Date: Wed, 29 May 2019 12:00:33 +0000

Hi Michael,

> I don't really know why we need CMP, let alone a lightweight CMP.

Obviously, I also cannot say why you would need CMP, but e.g. the telco industry understands it, and therefore we are using it actively. I also know that the FOSS CMP implementation is utilized actively by more silent users including the banking, IT, academia fields. 

To ease standard conforming, interoperable implementation for various use cases where EST and SCEP are totally useless (e.g. RA-CA interface), it'd be great to have some standards-track clarifications (= profiling). Profiling CMP would be more or less this "remove features" you're asking for, as the richness of options in CMP wasn't necessarily beneficial for out-of-the-box interoperability in the past.

One should note that the subject of this email seems to be somewhat misleading as it is overly limiting the scope. I expect that besides clarifications for e.g. RA-CA communications, the upcoming work will also include a refresh of mandatory algorithms (bye bye SHA-1). While both of those will certainly be beneficial also for the lightweight CMP on the interface to EEs, it will also have positive influence beyond the "lightweight CMP" scope.

> Plus we have a bunch of proprietary RESTful interfaces to CAs.

As they are proprietary, they seem to be somewhat out of IETF scope and interoperability might not have been your focus when you were creating those?

Cheers,
Martin

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, May 29, 2019 1:37 AM
To: [email-masked]
Subject: Re: [lamps] Support for working on the lightweight CMP profile

I agree with Panos.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 May 2019 15:08:19 -0400

First, thank you for providing an excellent summary as to why one might use CMP
rather than EST.

    > as product implementor we like them both.

...

    > needed. The best profiling of CMP that I have seen so far is 3GPP

This is why I have ignored CMP.

    > example. https://tools.ietf.org/html/draft-ietf-ace-coap-est-11

As an author of ace-coap-esp, I would not really call it a profile...
We are really changing the transport and addressing, but I acknowledge that
maybe it's a profile decision as to what we are not translating.

    > except for their limited scope/vertical.

Amen Brother!

Based upon your comments, I will change my view, and offer support for
lightweight CMP.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 May 2019 15:12:04 -0400

Peylo, Martin (Nokia - FI/Espoo) <[email-masked]> wrote:
    > One should note that the subject of this email seems to be somewhat
    > misleading as it is overly limiting the scope. I expect that besides
    > clarifications for e.g. RA-CA communications, the upcoming work will
    > also include a refresh of mandatory algorithms (bye bye SHA-1). While
    > both of those will certainly be beneficial also for the lightweight CMP
    > on the interface to EEs, it will also have positive influence beyond
    > the "lightweight CMP" scope.

I think that updating algorithms almost goes without saying, but it's good
you said it.

    > As they are proprietary, they seem to be somewhat out of IETF scope and
    > interoperability might not have been your focus when you were creating
    > those?

The point is, if I have to support a proprietary interface to some CA, is
there an advantage to also supporting a standard lightweight CMP if talking
to the CA vendor still requires the proprietary RESTful interface.  I am
expected one or two of those to become defacto specifications, the way the
AWS EC2 API did.

(ps: I am the author of a Registration Authority product)