I've reversed the roles of SAN A and SAN B. The branch has been updated.
Certificates should probably contain SAN A. If they don't, this is
liable to confuse TLS implementations and supporting infrastructure,
which doesn't expect that an SNI request for x should result in a
certificate not listing x.
You could allow extra names (which could be SAN A, or something else
entirely), but, well, why allow extra names? If you have SANs of
foo.token.acme.invalid, bar.ka.acme.invalid and example.com, something
is wrong. If you don't allow extra names, you need to check that all
naems are in {SAN A, SAN B} anyway. Or you require a SNI request for SAN
A lead to a certificate with {SAN B}, which is rather bizarre and will
probably cause problems somewhere.
This is a request-response procedure but it's a request-response
procedure being conducted in a byzantine fashion using TLS's certificate
presentation functionality. The practicalities of that mechanism must be
considered.
On Fri, Jan 22, 2016 at 10:27:25AM -0800, Andrew Ayer wrote:
> On Fri, 22 Jan 2016 16:13:07 +0000
> Hugo Landau <[email protected]> wrote:
>
> > Firstly, I've drafted a specification for tls-sni-02
> > which resolves Jehiah's concerns.
> > <https://github.com/ietf-wg-acme/acme/pull/71>
>
> I agree with jehiah's comment on GitHub that for consistency with the
> http-01 challenge, SAN A (the token) should be used for the SNI
> request, and SAN B (the keyAuthorization) should be the SAN which the
> ACME server looks for.
>
> Also, it's not necessary for the ACME server to verify that the
> returned certificate contains SAN A (the token). Seeing the
> keyAuthorization in a SAN is sufficient.
>
> I think these changes should be made because paring the challenges down
> to their essentials and making them as similar as possible makes them
> much easier to reason about. For both http-01 and tls-sni-02, the
> basic procedure would be:
>
> 1. Request a resource (file or certificate) at the domain using the
> token to identify the resource.
>
> 2. Verify that the returned resource contains the keyAuthorization.
>
> -- Andrew
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
