I think this is a terminology fix. Let's address it in the next iteration. -----Original Message----- From: Ace [mailto:[email protected]] On Behalf Of Michael Richardson Sent: Sunday, March 18, 2018 5:08 AM To: [email protected] Cc: [email protected] Subject: Re: [Ace] draft-ietf-ace-coap-est-00
peter van der Stok <[email protected]> wrote: >> 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? In the EST context, if it's a device with a (D)TLS connection to the Pledge (the device enrolling) and a TLS connection to the PKI CA, then it's a Registrar, not an http/coap proxy. It may have the same apparent connectors, but it processes the content. I can't come with any pure-7030 situations where this official MITM could be accomodated between the 7030 client and 7030-registrar. Perhaps this represents that for generic-7030 use involving COAP+DTLS, that a very clear applicability statement will need to detail what the initial EST trust is. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
