Re: [Acme] Onion address validation extension

[Roland Shoemaker <[e-mail]>]

I would be extremely uncomfortable specifying a mechanism like this. It
would be a large divergence from the existing ACME specification, and would
create significant traps for implementers to fall into. Specifically this
would break assumptions in most existing implementations, principally that
an order with valid authorizations can cause an issuance without further
validation. I'm also not sure how this would gel with implementations that
implement authorization reuse. It feels like this would create numerous
opportunities for an implementer to accidentally allow issuance without
actually doing any validation at all, for seemingly little real world
benefit (presumably this would only really save one or two additional
request roundtrips).

I think this is an example of one of the problems with the existing CABF
method of using a CSR as the data/signature transport when something else
would be more appropriate. The validation mechanism and the issuance
request mechanism should be as decoupled as possible to avoid people trying
to stick bits of either in the wrong place.

On Thu, Jul 9, 2020 at 8:51 AM Sebastian Nielsen <sebastian=
[e-mail]> wrote:

>
> >>ACME protocol is not meant to proceed to CSR sending until after all
>   names are validated. Breaking that would cause implementation
>   problems.
>
> Thats why there should be 2 validation types, so a client who support the
> new "skip ahead" validation type would know that it only needs to request
> onion-2 validation type, then it would immidiately skip ahead to CSR
> sending without checking if validation passed - since validation then
> occurs at CSR stage.
>
> The reason validation is required inside ACME is because ACME (usually)
> needs to contact external resources to confirm your validations, which
> incurs a delay. If you can prove the ownership of the domain inside the
> actual validation response (ergo a self-validating response that can be
> verified "offline") theres no need to use the full blown ACME
> infrastructure, then you could just submit the response inside the final
> CSR.
>
> Of course this wouldn't work for multiple domains, why the normal
> procedure with checking for validationa (onion-1) would be required.
>
> >>The CSRs are assumed to be self-signed, which is a problem here:
>
> Thats not a problem.
> What I proposed, is that you create a CSR over the normal TLS certificate
> (with its signature belongning the TLS certificate's key) BUT you put your
> onion signature (a signature of the nonce made with the onion private key)
> inside the CSR field called "CSR Challenge Password".
>
> So basically, you create a TOR signature with the TOR key, insert it in
> your final TLS CSR (as CSR Challenge Password), and then sign the TLS CSR
> with the TLS key.
>
> Meaning, that the CSR *are* self-signed, and that they CONTAIN the TOR
> signature made with the TOR private key, making the CSR being dual-use -
> both validating the onion name AND also becomes the grounds for your
> certificate generation.
>
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>