We have time on the agenda, so I am going to add some open discussion time for this.
On 7/21/20, 6:45 AM, "Ilari Liusvaara" <[email protected]> wrote: On Thu, Jul 09, 2020 at 09:01:25AM -0400, Ryan Sleevi wrote: > On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara <[email protected]> > wrote: > > > For designing a cleaner mechanism to propose to CABForum, I think > > reasonable starting point would be to model it like the ACME key- > > change endpoint. However, signing JOSE messages with Tor key is > > not cryptographically kosher (just like singing CSRs with it is > > not kosher). However, again there should be no problems in practice > > (Tor itself never signs with this key, only derives other keys from > > it). > > > I think the odds of a change in the Forum are low here. I’ll readily admit, > I am intentionally rather hostile to JOSE / COSE being introduced into the > CABF, because of the consistent and persistent security failures these > formats lead to. > > That said, given the rather significant improvements to the cryptographic > constructions of v3, I’m also quite keen for any establishment protocol in > the CSR that can suitably demonstrate a POP within the CSR. It needs to be > robust to cross-protocol reuse, but I suspect that is now substantially > easier given the v3 construction. I suspect that would also make it easier > for ACME, but perhaps I’m overlooking why even a simplified form is > challenging? It turns out that signing messages with Tor key does not have harmful cryptographic interactions with the way Tor uses that key (due to EdDSA also hashing the key when signing). The main issue with the present CSR method is complexity. The applicant nonce does nothing useful (as due to ordering of the main EdDSA hash, R already strenghens it). The description of format is too hard to understand (an example would go long way to resolving the latter issue). There are simpler constrctions that would do the POP. For example (TLS syntax): struct { opaque public_key[32]; opaque nonce<22..255>; } PopInner; Sign PopInner structure using TLS 1.3 signature format with context string "ACME, tor-rendv3-pop". Base64url-encode the 64-byte signature and send it in ready for challenge request. CA can verify this by reconstructing the PoPInner from the known key nonce and verifying the given signature with the key. However, this does not do approval of ACME key (neither does the present CSR method). I think the reason of approving old key with new key in performing the key rollover is to prevent replaying new keys. Replay here is prevented by the CA nonce. And I think I found an issue in draft-shoemaker-acme-onion: It requires only 64 bits of entropy for CA nonce, while BRs require 112, and base ACME spec requires 128. Fix would be to change the first "64 bits of entropy" in section 4 to "128 bits of entropy". This is presumably due to confusing the two nonces, as applicant nonce can indeed be 64-bit. -Ilari _______________________________________________ Acme mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwIGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kBAk8JLDrgKC0IPKbyr4bCQAQ8pEZPcETi7Q0vjkUzA&s=xCkQ_STqxFwHRKntBP8xAnybPBYEL0JHJbkstYIyFIE&e= _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
