Re: [Ace] draft-ietf-ace-coap-est-00
peter van der Stok wrote: >> >> DTLS connection is going to be required to act as an RA. RAs >> are required >> >> to have the entire request for adding authentication as necessary. >> >> > This is visible in the figure of section 6, but needs elaboration in >> the >> > text. >> >> I don't understand why we have that paragraph. >> An end point that terminates the Pledge (D)TLS connection and acts as >> an RA *IS* a Join Registrar, not a Proxy. >> > Thus is outside the BRSKI context, and thus a proxy with RA (separate or not) Let me delete "Join" from above sentence. A device that terminates the DTLS security (CoAPS) and then talks to the CA is a Registration Authority according to EST and RFC5280. It's not a proxy. (And it doesn't matter if it speaks HTTPS or CMS or CMP or super-pigeon-telepathy to the CA) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- 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] draft-ietf-ace-coap-est-00
Benjamin Kaduk wrote: >> Jim Schaad wrote: >> > In section 2 - There will be a problem in that the port format extension is >> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 1.3 >> > section for clarity. >> >> I don't understand what you are referring to. >> >> What is the "port format extension" you are referring to, and where in >> section 2 do you think we are depending upon it? > [...] DTLS > implementations MUST use the Supported Elliptic Curves and Supported > Point Formats Extensions [RFC4492]; the uncompressed point format > MUST be supported; [RFC6090] can be used as an implementation method. Ah, so s/port/point/ > The uncompressed point format only exists in (D)TLS 1.2 and lower. > (TLS 1.3 does not separately negotiate point format, rather, the > point format is determined by the group/curve to be used.) I think we were just being overly specific, I'm not sure why. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network 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] draft-ietf-ace-coap-est-00
Michael Richardson schreef op 2018-03-15 09:00: peter van der Stok wrote: >> >> DTLS connection is going to be required to act as an RA. RAs >> are required >> >> to have the entire request for adding authentication as necessary. >> >> > This is visible in the figure of section 6, but needs elaboration in >> the >> > text. >> >> I don't understand why we have that paragraph. >> An end point that terminates the Pledge (D)TLS connection and acts as >> an RA *IS* a Join Registrar, not a Proxy. >> > Thus is outside the BRSKI context, and thus a proxy with RA (separate or not) Let me delete "Join" from above sentence. A device that terminates the DTLS security (CoAPS) and then talks to the CA is a Registration Authority according to EST and RFC5280. It's not a proxy. (And it doesn't matter if it speaks HTTPS or CMS or CMP or super-pigeon-telepathy to the CA) A http/coap proxy is specified in RFC8075. It explains "how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response". In the est-coap draft DTLS and TLS connections are terminated in the http/coap proxy, and the proxy is therefore connected to an RA (possibly running on the same host as the proxy). Where is my terminology going astray? Peter ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
