As a meta point, this discussion is incomprehensible. The objective is to produce a comprehensible spec.
We should agree terms of art for the actors, certs etc. and use them consistently. On Sun, Jun 14, 2015 at 3:01 AM, 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? > > 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 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
