Subject: [Acme] Why "HTTP verification"

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Dec 2014 10:05:10 -0800

Greetings again. A few people have asked for HTTP-based verification for the certificate request, but I'm not sure that is needed. Are there environments where someone who will be able to stand up a server with a CA-issued cert on HTTPS-over-443 could not stand up such a service with a temporary self-issued cert? If not, what is the value of checking if the person can control the content on port 80?

--Paul Hoffman

---

From: Peter Bowen <[email-masked]>
Date: Tue, 2 Dec 2014 11:15:40 -0800

> Greetings again. A few people have asked for HTTP-based verification for the certificate request, but I'm not sure that is needed. Are there environments where someone who will be able to stand up…

The primary case where I see a problem is when the site already has a
trusted certificate and wants to use ACME to get a new certificate.
They are unlikely to want to replace their working certificate with a
self-signed certificate.  So the proof would need to happen at the
HTTP layer, not the TLS layer.

Thanks,
Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Dec 2014 19:44:42 +0000

> HTTP layer, not the TLS layer.

They can request a certificate for the same private key.  The
"self-signed" thing so not precise.  The real requirement would be
*some* certificate with the same key, not necessarily self-signed.
So issued by another CA should be fine.

[ Nobody has taken me up on discussing the question of whether
  unauthenticated leap-of-faith by the CA is appropriate when the
  domain is DNSSEC signed.  With signed domains verification of
  actual DNS control is substantially stronger than the other
  methods (unauthenticated email, or unauthenticated HTTP).  I hope
  this ultimately gets discussed. ]

-- 
	Viktor.

---

From: Peter Bowen <[email-masked]>
Date: Tue, 2 Dec 2014 13:41:41 -0800

> So issued by another CA should be fine.

I would hope that many sites would have a policy of rotating their
private key, as a reasonable number of clients still use the same key
for identification and key exchange.  I'm not sure what the protocol
should look like for proving possession of the old and new keys at the
same time, but it would be good to support this case.

Thanks,
Peter

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Dec 2014 16:53:49 -0500

> same time, but it would be good to support this case.

Absolutely!

Rotating the private key is one of the biggest potential wins here.
There are good reasons for not rotating keys on Key Signing Certs in
certain situations but the only reason it doesn't get done on end
entity certs is the problematic management protocols.

Automating the issue means we can drop the cert lifetime.

---

From: Ángel González <[email-masked]>
Date: Wed, 03 Dec 2014 00:23:25 +0100

> same time, but it would be good to support this case.

If the only reason for http verification is to allow a pre-existing
certificate on 443, signing a message with the current key is a much
stronger guarantee than placing a file accessible by http.

It would be possible to steal a certificate at date X and get the new
certificate at X+n, but since the stolen certificate would need to stay
current, I find hard that the attacker couldn't also have obtained a
certificate if http were used (a compromised backup maybe?). And given
that the previous certificate would still be in use, such compromise
would still be unnoticed.

Maybe require that http proof contains the new certificate signed with
the current cert ?

---

From: Eric Mill <[email-masked]>
Date: Tue, 2 Dec 2014 23:58:17 -0500

Would providing the proof in an HTTP header (on an HTTPS connection using
any cert at all) be a stronger guarantee of Real Domain Control (and not
malicious user-submitted content) than providing it in the HTTP response
body?

On Tue, Dec 2, 2014 at 6:23 PM, Ángel González <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Dec 2014 21:36:32 -0800

> HTTP layer, not the TLS layer.

I think that we can do better than this.  That's why I opened
<https://github.com/letsencrypt/acme-spec/issues/26>.

The protocol requires proof of possession for establishing a request
for a certificate.  Requiring a self-signed certificate means that you
can only use the simpleHttps (I don't see an HTTP variant here), for
completely new installations.  Presumably renewals can be protected by
periodic checks to see that the site remains valid, but it does little
for a new key.

I think that as long as there is some way to generate POP for the key
that a certificate is being issued for, it makes little sense to
require that the HTTPS connection is served with that key.  I
understand why the proposal has that, but it makes it impossible to
renew.

The SNI verification at least allows the server some information it
can used to select a self-signed certificate, and this could use ALPN
for the same thing, but that seems like overkill.  I think that I
would like to be able to have a check like this for key rollovers as
well as the initial setup, so I think that a different design is
appropriate.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 03 Dec 2014 16:01:37 +0000

On Tue Dec 02 2014 at 7:15:54 PM Peter Bowen <[email-masked]> wrote:

> > Greetings again. A few people have asked for HTTP-based verification for
> the certificate request, but I'm not sure that is needed. Are there
> environments where someone who will be able to stand up a server with a
> CA-issued cert on HTTPS-over-443 could not stand up such a service with a
> temporary self-issued cert? If not, what is the value of checking if the
> person can control the content on port 80?
>
> self-signed certificate.

Why would you need to replace it? You use SNI on some new domain...

> So the proof would need to happen at the

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Dec 2014 08:20:21 -0800

> Why would you need to replace it? You use SNI on some new domain...

That is currently only specified for the dvsni validation method.  And
it creates an additional burden on the implementation AND it makes it
much, much harder to deploy something like this.  If you have a
front-end that routes on SNI, then it would need to be modified.  The
advantage of simpleHttps is that it doesn't depend on control of the
demux point.

---

From: Peter Bowen <[email-masked]>
Date: Wed, 3 Dec 2014 08:30:08 -0800

> Why would you need to replace it? You use SNI on some new domain...

Assuming I want to get a new certificate for secure.example.org, which
is current using a certificate from Connotation, a trusted CA.  How
would using SNI on another FQDN help validate control of
secure.example.org?

The ACME proposal suggests that "DV + Proof of Possession of previous
CA-signed key" is the appropriate mechanism for "Existing valid certs,
first use of ACME."  However I don't see a clear definition of DV
outside of DVSNI.

Thanks,
Peter