Ok, I went back and read parts of RFC 8995 (Section 5.6, 11.4, other parts of Section 5), and a tiny bit of RFC8366. I also watched mcr's video (which does explain it nicely, x1.5 is the bomb). To clarify my concern (to David), I was discussing exactly what is mentioned in 8995's section 11.4 (the name of that section doesn't help). So, my concern is addressed.
I do think adding the voucher request/response to Figure 2 would help. But I fear it would make that figure much more complicated (although it just adds a column?). I also see now that if someone wants to use CMP (or SCEP) they will also have to deal with EST/CMS for parts of the process. I wonder just how complex these devices will have to be. But that isn't really a comment against the draft. Thanks for taking the time to explain. I'll re-write my discuss as a 'no objection' w/ a comment with some part of the above. Deb On Mon, Sep 2, 2024 at 5:01 PM David von Oheimb < [email protected]> wrote: > s/need/do not need/ > On 02.09.24 22:58, Michael Richardson wrote: > > Deb Cooley <[email protected]> <[email protected]> wrote: > > If there is always a TLS/DTLS session, then why is there a note in Sec > > Consid about CMP messages being in the clear? > > 1. brski-ae also can use brski-prm [they were one document before]. > PRM must use CMP, as it uses HTTP between a new thing (the > "registrar-agent"), and the pledge. With the initiation reversed. > > 2. the connection between RA and CA might not be encrypted. > > In general, CMP messages are designed so that they need transport security. > (vs EST) > > > > -- > Michael Richardson <[email protected]> <[email protected]> . o O ( > IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > >
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
