Note as a further point of clarification: there may be more ease in the CNAME
delegation method, most especially because mutations on the target zone name
are possible in a way that the NS delegations could not accommodate. i.e -
_acme-challenge.label-to-validate.example.com CNAME
_acme-chall
Whoops - quickie fix on this:
It’s been a long day.
Update permission to the dynamic DNS zone that is being delegated to should be
bound to the account key that has most recently demonstrated control of the
same label, such as via a one-time DNS-01 challenge to set up the delegation.
Anyone s
Allow me to throw in a twist which might more tighten the academic discussion
over whether a static CNAME for a TXT record to a special zone at a CA (or
other third party), over which dynamic updates to the CNAM target are available.
The opposition seems to be that chasing the CNAME to the other
But there is one difference between the two proves.
1) DNS-01 : Prove is with TXT record is that you have current DNS access
2) CNAME : Prove that you have once DNS access and now Account Key access
And here is no difference to the idea to publish account key via TXT record.
Both prove one time d
[Starting a new thread for this particular fork of the conversation]
Thanks for the input, Tim! As a member of the CA/Browser Forum
Validation Working Group, and a big contributor to the BR validation
methods, your perspective on this is particularly helpful.
On 01/23/2018 08:37 AM, Tim Hollebeek
It doesn't matter if lookups chase CNAMEs, because the answer has to
include a cryptographically secure random number that was created
especially for that particular validation and was not used in previous
validations, in order to be compliant with the BRs.
Your arbitrary computable impure functi
On Tue, Jan 23, 2018 at 07:53:12PM +, Tim Hollebeek wrote:
>
> > Oh, and the method very similar to the propose one (involving static CNAME
> > as
> > persistent authentication) is being used in the wild. And due to
> > fundamential
> > nature of DNS, even static zone can result variable res
> Oh, and the method very similar to the propose one (involving static CNAME
> as
> persistent authentication) is being used in the wild. And due to
> fundamential
> nature of DNS, even static zone can result variable results for names under
> the
> zone.
By who? I don't think it's possible f
On Tue, Jan 23, 2018 at 05:03:37PM +, Tim Hollebeek wrote:
> No, the BRs codify requirements, not security goals. The Mozilla root program
> requires all CAs to comply with the baseline requirements at all times.
>
> Something similar to PCI/DSS compensating controls existed as Method 11 in
>
> On 23 Jan 2018, at 16:50, Sebastian Nielsen wrote:
>
> I think that it could be acceptable to "reuse" an old validation provided
> WHOIS is checked right?
As a general rule, relying on the accuracy of whois data for *anything* is
remarkably stupid.
Some registries try hard to publish accu
No, the BRs codify requirements, not security goals. The Mozilla root program
requires all CAs to comply with the baseline requirements at all times.
Something similar to PCI/DSS compensating controls existed as Method 11 in
the BRs previously. It was removed last year in favor of explicit requi
I have seen the BR, and what I understand, the purpose of BRs are to provide a
specific security goal.
In this case, to prevent someone from aquiring control of a domain, and then
subsuquently, after losing control of said domain, being able to still renew
and reissue certificates for said domai
> I think that it could be acceptable to "reuse" an old validation provided
> WHOIS
> is checked right?
> Eg, if a hash is made of all the WHOIS data, and all the WHOIS data stays
> identical from last validation, then theres proof that control of domain has
> not
> shifted in the meantime, which
I think that it could be acceptable to "reuse" an old validation provided WHOIS
is checked right?
Eg, if a hash is made of all the WHOIS data, and all the WHOIS data stays
identical from last validation, then theres proof that control of domain has
not shifted in the meantime, which is the main
Yes and if you avoid the random token in the primary location,
you can use the public account key announced in the dns also as static
prove.
On 1/23/2018 5:37 PM, Tim Hollebeek wrote:
Your proposed method defeats one of the goals of the BR domain control
validation requirements, which is to d
> This challenge has the big advantage that subscribers only need to do a one-
> time CNAME setup, and renewals can be reliably automated without requiring
> that renewing systems have permission to update DNS. In effect, the CNAME
> record would act like a long-term delegation permitting the CA to
Only positive responses were noted and the discussion period Rich mentioned
has passed so I've merged https://github.com/ietf-wg-acme/acme/pull/390
Thanks all,
- Daniel / cpu
On Fri, Jan 12, 2018 at 1:29 PM, Daniel McCarney
wrote:
> This removes the "tls" error. I do not think this is appropri
On Tue, Jan 23, 2018 at 10:12:39 +0100, Thomas Lußnig wrote:
> instead of an FIXED cname that does not ensure that the requestor possess
> access to the dns.
> I would prefer to use an static TXT record whith the Account Key hashed.
> This would prove that
> only an person possesing an specified pr
Hi,
instead of an FIXED cname that does not ensure that the requestor
possess access to the dns.
I would prefer to use an static TXT record whith the Account Key hashed.
This would prove that
only an person possesing an specified private key is allowed to request.
Or to use TLSA record to veri
2018-01-23 8:09 GMT+01:00 Ilari Liusvaara :
> On Mon, Jan 22, 2018 at 05:09:53PM -0800, Jacob Hoffman-Andrews wrote:
> >
> > To fix that, the CA could assist the user by providing narrowly-scoped
> > DNS hosting: It would serve only TXT records used in validating DNS
> > challenges. The CA instruc
20 matches
Mail list logo
