Ilari Liusvaara <[email protected]> wrote: >> 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).
That's an interesting point.
It seems that should there be future algorithms after EdDSA, that they could
adopt the same process. But is there no interest in RSA? :-0
> 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).
Is this just a documentation issue, or does it potentially introduce coding
errors?
> 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.
Interesting.
> 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.
Can you explain what you mean by "replaying new keys".
> 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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
