> 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 <[email protected]> Sent: Thursday, January 24, 2019 06:05 To: 'Michael Richardson' <[email protected]>; Esko Dijk <[email protected]> Cc: [email protected] Subject: RE: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices > -----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
