On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
> Couldn’t it be done in the way that the ACME server creates a nonce.
I am not sure why the client nonce is there. And I can not quickly find
any discussion about cryptographic reasons.
It could be for hash strenthening. However, that explanation is
problematic:
- The signature scheme is Ed25519, which has built-in hash
strengthening.
- For hash strenthening via applicant nonce to actually work, the
CSR must have applicant nonce before CA nonce.
However, I do not think it is impossible that it is indeed for hash
strengthening and these two details were just missed.
> 2 – OR the client can choose to submit the validation result inside
> the final CSR. There is a object in the CSR called ”Challenge
> password”, which could be ”reused” for this purpose, by filling it
> with the result of the validation (ergo a signature by the onion
> private key over the nonce).
I do not think that would work for two reasons:
- ACME protocol is not meant to proceed to CSR sending until after all
names are validated. Breaking that would cause implementation
problems.
- The CSRs are assumed to be self-signed, which is a problem here:
- The signature needs to be from Tor key for obvious reasons.
- The Tor keys are Ed25519, which is not allowed in WebPKI,
even for subscriber certificates.
- Even if the keys were allowed, using them for TLS is not
cryptographically kosher. However, there should be no problems in
this case.
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).
-Ilari
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
