DNS records and delegation

427 views
Skip to first unread message

Jeremy Rowley

unread,
Oct 10, 2019, 11:42:06 PM10/10/19
to mozilla-dev-security-policy
Question, is there any prohibition against demonstration of domain control being delegated to a third party or even the CA itself? I don't think so, but figured we've discussed differences in interpretation a lot lately so wanted to see if people agreed.


Section 3.2.2.4.7 in the CAB/F requires that the CA verify a domain by "confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character."

If the CA is using a random value then the Random Value has to be unique the certificate request.

Could a third party or the CA itself set up a service of entities that hated doing domain validation? For example:



_validation.customer.com. 3600 IN CNAME _validation.domain.com.

_validation.domain.com. 3600 IN CNAME _validation.myvalidation.com.

_validation.myvalidation.com. 1 IN CNAME _<RNDVALUE>.myalidation.com.

Since each domain approval request requires an unique random value, the random value could be uploaded each time a certificate request comes in and checked.

I mean, the obvious issue is the customer.com domain would need to want to delegate this domain.com. But if you had a pretty non-technical person operating the DNS, they could set it to the domain.com name and leave their DNS settings forever.

This looks allowed under the BRs, but should it be? Or is it like key escrow - okay if a reseller does it (but frowned upon). Totally not cool if the CA does it.

Jeremy

Ryan Sleevi

unread,
Oct 11, 2019, 1:32:10 AM10/11/19
to Jeremy Rowley, mozilla-dev-security-policy
On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Question, is there any prohibition against demonstration of domain control
> being delegated to a third party or even the CA itself? I don't think so,
> but figured we've discussed differences in interpretation a lot lately so
> wanted to see if people agreed.
>

Huge thanks for bringing this up early :) Definitely the example for all
CAs :)

That said, you probably could have worded better, "demonstration of domain
control being delegated to a third party" is... probably not the best way
of framing ;)


> I mean, the obvious issue is the customer.com domain would need to want
> to delegate this domain.com. But if you had a pretty non-technical person
> operating the DNS, they could set it to the domain.com name and leave
> their DNS settings forever.
>
> This looks allowed under the BRs, but should it be? Or is it like key
> escrow - okay if a reseller does it (but frowned upon). Totally not cool if
> the CA does it.
>

This is definitely a good way of looking at it!

I'm familiar with at least one CA using an approach like this - Amazon
Trust Services, with
https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html .
There's subtlety here, though, which is why I like how you drew the
comparison to key escrow.

On first glance, it seems Amazon Trust Services is issuing certificates to
Amazon Web Services, both (through a complex structure) Affiliates, on
behalf of the user. And so it might seem that the user is pointing their
DNS to the CA, and that's how it's working.

However, when you look through the CCADB disclosures, along with the
certificates actually issued, it's clearer that the user is pointing those
records to Amazon Web Services, but the actual issuing CA is DigiCert (as
disclosed at https://www.amazontrust.com/repository/ ). It's also the case
that, if you look at how things are setup, the domain holder isn't the one
applying for the certificate - it's Amazon Web Services applying for the
certificate (i.e. they are the Applicant, not the domain owner), and AWS
configuring their own DNS records to contain a random value, to demonstrate
to the CA (DigiCert) that AWS, the Applicant, is authorized for the domain.

It's a really elegant solution, but it turns out it's not a "CA
self-dealing" kind of thing, which would have been useful as an example if
it was already allowed.

Now let's discuss how this idea could all go wrong, because it teases out a
little why the question of who is Applicant is relevant and important to
understanding.

Let's imagine that I setup the following (and I'm going to butcher this
pseudo-code, so bear with me)
_validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example
<DOMAIN-ID>.ca.example 1 IN CNAME <RNDVALUE>.random.ca.example
<RNDVALUE>.random.ca.example 1 IN TXT "{the CA challenge goes here}"

Now, whenever the CA receives a request to validate "sleevi.example", they
map that to a domain-id. They then update the CNAME, and the TXT record, to
match the CA-defined challenge value. Then, they issue a TXT record lookup
for _validation.sleevi.example, get the challenge value back, and huzzah,
the cert is authorized!

