Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
I believe that I already said yes. Jim > -Original Message- > From: Michael Richardson > Sent: Saturday, February 2, 2019 12:27 PM > To: Jim Schaad > Cc: 'Esko Dijk' ; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Jim Schaad wrote: > > Of anybody on the mailing list believes that the document should not > > add a new CoAP content type for "application/pkix-cert" please speak up > > before next Monday. > > Can we go ahead with this request now? :-) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ 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
Jim Schaad wrote: > Of anybody on the mailing list believes that the document should not > add a new CoAP content type for "application/pkix-cert" please speak up > before next Monday. Can we go ahead with this request now? :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 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
As ACE co-chair, Of anybody on the mailing list believes that the document should not add a new CoAP content type for "application/pkix-cert" please speak up before next Monday. Jim > -Original Message- > From: Ace On Behalf Of Michael Richardson > Sent: Thursday, January 24, 2019 8:01 AM > To: Esko Dijk > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for > embedded devices > > > Esko Dijk wrote: > > 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) > > So, to implement this in the specification, we need an additional Content- > Type value to be allocated. > > If we have WG Consensus to add this, then we can spin the document and > ask for another early allocation. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ 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: > 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) So, to implement this in the specification, we need an additional Content-Type value to be allocated. If we have WG Consensus to add this, then we can spin the document and ask for another early allocation. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 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
> -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
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
