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
> 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
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