But there's a small problem with this. Who was the Applicant requesting
sleevi.example? From the CA's perspective, how does it distinguish me, the
legit domain holder, from 'evil hacker'? In the Amazon case, AWS is the
Applicant, and AWS is the one doing this fancy DNS stuff, so it's clear -
only AWS can do this, and they're who the user delegated to.

However, if the "party doing this domain dance" is != "the applicant", then
a lot can go wrong here, because they might do the dance for two different
applicants. The easiest example would be if the CA, for every CSR it
received, regardless of the Applicant, it updated the <DOMAIN-ID> for
sleevi.example - at that point, anyone in the world could get a cert for my
domain from that CA, and that would not be the good result.

This would suggest that we don't want the CA doing it, because the CA is
not the Applicant, and the goal of 3.2.2.4 is to make sure the Applicant
can demonstrate control.

Another way of looking at this is imagining the following?
- Do we think it's allowed by the BRs for the domain operator to set their
MX to be the CA, so the CA can auto-answer their own emails sent under
3.2.2.4.4.?
- Do we think it's allowed by the BRs for the domain operator to give the
CA FTP/SSH/file upload access to /.well-known/pki-validation, so that the
CA can place the answer file on the server, and then request it as the CA,
under 3.2.2.4.6?
- Do we think it's allowed by the BRs for the domain owner to set an email
of doma...@ca.example using 3.2.2.4.13 / 3.2.2.4.14, and allowing the CA
to self-acknowledge that e-mail?

I seem to recall that there is a provision in the BRs that would prohibit
this, at least in that none of the above (in the CA-controlled example) are
demonstrating the Applicant themselves has control. And we certainly know
from the above example that it could go quite poorly if naively
implemented, so that's probably the right thing.

That said, the solution Amazon uses here might be a useful solution to
allowing it. Rather than <DOMAIN-ID>, AWS uses something like
<ACCOUNT-UNIQUE-ID>, so that _validation.sleevi.example points to
<SLEEVI-ACCOUNT-UNIQUE-ID>.ca.example. In that setup, only the
<SLEEVI-ACCOUNT-UNIQUE-ID> can get new certs for sleevi.example, and any
other accounts would fail, because _validation.sleevi.example wouldn't be
pointing to <EVIL-HACKER-ACCOUNT-UNIQUE-ID>.ca.example, which is the one
the CA would update. But if we're going to go that route, we probably would
minimally want to codify that as the expectation, similar to the intent of
3.2.2.4.12 of making sure it's actually the same person.

I realize that I gave this long answer that didn't clearly answer the crux
of your question: do the BRs forbid it? The recap, with all this context,
is: I seem to recall that, in the case where it was not the Applicant
making the change, it was/is forbidden. But I can see good reason to make
it allowed, if we can get the safety guards correct.

Cynthia Revström

unread,
Oct 11, 2019, 2:38:43 AM10/11/19
to ry...@sleevi.com, Jeremy Rowley, mozilla-dev-security-policy
Hello,

I just want to add that Let's Encrypt also allows for this (at least if I
understand what you correctly)

This following is from https://letsencrypt.org/docs/challenge-types/
> Since Let’s Encrypt follows the DNS standards when looking up TXT records
for DNS-01 validation, you can use CNAME records or NS records to delegate
answering the challenge to other DNS zones. This can be used to delegate
the _acme-challenge subdomain to a validation-specific server or zone. It
can also be used if your DNS provider is slow to update, and you want to
delegate to a quicker-updating server.

Now you don't delegate it to Let's Encrypt, however you can delegate it to
a hosting provider or similar, which seems to be about the same as what AWS
is doing if I understand you correctly.

- Cynthia Revström
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Ryan Sleevi

unread,
Oct 11, 2019, 2:40:07 PM10/11/19
to Clint Wilson, Ryan Sleevi, Jeremy Rowley, mozilla-dev-security-policy
On Fri, Oct 11, 2019 at 2:10 PM Clint Wilson <cl...@wilsonovi.com> wrote:

