Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
> -Original Message- > From: Ace On Behalf Of Michael Richardson > Sent: Wednesday, January 23, 2019 6:27 PM > To: Esko Dijk > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Esko Dijk 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 [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Esko Dijk 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 [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] ACE Implementation for Disadvantaged Environments
Hello, I just wanted to make the group aware of our ACE implementation (SEI-ACE), which includes an implementation for a resource-constrained server. Details available in this news article: https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184 Article includes the link to our Git repo. Enjoy! - Grace Lewis __ Grace A. Lewis, Ph.D. Principal Researcher and TTG Initiative Lead Carnegie Mellon Software Engineering Institute Software Solutions Division (SSD) Tactical Technologies Group (TTG) 4500 Fifth Ave. #5412 Pittsburgh, PA 15213 Phone: (412) 268-5851 http://www.sei.cmu.edu/staff/glewis “A change in perspective is worth 80 IQ points” --- Alan Kay ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Dear ACE WG & authors, 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) The client can request this format using the CoAP Accept Option; by default if no Accept Option given the EST server would return application/pkcs7-mime;smime-type=certs-only. What do you think about this addition? I believe that adding this would make the EST-over-Coaps protocol an ideal fit to common embedded SW stacks. Furthmore I found these two issues that need to be addressed: Section 5.4: "The equivalent CoAP error code to use in an EST-coaps responses are 2.04 ..." -> 2.04 is a success code, not an error. Section 5.6: "According to section 5.2.2 of [RFC7252], a slow server can acknowledge the request with a 2.31 code" -> 2.31 is not specified in RFC 7252. Best regards Esko Dijk -Original Message- From: Ace On Behalf Of Jim Schaad Sent: Monday, January 14, 2019 05:03 To: ace@ietf.org Subject: [Ace] WGLC for draft-ietf-ace-coap-est The chairs believe that the EST over CoAP draft is nearing the point it should be sent to the IESG for publication. We are therefore going to have a Working Group Last Call on this document. WGLC will until 29th of this month. Please review the document and send comments both positive and negative to the list about its state. Jim & Roman ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace