> -Original Message-
> From: Ace On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Friday, July 24, 2020 7:05 AM
> To: Brockhaus, Hendrik ; Benjamin Kaduk
> ; Michael Richardson
> Cc: Mohit Sahni ; steffen.fr...@siemens.com;
> ace@ietf.org
> Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
Migault)
>
> Hi Hendrik,
>
> Thank you. Understood about the end-to-end protection of CMP and POP.
>
> I would argue that establishing the end-to-end keys to offer the
application
> level protection functionality in a scalable way does not come easily. On
the
> other hand, even CMP allows for an RA trust model instead of end-to-end
POP
> like EST-coaps does.
[JLS] EST-coaps does allow for an RA trust model for POP as well. The RA is
the terminator for the coaps connection.
Jim
>
> > I am uncertain if I understand your question correctly. Est-over-coaps
> described EST transport and not CMP transport on top of CoAP.
>
> I meant why do we need two enrollment protocols to run over COAP?
> est-over-coaps took a long time and a lot of work. The reason we pursued
it is
> because we were getting requests from vendors that wanted to enroll certs
in
> constrained environments in the energy sector and industrial automation
and
> EST was standardized in IEC 62351. Is the cmp-over-coap argument that you
> could run it over plan UDP and use out-of-band established, end-to-end
> protection the sole motivating reason?
>
> Rgs,
> Panos
>
>
> -Original Message-
> From: Ace On Behalf Of Brockhaus, Hendrik
> Sent: Wednesday, July 22, 2020 9:42 AM
> To: Panos Kampanakis (pkampana) ; Benjamin Kaduk
> ; Michael Richardson
> Cc: Mohit Sahni ; steffen.fr...@siemens.com;
> ace@ietf.org
> Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
> Migault)
>
> Hi Panos,
>
> thnaks for you feedback.
>
> > Von: Panos Kampanakis (pkampana)
> >
> > Hi,
> >
> > > Looking into Mohits draft, cmp-over-coap is much simpler than
> > est-over-coaps, as CMP does not need any binding to an underlying
> > (D)TLS handshake.
> >
> > Not sure that is accurate. And EST does not bind to the tunnel
> > protocol either unless proof of possession is used. For now the
> > cmp-over-coap draft says
> >
> >When the end to end secrecy is desired for CoAP transport, CoAP over
> >DTLS [RFC6347] as a transport medium SHOULD be used.
> >
> > COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and
> > maybe Websockets. I am not sure someone would run cmp-over-coap over
> > TCP because then he could just run CMP natively without COAP in the
> > middle. Any application layer protocol (CMP etc) can run over any
> > transport but I am
> not
> > sure there are more transports than the usual ones for cmp-over-coap
> anyway.
>
> It is not needed to run CMP over CoAP over TCP. UDP as transport protocol
is
> fine. Actually CMP over CoAP also does not need DTLS underneath. But it
also
> does not hinder to have a second line of defense.
> As I understand EST, proof-of-possession is purely provided by the
> self-signature in PKCS#10. But EST provides the proof-of-identity of the
> requesting party by the (D)TLS client authentication bound to the PKCS#10
> (tls-unique copied in the P10 password filed). Is this correct?
> Such binding is not required for CMP. CMP does not have any requirements
in
> this regard and provides prove-of-identity by signing the CMP messages.
The
> advantage is that this prove-of-identity can be end-to-end and not only on
> the first hop to the (D)TLS server, like with EST.
>
> >
> >
> > I agree that if this gets picked up it should be by ACE.
> >
> > I would like to understand what gaps it is filling compared to
> > est-over-coaps which took a lot of work and where it will be used and
> > implemented in.
>
> I am uncertain if I understand your question correctly. Est-over-coaps
> described EST transport and not CMP transport on top of CoAP.
> One prototypic implementation can be found on
> github.com/siemens/embeddedCMP.
>
> - Hendrik
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