> Apologies, but this isn't entirely clear to me. I'm guessing (hoping) my
> misunderstanding centers around a difference between the Applicant fully
> delegating DNS to the CA vs the Applicant only configuring a single CNAME
> record? If the Applicant has configured
> _validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example
> then the CA wouldn't be able to use any other <DOMAIN-ID> value to
> complete the full lookup to include the TXT record, without the Applicant
> directly changing the CNAME value.
>
> However, if the CA is fully managing this DNS, and therefore able to
> independently reconfigure:
> _validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example
> to
> _validation.sleevi.example 3600 IN CNAME
> <EVIL-HACKER-DOMAIN-ID>.ca.example
> that's clearly a very different story.
> Is it correct to think of these as two different scenarios? In my mind,
> the first scenario is the one I'm most interested in.
>

It's my fault for not being clearer of the example.

You can think of <DOMAIN-ID> as an ID computed from the domain being
requested - e.g. "sleevi.example" - rather than the account doing the
requesting (the Applicant).

In that scenario, when Evil Hacker, the Applicant, requests a cert for
sleevi.example, the CA doesn't look at the Applicant-ID. They look to see
if the domain - e.g. sleevi.example - is one that is signed up to use their
service. If so, they modify the records, and now Evil Hacker has access.

I tried to clarify this later on, that it's possible to design around; for
example, by using <SUBSCRIBER-ID>.ca.example. This is closer to what AWS
does.

There are /still/ risks with that approach though, in terms of greater
centralization of risk. Using the AWS example, if you wanted to get a
malicious cert for sleevi.example, you'd either need to compromise my DNS
provider, my DNS registrar, or my AWS account. Using the <SUBSCRIBER-ID>
example, with the CA hosting, you'd either need to compromise my DNS
provider, my DNS registrar, or... well, the CA's systems.

Allowing the CA to do this sort of flow creates real challenges, because
they're the only ones that can issue certs. For example, the CA could
refuse to use that TXT method for anyone who doesn't point to them (e.g.
who uses AWS instead of the CA). It might seem odd to suggest that CAs
might refuse issuance, but we see it all the time. After all, the whole
reason we have so many trusted CAs is because there are a number
(particularly the European CAs) that want to refuse issuance on grounds of
who is applying or how they're applying (e.g. ETSI EN 319 411-et-al
forbidding automation entirely!). So we know CAs can try to lock folks in,
and we also know that CAs' incentives, around user/account security, are
not necessarily the same as might exist with a third-party provider like
AWS.

I realize that seems like I'm suggesting a lot of ill-intent. I'm simply
trying to threat-model both the systemic weaknesses and the economic
incentives. If we allow the CAs to do this, it seems like we'd need even
stronger rules regarding Subscriber/CA authentication and identification,
and that... would likely be controversial and complex, to say the least ;)


Would there be a benefit to something like having <DOMAIN-ID> (or
> <ACCOUNT-GUID> as discussed further below) published in CAA as well? i.e.
> the Applicant publishes a whitelist of valid <ACCOUNT-GUID> values to be
> used in this type of validation-delegation-schema? I haven't thought this
> through fully, but it seems like it could help with explicitly codifying
> the requirements, especially if the CAA record is published at
> sleevi.example?
>

That's functionally what AWS is doing - it's using <ACCOUNT-GUID> instead
of <DOMAIN-ID> as the binding, and pushing that in the hop.


> This would suggest that we don't want the CA doing it, because the CA is
>> not the Applicant, and the goal of 3.2.2.4 is to make sure the Applicant
>> can demonstrate control.
>>
>> Another way of looking at this is imagining the following?
>> - Do we think it's allowed by the BRs for the domain operator to set their
>> MX to be the CA, so the CA can auto-answer their own emails sent under
>> 3.2.2.4.4.?
>>
> - Do we think it's allowed by the BRs for the domain operator to give the
>> CA FTP/SSH/file upload access to /.well-known/pki-validation, so that the
>> CA can place the answer file on the server, and then request it as the CA,
>> under 3.2.2.4.6?
>> - Do we think it's allowed by the BRs for the domain owner to set an email
>> of doma...@ca.example using 3.2.2.4.13 / 3.2.2.4.14, and allowing the
>> CA
>> to self-acknowledge that e-mail?
>>
>> I seem to recall that there is a provision in the BRs that would prohibit
>> this, at least in that none of the above (in the CA-controlled example)
>> are
>> demonstrating the Applicant themselves has control. And we certainly know
>> from the above example that it could go quite poorly if naively
>> implemented, so that's probably the right thing.
>>
>
> Agreed with the conclusion, though I can't find a clear statement to this
> effect so it remains more of a grey area than I'd like :(
> The way I understand it is that currently the BRs are written such that
> only when the CA is itself the Applicant can the CA compliantly perform the
> 3 flows you outlined above (and there's some stuff about affiliates that
> expands that a bit, but not much). But making that even clearer would be
> pretty nice.
>

