Re: [Acme] Why "HTTP verification"

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 <angel@tls.16bits.net> wrote:

> Peter Bowen wrote:
> > On Tue, Dec 2, 2014 at 11:44 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> 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 ?
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>

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