Re: [Acme] Onion address validation extension

[Sebastian Nielsen <[e-mail]>]

Couldn’t it be done in the way that the ACME server creates a nonce.

Then there is 2 choices for the client to proceed:

 

1 – Either the client proceeds as in the draft, and submits the validation to the ACME server – this is required if the client wants to validate more than one domain name

 

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).

 

 

This could be made as 2 different validation types: onion-01 and onion-02

Onion-01 requires responding to the validation (as usual as described in the draft), while onion-02 will always succeed at validation stage, but instead you submit the validation response in the final CSR.

 

(Note that the final CSR in onion-02 is then signed with the certificate private key, while it contains the nonce-signature of the onion-private-key inside the ”Challenge password” field).

 

Such a ”shortcut” validation method then skips the whole sequence of having to submit for validation, wait for it to succeed and wait for response etc. Its effectively short-cuts the whole process to the very final CSR – while still keeping the same security level.

 

Från: [e-mail] <[e-mail]> För Roland Shoemaker
Skickat: den 8 juli 2020 19:48
Till: IETF ACME <[e-mail]>
Ämne: [Acme] Onion address validation extension

 

With the recent passage of SC27 at the CA/Browser Forum there are now acceptable mechanisms for validating v3 Onion addresses for inclusion in DV certificates. As such it would be good to extend ACME to be able to make use of these methods. I've written a short draft that covers what is likely to be the most interesting validation mechanism to CAs (i.e. the one that doesn't require actually using Tor directly) and would be interested in thoughts from the WG.

 

The defined ACME challenge is basically just an adapted version of the method defined in Appendix C 2.a of version 1.6.9 of the CABF BRs. I think in general the usage of a CSR as the transport mechanism for the nonces and key signature are a bit burdensome, and likely to cause some confusion for implementers (since it introduces yet another place a CSR is transferred between the client and server, with another non-standard use). That said I think the first priority in this document is to get out something that works with current CABF rules. There could be value though in defining our own validation mechanism that is a bit more straightforward alongside the existing CABF method and if/when this document is standardized we could lobby for it's inclusion as a blessed CABF validation method.

 

Thoughts?

 

https://www.ietf.org/id/draft-shoemaker-acme-onion-02.html