Yeah, that's my recollection/understanding as well, and agree, we can make
it clearer that this is/should be prohibited, and then discuss how we can
go allowing it.


> That said, the solution Amazon uses here might be a useful solution to
>> allowing it. Rather than <DOMAIN-ID>, AWS uses something like
>> <ACCOUNT-UNIQUE-ID>, so that _validation.sleevi.example points to
>> <SLEEVI-ACCOUNT-UNIQUE-ID>.ca.example. In that setup, only the
>> <SLEEVI-ACCOUNT-UNIQUE-ID> can get new certs for sleevi.example, and any
>> other accounts would fail, because _validation.sleevi.example wouldn't be
>> pointing to <EVIL-HACKER-ACCOUNT-UNIQUE-ID>.ca.example, which is the one
>> the CA would update. But if we're going to go that route, we probably
>> would
>> minimally want to codify that as the expectation, similar to the intent of
>> 3.2.2.4.12 of making sure it's actually the same person.
>>
>>
> It seems like a provision to the effect of "The CA can't modify DNS
> records in an Applicant's DNS Zone(s)" is minimally necessary for this to
> be safe? That is, even if the Applicant delegates their DNS fully to a CA
> and points _validation.sleevi.example to
> <SLEEVI-ACCOUNT-UNIQUE-ID>.ca.example, regardless of whether the CA is
> technically capable of independently doing so, only the Applicant should be
> authorized to initiate a change where _validation.sleevi.example points to,
> but the CA can modify the DNS records in the zone(s) it owns (ca.example).
> The chain of DNS lookups need to remain transparent and explicit.
> The use of <ACCOUNT-GUID> works just as well for us as the <DOMAIN-GUID>
> since architecturally a Domain ID is directly tied to an Account ID, so
> would be supportive of requiring the <ACCOUNT-GUID> (and doing so seems
> like it would fit in better with BR language around Applicants).
>

Just to clarify: the risk scenario I was trying to describe is where
<DOMAIN-ID> is *not* linked to <ACCOUNT-ID>. If you don't have that, all
bets are off. So it seems that, before saying it's copacetic, we need
language to make clear the Right Way and the Dangerous Way, at least with
respect to CAs.


> With regards to changes in the BRs, it seems like we need to encapsulate
> some specifics to how the DNS delegation can operate and identify what
> safety guards are necessary for this be equivalent to current methods. As a
> more minor change, would we also need to update the definition of Random
> Value so that it can be something used by the CA's Validation system
> directly, instead of something only specified to the Applicant?
>

Thanks, that's another good point about why prohibited - the Random Value
is specified to the Applicant, which is true in the AWS case (AWS is the
Applicant, DigiCert is the CA), but not true in the CA-hosting-the-CNAME
case.

But yeah, I agree with the overall approach: In order to say this is safe
and good, we'd need to specify a clear and precise algorithm that made sure
the relevant safe guards were in place.

Doug Beattie

unread,
Oct 11, 2019, 3:14:18 PM10/11/19
to ry...@sleevi.com, Clint Wilson, mozilla-dev-security-policy, Jeremy Rowley
Ryan,

Are you recommending that:
a) we need a new domain validation method that describes this, or
b) those CAs that want to play with fire can go ahead and do that based on
their own individual security analysis, or
c) we need a clear policy/guideline in the BRs or root program that MUST be
followed when the CAs (maybe other entities) are updating DNS with random
values?

I'm pretty sure I know the answer (none of the above).

Ryan Sleevi

unread,
Oct 11, 2019, 3:32:46 PM10/11/19
to Doug Beattie, ry...@sleevi.com, Clint Wilson, mozilla-dev-security-policy, Jeremy Rowley
On Fri, Oct 11, 2019 at 3:14 PM Doug Beattie <doug.b...@globalsign.com>
wrote:

