Re: [Acme] Why "HTTP verification"

[Ángel González <[e-mail]>]

Peter Bowen wrote:
> On Tue, Dec 2, 2014 at 11:44 AM, Viktor Dukhovni <[e-mail]> wrote:
> > On Tue, Dec 02, 2014 at 11:15:40AM -0800, Peter Bowen wrote:
> >
> >> 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.
> >
> > 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.
> 
> 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

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 ?