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
>
> 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 ?
>If the issuer of the DNS challenge flushes its DNS cache and checks with
>the authoritative server itself, the propagation delay 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
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
> 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
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
>
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
> 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.
>
> 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
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
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
11 matches
Mail list logo