> Ryan,
>
> Are you recommending that:
> a) we need a new domain validation method that describes this, or
> b) those CAs that want to play with fire can go ahead and do that based on
> their own individual security analysis, or
> c) we need a clear policy/guideline in the BRs or root program that MUST be
> followed when the CAs (maybe other entities) are updating DNS with random
> values?
>
> I'm pretty sure I know the answer (none of the above).
>

I'm suggesting the BRs forbid this (and the other examples) from being done
by CAs today, so (b) is not an option. This is the same as the BRs
forbidding a CA from, say, using the serial number in a certificate they
issue to act as a 'continuous authorization' for issuance.

I'm totally open for a discussion about (a)/(c) - done correctly, it would
allow us to achieve the ideal property, that:
1) We constantly go back to the DNS as the source of truth. For example, we
could remove the reuse of validation data entirely here / reduce it to
something small (like 5 minutes).
2) The domain name owner can voluntarily decide to make a continual
authorization to a CA /for their account/, just like they can make a
continual authorization to their hosting provider or other authorized entity

There are a variety of challenges that could cause things to go wrong. We'd
need to address those. They might be insurmountable, but it's worth
discussing. This seems like potentially something suited for the IETF ACME
WG, especially for the nuances of the security properties and ensuring wide
review, not just among CAs and a few browsers.

Corey Bonnell

unread,
Oct 12, 2019, 8:15:45 AM10/12/19
to mozilla-dev-s...@lists.mozilla.org
> I'm suggesting the BRs forbid this (and the other examples) from being done
> by CAs today, so (b) is not an option. This is the same as the BRs
> forbidding a CA from, say, using the serial number in a certificate they
> issue to act as a 'continuous authorization' for issuance.

At the risk of derailing this discussion away from DNS-based validation, I have to ask: how do the BRs prohibit domain validation using the serial number of a newly issued, publicly trusted certificate as the Random Value as a means to demonstrate "continuous authorization"? It seems to me that would be method 10 ("TLS Using a Random Number"), provided there is at least 112 bits of CSPRNG output in the serial number. This interpretation was brought up a few years ago on the CAB Forum Validation WG mailing list by Peter Bowen [1], and no objection was raised to this interpretation.

[1] https://cabforum.org/pipermail/validation/2017-May/000557.html



Clint Wilson

unread,
Oct 13, 2019, 10:28:19 PM10/13/19
to ry...@sleevi.com, Jeremy Rowley, mozilla-dev-security-policy
On Thu, Oct 10, 2019 at 11:32 PM Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > Question, is there any prohibition against demonstration of domain
> control
> > being delegated to a third party or even the CA itself? I don't think so,
> > but figured we've discussed differences in interpretation a lot lately so
> > wanted to see if people agreed.
> >
>
> Huge thanks for bringing this up early :) Definitely the example for all
> CAs :)
>

Thank you for the response, insight, and feedback here! Really, really
helpful in clarifying some of the open questions/discussions we've been
having.
> _validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example
> <DOMAIN-ID>.ca.example 1 IN CNAME <RNDVALUE>.random.ca.example
> <RNDVALUE>.random.ca.example 1 IN TXT "{the CA challenge goes here}"
>
> Now, whenever the CA receives a request to validate "sleevi.example", they
> map that to a domain-id. They then update the CNAME, and the TXT record, to
> match the CA-defined challenge value. Then, they issue a TXT record lookup
> for _validation.sleevi.example, get the challenge value back, and huzzah,
> the cert is authorized!
>
> But there's a small problem with this. Who was the Applicant requesting
> sleevi.example? From the CA's perspective, how does it distinguish me, the
> legit domain holder, from 'evil hacker'? In the Amazon case, AWS is the
> Applicant, and AWS is the one doing this fancy DNS stuff, so it's clear -
> only AWS can do this, and they're who the user delegated to.
>
> However, if the "party doing this domain dance" is != "the applicant", then
> a lot can go wrong here, because they might do the dance for two different
> applicants. The easiest example would be if the CA, for every CSR it
> received, regardless of the Applicant, it updated the <DOMAIN-ID> for
> sleevi.example - at that point, anyone in the world could get a cert for my
> domain from that CA, and that would not be the good result.
>

