Re: [Acme] various issues with the spec

[Fraser Tweedale <[e-mail]>]

On Sun, Jun 14, 2015 at 08:06:46AM +0200, Stefan Bühler wrote:
> On Sun, 14 Jun 2015 11:17:38 +1000
> Fraser Tweedale <[e-mail]> wrote:
> 
> > On Sun, Jun 14, 2015 at 12:24:32AM +0200, Stefan Bühler wrote:
> > > * dvsni: Please don't require the domain name which is being
> > > validated to be part of subjectAltName; configuring such
> > > certificate might break a working setup in production, when it
> > > "wins" over an already present and valid certificate for the domain.
> > > 
> > No, this certificate is only presented for the host
> > `<nonce>.acme.invalid'.
> 
> You are thinking of a setup where you configure explicitly which
> certificate is used for which SNI value. But gnutls for example has a
> nice feature where you can just give it all your certificates, and it
> will pick the matching one automatically.
> 
Do you propose that the certificate *not* bear the domain name being
validated in *either* the Subject DN or subjectAltName extension?

This probably does not affect the protocol, but I think is nice to
include it anyway for the sake of being explicit.  Can you identify
any existing server software which would is incompatible with ACME
dvsni due to the validation certificate bearing the name being
validated?

> > > * dvsni: `The public key is the public key for the key pair being
> > >   authorized`. I hope this was just an accident, this would be
> > > *really* wrong to require.
> > > 
> > Why would this be wrong?  Remember that this certificate is
> > generated as part of, and intented for use only as part of the
> > authorization workflow.  It has no bearing on certificates
> > eventually issued for the domain name being authorized.
> 
> I don't want my webserver to see my account private key, ever. Am I
> really the first guy to have a problem with that?
> 
> > > * dvsni: Don't require it to be a self-signed certificate - what
> > > does it matter who signed it?
> > > 
> > It must be signed by the account key as evidence that the entity
> > performing the authorization controls the account key.
> 
> What exactly is the attack scenario here if this is not checked?
> Person A playing MITM to give control over domain B to account C, and
> account C started the authorization but didn't actually want it to
> succeed?
> 
> If you really require such evidence, perhaps it could be required to
> have the certificate signed by the account key instead of being
> self-signed.
> 
> regards,
> Stefan

You've convinced me on these latter points - the certificate should
be signed by the account key but the key could be a different key
(i.e. not a self-signed cert) - and this means that the web server
need not have access to the account private key.

Cheers,
Fraser