Re: [Acme] Should the DNS challenge be deterministic?

2015-11-13 Thread Ilari Liusvaara
On Fri, Nov 13, 2015 at 03:00:48PM +0100, Romain Fliedel wrote: > > > > However, the CA/B Forum validation requirements currently being > > discussed include a requirement for a "Random Token." So we'd need to > > convince them to add language that would allow something like an > > authorized

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-13 Thread Romain Fliedel
> > However, the CA/B Forum validation requirements currently being > discussed include a requirement for a "Random Token." So we'd need to > convince them to add language that would allow something like an > authorized account key perhaps the use of a random dns prefix would be sufficient ?

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Hugo Landau
>If the issuer of the DNS challenge flushes its DNS cache and checks with >the authoritative server itself, the propagation de​lay doesn't seem like >an issue. Are there particular issuers/conditions for which you believe >the issuer would have to rely on caching resolvers? This

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Jacob Hoffman-Andrews
I like the idea, and it generalizes to the other queries. For instance, you can imagine putting up an HTTP validation file that contains a list of authorized account keys, with no random token. However, the CA/B Forum validation requirements currently being discussed include a requirement for a

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Romain Fliedel
> This seems problematic, however. Changes to DNS can take time to > propagate, and changes to DNS may involve manual intervention. If an > authorization fails for any reason, the process has to be started again. +1 To avoid the cache issue I'm using short TTL but it would be easier if the DNS

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Ilari Liusvaara
On Thu, Nov 12, 2015 at 10:11:12AM +0100, Romain Fliedel wrote: > > > This seems problematic, however. Changes to DNS can take time to > > propagate, and changes to DNS may involve manual intervention. If an > > authorization fails for any reason, the process has to be started again. > > +1 >

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Ilari Liusvaara
On Fri, Nov 13, 2015 at 01:25:35AM +, Hugo Landau wrote: > On Thu, Nov 12, 2015 at 02:14:11PM -0800, Jacob Hoffman-Andrews wrote: > > I like the idea, and it generalizes to the other queries. For instance, > > you can imagine putting up an HTTP validation file that contains a list > > of

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Hugo Landau
> I think one would also have to include the endorsed EESPKI (End-Entity > SubjectPublicKeyInfo, a.k.a. the server public key) too (or at least > collision-resistant hash of it)? > > That should rarely change, so it should be quasi-constant. That works, but I'm not convinced it's necessary.

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Romain Fliedel
> > On Thu, Nov 12, 2015 at 4:05 PM, Hugo Landau wrote: > >> Currently, the DNS challenge uses a random token which changes every >> time an authorization is performed. >> >> This seems problematic, however. Changes to DNS can take time to >> propagate, > > > If the issuer of

Re: [Acme] Should the DNS challenge be deterministic?

2015-11-12 Thread Ted Hardie
On Thu, Nov 12, 2015 at 4:05 PM, Hugo Landau wrote: > Currently, the DNS challenge uses a random token which changes every > time an authorization is performed. > > This seems problematic, however. Changes to DNS can take time to > propagate, If the issuer of the DNS

[Acme] Should the DNS challenge be deterministic?

2015-11-11 Thread Hugo Landau
Currently, the DNS challenge uses a random token which changes every time an authorization is performed. This seems problematic, however. Changes to DNS can take time to propagate, and changes to DNS may involve manual intervention. If an authorization fails for any reason, the process has to be