On Sun, 14 Jun 2015 17:01:37 +1000 Fraser Tweedale <[email protected]> wrote:
> 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 <[email protected]> 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? Yes, neither set in the common name nor in subjectAltName; I think gnutls would find both. Just for the record, I'd be fine with adding a subjectAltName like `DNS:<dnsname>.acme.invalid', so the domain name is at least present in some form (although I don't know what to gain from it). > 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? I happen to know such webserver: lighttpd 2 (not released yet); see http://doc.lighttpd.net/lighttpd2/mod_gnutls.html > > > > * 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. > > 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. Ok. regards, Stefan _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