Apologies, but this isn't entirely clear to me. I'm guessing (hoping) my
misunderstanding centers around a difference between the Applicant fully
delegating DNS to the CA vs the Applicant only configuring a single CNAME
record? If the Applicant has configured
_validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example
then the CA wouldn't be able to use any other <DOMAIN-ID> value to complete
the full lookup to include the TXT record, without the Applicant directly
changing the CNAME value.

However, if the CA is fully managing this DNS, and therefore able to
independently reconfigure:
_validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example
to
_validation.sleevi.example 3600 IN CNAME <EVIL-HACKER-DOMAIN-ID>.ca.example
that's clearly a very different story.
Is it correct to think of these as two different scenarios? In my mind, the
first scenario is the one I'm most interested in.
Even then, I may be oversimplifying things since even in scenario 1 we
could encounter something like this happening (and would want to ensure
it's forbidden):
_validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example
<DOMAIN-ID>.ca.example 1 IN CNAME <EVIL-HACKER-DOMAIN-ID>.ca.example
<EVIL-HACKER-DOMAIN-ID>.ca.example 1 IN CNAME <RNDVALUE>.random.ca.example
<RNDVALUE>.random.ca.example 1 IN TXT "{the CA challenge goes here}"

Would there be a benefit to something like having <DOMAIN-ID> (or
<ACCOUNT-GUID> as discussed further below) published in CAA as well? i.e.
the Applicant publishes a whitelist of valid <ACCOUNT-GUID> values to be
used in this type of validation-delegation-schema? I haven't thought this
through fully, but it seems like it could help with explicitly codifying
the requirements, especially if the CAA record is published at
sleevi.example?


> That said, the solution Amazon uses here might be a useful solution to
> allowing it. Rather than <DOMAIN-ID>, AWS uses something like
> <ACCOUNT-UNIQUE-ID>, so that _validation.sleevi.example points to
> <SLEEVI-ACCOUNT-UNIQUE-ID>.ca.example. In that setup, only the
> <SLEEVI-ACCOUNT-UNIQUE-ID> can get new certs for sleevi.example, and any
> other accounts would fail, because _validation.sleevi.example wouldn't be
> pointing to <EVIL-HACKER-ACCOUNT-UNIQUE-ID>.ca.example, which is the one
> the CA would update. But if we're going to go that route, we probably would
> minimally want to codify that as the expectation, similar to the intent of
> 3.2.2.4.12 of making sure it's actually the same person.
>
>
It seems like a provision to the effect of "The CA can't modify DNS records
in an Applicant's DNS Zone(s)" is minimally necessary for this to be safe?
That is, even if the Applicant delegates their DNS fully to a CA and points
_validation.sleevi.example to <SLEEVI-ACCOUNT-UNIQUE-ID>.ca.example,
regardless of whether the CA is technically capable of independently doing
so, only the Applicant should be authorized to initiate a change where
_validation.sleevi.example points to, but the CA can modify the DNS records
in the zone(s) it owns (ca.example). The chain of DNS lookups need to
remain transparent and explicit.
The use of <ACCOUNT-GUID> works just as well for us as the <DOMAIN-GUID>
since architecturally a Domain ID is directly tied to an Account ID, so
would be supportive of requiring the <ACCOUNT-GUID> (and doing so seems
like it would fit in better with BR language around Applicants).


> I realize that I gave this long answer that didn't clearly answer the crux
> of your question: do the BRs forbid it? The recap, with all this context,
> is: I seem to recall that, in the case where it was not the Applicant
> making the change, it was/is forbidden. But I can see good reason to make
> it allowed, if we can get the safety guards correct.
>

With regards to changes in the BRs, it seems like we need to encapsulate
some specifics to how the DNS delegation can operate and identify what
safety guards are necessary for this be equivalent to current methods. As a
more minor change, would we also need to update the definition of Random
Value so that it can be something used by the CA's Validation system
directly, instead of something only specified to the Applicant?


bif

unread,
Oct 24, 2019, 7:02:27 AM10/24/19
to mozilla-dev-s...@lists.mozilla.org
There's a specific provision in the CAA checking algorithm that allows CAs to not even bother checking CAA records if CA operates the nameservers for the domain.
Reply all
Reply to author
Forward
0 new messages