> -----Original Message-----
> From: Ace <[email protected]> On Behalf Of Michael Richardson
> Sent: Wednesday, January 23, 2019 6:27 PM
> To: Esko Dijk <[email protected]>
> Cc: [email protected]
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for
> embedded devices
>
>
> Esko Dijk <[email protected]> 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
[
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
[
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
