Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices

[Esko Dijk <[e-mail]>]

> There is no signature for this CMS signed message format.  It only contains the certificates and CRLs that are passed back.  I would still think that this is a fine idea as long as you are only going to return the leaf certificate and not returning a bag of certificates or any CRLs.

That's right, only the leaf certificate is returned and no CRLs; in this embedded case. Any other required certificates are already obtained from the prior DTLS handshake process.
I agree that using draft-birkholz-core-coid-01 could be used in the future as an alternative format instead of an X.509 certificate. Ideally, it would become an update of RFC-EST-over-coaps and an enrolling client can indicate it uses the new formats by using e.g. CoAP Content-Format and Accept Options, or by different URI paths. 

Best regards
Esko

-----Original Message-----
From: Jim Schaad <[e-mail]> 
Sent: Thursday, January 24, 2019 06:05
To: 'Michael Richardson' <[e-mail]>; Esko Dijk <[e-mail]>
Cc: [e-mail]
Subject: RE: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices



> -----Original Message-----
> From: Ace <[e-mail]> On Behalf Of Michael Richardson
> Sent: Wednesday, January 23, 2019 6:27 PM
> To: Esko Dijk <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for 
> embedded devices
> 
> 
> Esko Dijk <[e-mail]> wrote:
>     > My main comment on this draft is based on recent experience with an
>     > embedded implementation. In the draft, the content format
>     > "application/pkcs7-mime;smime-type=certs-only" is used to 
> transport
a
>     > single certificate back to the client. However, in the embedded
>     > implementation crypto library there is no support for parsing this
>     > format, but there is support for parsing X.509v3
>     > (application/pkix-cert). See
>     > e.g. https://tls.mbed.org/api/group__x509__module.html for an 
> embedded
>     > API that can parse CSR and certs, but not PKCS#7.
> 
>     > Therefore the X.509 format seems better to use; also given that
>     > 1) the signing of data that the PKCS#7 S/MIME envelope provides 
> is useless because the DTLS session is already end-to-end protected 
> and the certificate is already signed; and

There is no signature for this CMS signed message format.  It only contains the certificates and CRLs that are passed back.  I would still think that this is a fine idea as long as you are only going to return the leaf certificate and not returning a bag of certificates or any CRLs.

>     > 2) RFC 7030 requires that only one certificate, the  generated 
> one,
is
>     > carried in the /simple(re)enroll response so that a container format
>     > for multiple certificates is not really needed here.
> 
>     > So to reduce code size for embedded implementations it would be very
>     > beneficial if the EST Server would support an additional content
>     > format:
>     > application/pkix-cert  (see RFC 5280)
> 
> I think that this is a reasonable thing to do.
> The client can easily say what it wants and I think the two formats 
> are relatively easy to swap.
> 
> What about if we went further, and went to:
>              Concise Identities
>              draft-birkholz-core-coid-01

Given that it would be a blocking factor, I would think about this as maybe something in the future.

Jim

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