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

[Jim Schaad <[e-mail]>]

> -----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
[