Discussion Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

[Slaughter, Michael]

Ballot SC-082 is proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly).

 

— Purpose of Ballot SC-082 —

 

The purpose of this ballot is to clarify the practice of CA Assisted DNS Validation and add constraints under Method 7 (3.2.4.4.7 DNS Change). Modification of other domain validation methods and the introduction of new domain validation methods are not in scope of this ballot but may be addressed in a future ballot.

 

Background:

 

CA Assisted DNS Validation is the practice where Certification Authorities (CAs) instruct Applicants to create Canonical Name (CNAME) records specifically for the purpose of assisting the Applicant with Domain Control Verification (DCV) of their domain.

At F2F 59 (July 23’), the Validation Subcommittee of the Server Certificate WG presented the following conclusions on the practice of CA Assisted DNS Validation:

• More clarity is needed around the practice
• Applicants generally delegate the performance of many aspects of operating a website.
• If done correctly, allowing Applicants to delegate the placement of the Random Value/ Request Token boosts agility and automation.
• There are reasonable interpretations of the BRs that such delegation is already allowed today.

A tiger team was formed to threat model CA Assisted DNS Validation and propose modifications to the BRs to add clarity and constraints around the practice under section 3.2.2.4.7. The results of the threat model exercise [1] were presented and discussed at F2F 60 [2] and F2F 61 [3].

 

Overview of Changes:

• New definition: Canonical Authorization Domain Name
• Add Canonical Authorization Domain Names into section 3.2.2.4.7 (DNS Change)
• Addition of constraints around the usage of Canonical Authorization Names by CAs
  • Enforce CNAMEs are unique to an Applicant and not shared with multiple Applicants
  • Expire DNS lookup results after 8 hours
  • Restrict the type of DNS records located in zones used for this purpose.

 

References:

[1] Validation SC Threat Modeling Doc: https://docs.google.com/document/d/1G2GYb0eg0rqE23f844J8qs7RYGU1jFVDsU5Pf7UYg3g/edit

[2] F2F-60 Presentation: https://docs.google.com/presentation/d/1M80h1N7MpBuqvZS0FdtJ_zj-AsaFxu7BNBSUJ6Ia5jU/edit?usp=sharing

[3] F2F-61 Presentation: https://docs.google.com/presentation/d/1rKW7I5jOYh37jQFtd1S-fKIs0j-dCAyUUU-fq_C8UKw/edit?usp=sharing

[4] https://github.com/cabforum/servercert/pull/501

 

The following motion has been proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly)

 

GitHub pull request for this ballot: https://github.com/cabforum/servercert/pull/501

 

— Motion Begins —

 

MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version 2.0.9 as specified in the following redline:

https://github.com/cabforum/servercert/compare/911e47e2657de64a7455ba16319b96ffdb5816cd..76f6e1b7a39f44f6e7b5a1bc0c4a0df744457d84

 

— Motion Ends —

 

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (7 days)

 

- Start: 2024-11-12 17:30:00 UTC

- End no earlier than: 2024-11-19 17:30:00 UTC

 

Vote for approval (7 days)

 

- Start: TBD

- End: TBD

 

 

[Jacob Hoffman-Andrews]

Thanks for putting this all together. The supporting documents are very well done.

I'm very much in support of this clarification. In particular, CA Assisted DNS Validation makes it easier for Subscribers to secure their certificate issuance automation. Right now, it's common for ACME clients to be configured with API tokens to update DNS for the purpose of automatically performing ACME DNS-01 challenges. But this is risky because such a token is usually very high-privilege, allowing modifications to an entire zone. There are ways to limit that privilege, but they tend to be more complicated to manage. If more CAs implement CA Assisted DNS Validation, Subscribers can rely on that rather than deploying DNS API tokens.

This may also reduce the burden of maintaining an ACME client. Certbot, one of the more popular clients, maintains a variety of plugins to talk to various DNS providers' APIs. Maintaining these plugins over time is a big task, and Certbot is not the only client with an ecosystem of DNS providers. If CA Assisted DNS Validation becomes popular, it may be possible for ACME clients to deprecate the DNS plugins.

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CF06C88E-922A-47D9-A34F-382EDC82BB95%40amazon.com.

[Tim Hollebeek]

DigiCert votes YES on SC-082

--

[Mads Egil Henriksveen]

Buypass ABSTAINS from voting on ballot SC-082. We agree with Dimitris that more discussion is required.

 

Regards

Mads

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: tirsdag 12. november 2024 18:33
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Discussion Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Ballot SC-082 is proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly).

--

[Michael Guenther]

SwissSign votes 'yes' on SC-082

 

Mike

 

Note: Second try as I believe that the first one was not sent correctly

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Tuesday, November 12, 2024 6:33 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Discussion Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Ballot SC-082 is proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly).

--

[Aaron Gable]

Well, SC-082 has failed during the voting period. I'd like to put down some thoughts about how I think something in this same direction could be improved.

Fundamentally, I have two competing thoughts about "CA-Assisted DCV":

1) The security model is sound and has real advantages; but

2) The ergonomics and optics are bad.

It's important to recognize that the assertion demonstrated by CA-Assisted DCV is different from the assertion demonstrated by traditional DNS Change validation. The traditional method (in which the Applicant places a Random/Request Token into DNS themselves) verifies that the Applicant controls DNS for the name in question here and now: the token is time-bounded. In contrast, CA-Assisted DCV can only verify that the domain owner at some time in the past permitted a specific account at a specific CA to issue for this domain at any time.

To be clear, I think that's a fine security model. Basing validation on a DNS record that has the semantics "account X at CA Y may issue a certificate for this domain name" is a good idea, in my opinion. It has lots of advantages -- no need for DNS API keys to be accessible for every renewal, long-lived DNS records that can be validated by independent third parties, etc. -- and good security properties.

However, I don't think that CA-Assisted DCV is a good way to achieve those properties. In particular, the fact that it still involves a Random Token even though checking for the presence of that random token achieves nothing feels like pulling the wool over one's eyes. It's pretending that this validation method has security properties (namely, applicant control of DNS at the moment validation is performed) that it simply doesn't have.

So in order to allow this sort of long-term authorization that doesn't need a random token, I think we should do so openly and clearly. We should do so with a separate DCV method, not within the existing DNS Change. And with that clean slate, we should do it with a mechanism other than CNAME records -- for example, we could use a syntax similar to CAA records to specify a CA's URL and an accounturi. We could even let the record contain a fingerprint of the desired certificate pubkey, allowing issuance only for that pubkey (I've been calling this idea "DANE for CAs").

Would this be a larger change than the very simple clarification proposed by SC-082? Yes, absolutely. But I think it would also provide a clearer, cleaner path forward, in which both the intentions and resulting security properties of the validation method are clear to all readers and relying parties.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAN3x4Qnv3AXVCyOMobE0acPp9M4jkz9L0_dpSbxMYD7uszSnmQ%40mail.gmail.com.

[Wayne Thayer]

Hi Aaron,

I agree with your points about creating a new validation method. However, we still need to address the use of CNAME delegation to the CA in the existing method 7, so I don't see your proposal as an alternative to this ballot but rather a natural follow-on. Even if I read the current TLS BRs with a "default deny" mindset, I have to squint really hard to conclude that CNAME delegation to a domain controlled by the CA is not currently permitted. One option would be to clearly forbid the practice, but doing that in the midst of an increasing push for automation seems counterproductive to me. That leaves the option presented in this ballot, which is to put up guard rails that make the practice safe. With this in mind, I hope we can continue discussing the existing ballot and get it passed, before moving on to creating new and improved methods.

Thanks,

Wayne

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnEreweqtiiQx5%3D1iy1oDtvB6TD%3Db5rcDRuVtEbhhxZMTpXA%40mail.gmail.com.

[Tim Hollebeek]

Right.

 

People are already doing this. A few years ago, we decided that it would be better to clarify explicitly that it is allowed, and to remove some unclear wording that could be misread as disallowing it.

 

We need to stop discussing the same points over and over for years on end and get this ballot passed.

 

-Tim

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAPh8bk_H-X%2BzqrQdeqUnFfvOAcmshPrfEz6m8Hr2SQBL-io%2BEQ%40mail.gmail.com.

[Aaron Gable]

I know the history behind this ballot, and I understand why it was formulated in this way. But clearly this ballot as-is did not pass, as it did not have the support of enough certificate consumers. I'm proposing an alternate path forward that may have a clearer path to success, and bring with it additional benefits at the same time.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SN7PR14MB649211D5F69EBB4A01394E8283362%40SN7PR14MB6492.namprd14.prod.outlook.com.

[Trevoli Ponds-White]

Thank you Tim and Wayne. I want to also remind everyone of the point Jeremy raised when we began discussing this almost two years ago. As Tim said this is already something that happens today. Outside of entities adjacent to the Forum there are other third parties that offer this kind of service. If we ban the practice it only bans it for CAs not third parties.

[Henry Birge-Lee]

Hi all,

I wanted to briefly chime in on some points from an outsider's perspective and having studied permitted validation methods a bit from both a threat modeling and deployment perspective.

First: I wanted to say I agree with Wayne that even with a strict reading of the BRs I feel CNAMEing to a CA-controlled validation endpoint is something that would be permissible. CNAMEs are part of proper DNS resolution that CAs have to follow and unless there is an explicit forbiddance of this practice, it just sort of works.

Second: I think actually "banning" this practice would not accomplish all that much and could incur collateral damage as well as be quite difficult to draft normative requirements for. I say this because: 1) there are many ways infrastructure can be redirected or pointed to other sources. For example, validation can be done via email to a CAA email contact per 3.2.2.4.13. CA-assisted validation could be done by instructing subscribers to put a CA-controlled email address in their CAA records. This method utilizes completely different mechanisms than the CNAME solutions previously discussed but has similar threat modeling implications. Another solution could involve every query for a URL below /.well-known/pki-validation or /.well-known/acme-challenge being 301 redirected to a domain controlled by the CA. Truly banning this practice would possibly require a rigorous enumeration of all possible methods. Distributed infrastructure design relies heavily on the ability to point resources to other resources and this can be done at many layers of the application stack, so it's quite hard to catch everything. 2) Even if you take a more general approach than hunting down specific redirect methods and say something like "the CA MUST not assist in operating a resource involved in domain control validation", there is still potentially an organizational boundary issue (e.g., I use Google Trust Services and Google Cloud Platform to manage my infrastructure, if I ask CGP to get a cert from GTS is the CA somehow inappropriately operating validation-related resources?) and 3) Trevoli's point that any requirements would not affect third parties that could just come in and offer that service.

Third: with all these points, I still think Aaron brings up a very important point that approving this language is more significant than just moving forward with the proposed wording change. I think it is worth reviewing the practices of domain control validation from a more theoretical level and really asking why they are the way they are and what is the intent. If you read the current baseline requirements, the vast majority of the DCV methods permitted today revolve around some sort of online operational control of a network resource affiliated with the domain in question at the moment of validation. The current methods I would even argue seem to go out of their way to make this explicit (e.g., the method is agreed-upon website change v2 not CA checks for stuff that happened to be sitting on your website all along). However, with the techniques I described in the second point and the original techniques that lead to this ballot, I would say it is not entirely obvious that the requirement of such online operational control is being strictly enforced in the BRs. However I feel many seem to act as if online operational control is in the spirit of the BRs and techniques that directly bypass this requirement are inherently questionable. With this context in mind, adopting this ballot would have had a much more significant change than just wording addition: it would be the first explicit permission of a completely passive domain control method.

For those who have deployed modern distributed infrastructure, I am sure you can realize the significant market advantage of a technique that would allow a certificate requesting agent with no operational control of a domain to obtain a trusted certificate strictly via their authenticated CA credentials. Certificates could be requested and deployed entirely by agents that sat on the boxes that needed to have certificates and these agents would not need to have any complex way to either distribute certificates/private keys or coordinate the completion of domain control validation challenges. They could all operate independently and just renew certs as needed.

With this in mind, I think Aaron's points are important to consider. If you are going to significantly change how a PKI client is allowed to operate, is this really the way you want to implement it? With a totally deprecated method of a CA running a DNS validation service strictly for itself that it then uploads a token to and checks itself via CNAME redirect ? Wouldn't a much cleaner and more forward thinking implementation be to put authorized CA account data into something like CAA records which are actually meant for this?

In conclusion, I am not against this language change, but I would ideally like to see the PKI tackle the problem head on and propose a more comprehensive solution for passive domain control validation than seemingly accidently enabling it via a language clarification.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/580ca82a-a228-42ce-a50f-7022428fba81n%40groups.cabforum.org.

[Michael Slaughter]

Thank you for the thoughtful feedback, considerations and discussion on this thread.

We seem to be converging on two distinct open questions (whose answers are NOT mutually exclusive):

1. How should we proceed on implementations of Assisted DCV under Method 7? (Constrain them, ignore them, ban them).
2. What does a new, improved, better and more focused automation oriented DCV method(s) look like?

There is broad agreement that developing more robust automation-oriented DCV methods is a worthwhile endeavor. Developing new automation-oriented DCV methods was always intended to be the next step of this effort following the Method 7 clarification ballot. That discussion should continue especially in light of the proposed changes to certificate validity and domain validation reuse periods.

The more immediate question is still (and has been for many years) what to do about Method 7. I am still very much in favor of adding constraints to CA operated implementations in response to the threats identified during the threat modeling exercise and subsequent discussions. Alternatively we could either explicitly ban the practice or explicitly continue to ignore it. I agree with others that banning the practice is not helpful or practical and is potentially harmful for the reasons Henry and Trev called out. Ignoring the problem is also a choice, but one that does nothing does to address any of the concerns raised about the current practice under Method 7.

As Aaron called out, the proposed language did not get support from certificate consumers. It would be helpful to have a more concrete understanding from the community on what (if any) specific changes to ballot language or structure would mitigate those concerns and craft something that will pass.

Slaughter

[Roman Fischer]

Dear Aaron,

 

Thanks for this possible way forward.

One thing to consider: Binding to the public key of the certificate will make it impossible for some CAs to use this method as they don't allow to re-use a keypair at all.

 

Thx
Roman

 

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Dienstag, 3. Dezember 2024 00:19
To: server...@groups.cabforum.org
Subject: Re: [Servercert-wg] Discussion Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Well, SC-082 has failed during the voting period. I'd like to put down some thoughts about how I think something in this same direction could be improved.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnEreweqtiiQx5%3D1iy1oDtvB6TD%3Db5rcDRuVtEbhhxZMTpXA%40mail.gmail.com.

[Tobias S. Josefowitz]

Hi Tim,

On Tue, 3 Dec 2024, 'Tim Hollebeek' via Server Certificate WG (CA/B Forum)
wrote:

> People are already doing this.

This statement is somewhat ambiguous. Are any CAs actually doing this, or
is it that some companies are doing this in conjunction with CAs, CAs that
might even be subsidiaries or otherwise linked to this first company,
which receives the delegation by CNAME?

My understanding so far was that it was the latter. This detail may not
be, or let me be clear, is probably not material to the security
properties of this practice, but it is clearly material to whether or not
a CA itself is allowed to participate in this on the Applicant's side
under a "default deny" intepretation.

> A few years ago, we decided that it would be better to clarify
> explicitly that it is allowed, and to remove some unclear wording that
> could be misread as disallowing it.
>
> We need to stop discussing the same points over and over for years on
> end and get this ballot passed.

I do not vividly remember such a decision, but I clearly would not rule
out that such a decision has been reached at some point. Yet, this not
having materialized yet or the fact that SC-082 has failed might also give
rise to the idea that maybe such consensus as there once has been may not
have been as solid, or at least no longer exists in that same form,
currently?

[Tobias S. Josefowitz]

Hi Henry,

On Tue, 3 Dec 2024, Henry Birge-Lee wrote:

> First: I wanted to say I agree with Wayne that even with a strict reading
> of the BRs I feel CNAMEing to a CA-controlled validation endpoint is
> something that would be permissible. CNAMEs are part of proper DNS
> resolution that CAs have to follow and unless there is an explicit
> forbiddance of this practice, it just sort of works.

I think the core point of the argument for why it would not be allowed is
not in the CNAME, in the sense that a CNAME to anywhere else but a CA
would indeed delegate "authority" to participate in DV for the delegating
domain/hostname. The crux would rather be in whether the CA may be on the
receiving end of such a delegation, and wilfully participate in it - or
even encourage such scenarios towards subscribers.

A CA participating in DV on both sides in this way can for sure be
interpreted as more or less a circumvention of the responsibilities placed
on CAs, in the sense that instead of DV testing domain control of the
applicant, it would instead test if authority to participate in DV on the
subscriber's side has been delegated to the CA. Furthermore, there would
be no prescription from the BRs as to how the CA would have to exercise
the duty/privilege delegated to them whatsoever.

We have heard strong arguments for a "default deny" interpretation of CABF
documents before, and certainly with such a "default deny" interpretation,
I think a very likely conclusion simply must be that for the CA to
participate in DV this way changes the structure of what is established
during DV so much that we cannot assume CAs would be allowed to
participate in it in this way, even if we cannot and do not place such
restrictions on other entities. If this should be allowed, it should be
explicit; we cannot encourage "getting creative" with the Baseline
Requirements even in cases where some might consider it beneficial.

Tobi

[Henry Birge-Lee]

Hi Tobi,

Great points. I see your opinion that CNAME is not the problem, but a CA choosing to partake in a practice where it CNAMEs to itself is questionable.

With that said, I think the question arises that there is nothing today stopping a third-party from offering such a service (e.g., delegated DCV challenges so that domains only need to configure a static pointer to the new DCV challenge manager). In fact, a popular DNS service ACME DNS (https://github.com/joohoi/acme-dns) offered exactly this. For a long time they had a hosted service at acme-dns.io where users could make an account, point to with a CNAME under _acme-challenge.your-domain.example.com and then easily use a REST API to make TXT records. They also published an ACME DNS client plugin for certbot: https://github.com/acme-dns/acme-dns-client

Reading these CA/B Forum discussions, I also got really interested in seeing what was possible beyond the DNS ecosystem and also, what is the minimum action that can be taken by a party requesting a cert. I came up with an experimental project for a fully-passive and stateless domain control validation system:

https://github.com/birgelee/passive-dcv

Essentially, after creating a "magic" 301 redirect for the .well-known directory of a domain's webserver, you simply ask the system for a cert with a secret key that corresponds to the redirect you put in place. You don't have to even register (the system contains no state regarding its clients and you can get a cert in a single HTTP POST request).

Given this system is fully functional (and I have a Let's Encrypt staging-environment version hosted at pdcv.henrybirgelee.com), it makes me ask the question:

Is this somehow more secure than a CA just checking for the presence of a particular static redirect or static CNAME value (obviously given proper CA/B Forum regulations regarding such behavior)?

Is a 3rd party unaffiliated with CAs running such services considered more secure than CAs running these services themselves?

Where is the line drawn, if a CA reseller offers such a service as well as the sale of certificates from an affiliated tested CA, is that a problem? I could easily see services coming along to offer dcv-free certificates based on static delegations through CNAME, NS, HTTP redirects or just putting in the 3rd-party's email.

Also, I should mention, a major vulnerability with putting in a standing authorization for say "myac...@ca.example.com" in something like a CAA record is account compromise. However, this is already an existing attack vector in the PKI because of validation reuse. Domain validations can be reused and associated with a subscriber account. So if I can hack your CA subscriber account, I can get a cert without DCV as long as I ask in a short enough window after you got a cert (which is public knowledge thanks to CT). Thus, I think it is comparably secure to authorize "myac...@ca.example.com" with a static record as long as I keep that record in place.

Finally, I think its worth thinking about automation. Many certificate consumers appear to want shorter lifetime certs and better automation. One way to improve automation is to make certs easier to get. Passive DCV makes certs a whole lot easier to get because an inter communication channel between certificate clients and live domain infrastructure can be eliminated.

I guess overall I am somewhat aligned with Aaron's points that the security model is probably pretty solid, but CA-assisted DCV is a very circuitous way of realizing it. CAs checking for static crypto credentials in domain records per a well-defined CA/B Forum spec is probably better.

[Tobias S. Josefowitz]

Hi Henry,

On Wed, 4 Dec 2024, Henry Birge-Lee wrote:

> Hi Tobi,
>
> Great points. I see your opinion that CNAME is not the problem, but a CA
> choosing to partake in a practice where it CNAMEs to itself is
> questionable.

First and foremost under the BRs as currently written. As I tried to
highlight, even if we assume that this practice has no negative security
implications whatsoever, this level of "creativity" in working with or
around the rules is inherently not something that could be assumed to be
beneficial for the ecosystem, the trust placed in it by Relying Parties
and the public in general, I think the only valid approach is to expect
CAs to not "subvert" the expectations placed on them based on
technicalities.

> With that said, I think the question arises that there is nothing today
> stopping a third-party from offering such a service (e.g., delegated DCV
> challenges so that domains only need to configure a static pointer to the
> new DCV challenge manager). In fact, a popular DNS service ACME DNS
> (https://github.com/joohoi/acme-dns) offered exactly this. For a long time
> they had a hosted service at acme-dns.io where users could make an account,
> point to with a CNAME under _acme-challenge.your-domain.example.com and
> then easily use a REST API to make TXT records. They also published an ACME
> DNS client plugin for certbot: https://github.com/acme-dns/acme-dns-client

Third parties today can do all kinds of things we would not accept from a
CA. If you were to, for whatever reason, use my services to get
certificates, and made it possible for me to finish the DV process for the
applied for certificates successfully, the BRs do virtually nothing to
stop me from any behaviour that would be problematic for you or for the
respective Relying Parties involved. The mere possibility for third
parties to engage in behavior we would not like to see CAs engage in thus
clearly does not come with any direct indication that CAs should
necessarily be allowed in all kinds of behavior that third parties could
engage in today.

Your arguments actually indicate to me that you have picked up on the fact
that I have, in this discussion at least, never given any reason for why
CAs should not be allowed to participate in DV on both sides that relates
to the security properties of the procedure itself. This is intentional on
my part, I am intentionally not saying that CAs cannot be allowed to offer
such services per se.

However, I believe there are considerations that have been left unexplored
in the course of SC-082. Clint has for example raised the point that it
would be beneficial to create an explicit validation method to allow this,
instead of fiddling with 3.2.2.4.7, as that would allow better insights
into challenges and incidents related to this practice, if any should
occur. It would also possibly allow us to add possible safeguards against
"accidental delegation"; many use cases today involve the setup of CNAME
records pointing to zones controlled by third parties, from mail hosting
to cloud services. It would also possibly allow to streamline the method
to its bare essentials that are crucial for deriving the security
properties we desire, as opposed to mandating the full 3.2.2.4.7 "dance"
even including possibly irrelevant parts.

This is not to say that, when discussing this other than as "it's kinda
already allowed today but let's make it clear" (a statement I vehemently
disagree with), the discussion might not establish reasons for why we
would not want CAs to engage in this, at all, even though third parties
can. This could for example happen if we found fundamentally undesirable
properties of such a mechanism, and considered that allowing CAs to engage
in them might make this mechanism more widely used in comparison to just
third parties engaging in it. I am not aware of any such issue at the
moment, I just would not rule it out until the proper discussion has been
had.

> Reading these CA/B Forum discussions, I also got really interested in
> seeing what was possible beyond the DNS ecosystem and also, what is the
> minimum action that can be taken by a party requesting a cert. I came up
> with an experimental project for a fully-passive and stateless domain
> control validation system:
> https://github.com/birgelee/passive-dcv
>
> Essentially, after creating a "magic" 301 redirect for the .well-known
> directory of a domain's webserver, you simply ask the system for a cert
> with a secret key that corresponds to the redirect you put in place. You
> don't have to even register (the system contains no state regarding its
> clients and you can get a cert in a single HTTP POST request).
>
> Given this system is fully functional (and I have a Let's Encrypt
> staging-environment version hosted at pdcv.henrybirgelee.com), it makes me
> ask the question:
>
> Is this somehow more secure than a CA just checking for the presence of a
> particular static redirect or static CNAME value (obviously given proper
> CA/B Forum regulations regarding such behavior)?
> Is a 3rd party unaffiliated with CAs running such services considered more
> secure than CAs running these services themselves?
> Where is the line drawn, if a CA reseller offers such a service as well as
> the sale of certificates from an affiliated tested CA, is that a problem? I
> could easily see services coming along to offer dcv-free certificates based
> on static delegations through CNAME, NS, HTTP redirects or just putting in
> the 3rd-party's email.

At first glance, that sounds like a promising method to me.

As for your question regarding where the delineation is, it is crucial to
keep in mind that the current delineation regarding CNAME delegation is
informed by technicalities of the current requirements in combination with
a "default deny" interpretation. As such, the delineation cannot be
expected to align very well with actual security properties, none the less
it is valid. A CA "subverting" a "default deny" interpretation in
conjunction with other entities in that sense is not something that I do
not find problematic, but at the same time I would not just say that it is
against the BRs.

To reiterate, this is definitely a topic that can be discussed, and that
discussion could definitely result in security improvements for the
ecosystem. We just haven't had it yet, or according to Tim, we've
apparently had it so long ago that at least I have forgotten the specific
determinations that the discussion brought out. In the course of SC-082,
we did clearly not have it.

Tobi

[Henry Birge-Lee]

Hi Tobi,

Thanks for those clarifications.

To put my stance a bit more concretely, having done some work studying domain control validation and studying attacks that subvert certificate issuance, I feel there is a secure way to make some forms of DCV rely on static configurations instead of online challenge/response protocols. If done correctly, I think such a method would add significant benefit to automation/deployment while having comparable or even superior security to existing DCV methods. I also agree with several people who have spoken previously that this is probably best implemented as a new method with its own independent security justification and not just tacking on to a method that was previously developed as a challenge and response protocol. If the forum would consider it, I would be interested in participating in exploratory conversations on this topic.

Best,

Henry

[Aaron Gable]

I think that the general discussion of whether third-parties should be allowed to offer similar services is ultimately a red herring. And I have no fundamental issue with a CA acting like one such third party, providing a DNS service to which validation can be delegated. The key distinction between a CA offering such a service and a third-party offering a similar service is not who offers the service: the key distinction is how the Random Value gets into the service.

When a third party -- such as "acme-dns" -- operates a DNS service to which the Applicant delegates the DCV process, that delegation involves the Applicant providing the token to the third-party every time they attempt validation. The token travels from the CA, to the Applicant, to the third-party: the Applicant is actively participating in the process, demonstrating that they still desire for this delegation to be in place at the time validation occurs.

When a CA operates a DNS service to which the Applicant delegates the DCV process, the token is potentially never even provided to the Applicant at all. It travels from the CA directly into the CA's DNS service, thus demonstrating nothing about the Applicant's desires at the time validation occurs -- it only demonstrates that the Applicant wished to delegate DCV at some time in the past.

Again, I think this is a perfectly reasonable security model, and I actually think it could be a good thing to enshrine such a DNS-based, set-and-forget (or "durable") DCV method in the BRs. But I don't think it belongs in Method 7 "DNS Change" because nothing in the DNS is changing.

Returning to my original point: it seems clear to me that the BRs today do allow CNAME delegation to the CA. It's clear that there are ways to implement such delegation poorly, and that it would make sense for CAs to be forbidden from making those mistakes. It's also clear that this ballot as-is did not pass, and something should change to make it palatable. So my concrete proposal would be to introduce a new ballot which describes a new "durable DNS" validation method, and to update Method 7 "DNS Change" to say that CAs SHOULD implement the new method instead of doing whatever they're doing today.

Aaron

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/044620c3-6cdd-49db-a728-23fd84da5cb4n%40groups.cabforum.org.

[Dimitris Zacharopoulos (HARICA)]

On 12/5/2024 11:11 PM, 'Aaron Gable' via Server Certificate WG (CA/B Forum) wrote:

When a third party -- such as "acme-dns" -- operates a DNS service to which the Applicant delegates the DCV process, that delegation involves the Applicant providing the token to the third-party every time they attempt validation. The token travels from the CA, to the Applicant, to the third-party: the Applicant is actively participating in the process, demonstrating that they still desire for this delegation to be in place at the time validation occurs.

When a CA operates a DNS service to which the Applicant delegates the DCV process, the token is potentially never even provided to the Applicant at all. It travels from the CA directly into the CA's DNS service, thus demonstrating nothing about the Applicant's desires at the time validation occurs -- it only demonstrates that the Applicant wished to delegate DCV at some time in the past.

If the third-party also manages or controls the DNS server (or the corresponding zone) on behalf of the Applicant, then we're probably in the same situation, meaning that the Applicant delegated this function to the third-party at some time in the past.

In my understanding, the fact that the CNAME record exists at time of validation, is an expression of "authorization" by the Applicant to the delegated entity to complete the Domain Validation process on behalf of the Applicant.

Aaron, do you agree? Did you have another model in mind with the first example?


Thanks,
Dimitris.

[Aaron Gable]

I believe there are two different common situations:

1) The Applicant is the domain owner. They use a third-party DNS service (e.g. acme-dns) to ease their validation. They use a CNAME to delegate the underscore-prefixed subdomain, apply for a certificate, receive a token, provide the token to their delegate, complete validation, and receive a certificate.

2) The Applicant is a third-party service, to whom the domain owner has delegated certificate management, including using a CNAME to point the underscore-prefixed subdomain at the third-party service. The third party applies for a certificate, receives a token, installs the token, completes validation, and receives a certificate.

Obviously these are somewhat broad strokes, and there's variation within each of these. But the key is that in both of these cases, the Applicant (the domain owner in the first case; the delegate in the second case) receives the Random Token themselves, and then does something (providing it to the third-party in the first case; using it directly in the second case) with it. I think there are few if any cases today where the domain owner is the Applicant, and yet only their third-party delegate ever sees the Random Token -- how is the CA providing the token directly to that delegate when the contact info they have is for the Applicant? Am I misinformed and this is actually common?

In the CA-Assisted DNS case, neither the domain owner nor the Applicant ever receives the random token. The CA provides the token directly to the delegate (themselves) with no action taken on the part of the Applicant. I believe that is meaningfully different, and therefore worth recognizing as a separate validation method.

Aaron

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/82d59d63-0a50-4d60-8f41-9a75f4272478%40harica.gr.

[Tobias S. Josefowitz]

Hi Aaron,

On Thu, 5 Dec 2024, Aaron Gable wrote:

> Returning to my original point: it seems clear to me that the BRs today
> do allow CNAME delegation to the CA.

While I am very much in agreement with pretty much every other part of
your mail, I feel the need to comment on this point.

I myself believe that method 7 was never intended to be used in a way
where a CNAME delegated the ability to participate in the DV process as
the applicant to the CA. Technically of course, there is a priori nothing
that would single out CAs in this regard in any way, certainly not when it
comes to DNS itself. So based on the language of method 7 itself, in
isolation, I can follow the argument that this would be allowed for CAs.
Which to me means that there is objectively room for discussion around
this point, certainly.

I do not mean to imply that you made the point that it is allowed today
was made outside of this exact discussion, but I see the possibility for
it to be interpreted on its own, in ways that I consider unfortunate.
After Certificate Consumers, also in this discussion, have voiced concerns
and perspectives that are in opposition to this idea, and after Ballot
SC-082 clearly established, as one might interpret from the votes of
absensce thereof from Certificate Consumers, that Certificate Consumers
are not necessarily part of such concensus, for a CA to actually move
forward and use method 7 in this way would probably be a harmful outcome
for the ecosystem, if not necessarily because of the security properties
of this particular use of method 7, then simply becaue of making use of
what could certainly be seen as a loophole by some participants, when such
concerns are known, and under debate. Even if the discussion would
ultimately determine this not to be a loophole but allowed, acting on it
before such a conclusion is reached would be fraught with problems. I even
believe all of this would still be true if such a use of method 7 would
ultimately not be considered to be in violation if such a case had to be
authoritatively decided.

Tobi

[Henry Birge-Lee]

Hi all,

One positive I have noticed during this discussion is that from the original result of the tiger team work linked in the ballot to the perspective of some certificate consumers, there seems to be many that feel, if done properly, approaches to domain validation that rely on static CNAME records (or potentially certain types of static content in general) can have comparable security to existing DCV methods. I think the security reasoning behind this (assuming appropriate guidelines are put in place) is quite sound.

I also think Aaron's point about framing is particularly relevant. Modifying 3.2.2.4.7 may create optics of somehow "gaming" a method that was originally designed as a challenge/response system, and makes the approach look somewhat unfavorable. However, I think there are actually several aspects of static identifiers for domain control validation that largely align with certificate consumers' stated objectives of improved security, improved automation, and validation methods that rely on modern protocols/cryptography. In fact, I even feel there are some superior security properties of a hypothetical validation method using such static identifiers over several existing methods. As an interested party and domain owner, I think having people come together and clearly define a new permissible method(s) along these lines would be a great improvement to the PKI.

Best,

Henry

--
You received this message because you are subscribed to a topic in the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.cabforum.org/d/topic/servercert-wg/ctYFczlzT5Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/0f4e0640-6012-96bd-2631-ec9090b9f821%40opera.com.

[Michael Slaughter]

Hi all,

Thanks again for the valuable feedback, suggestions, and conversation. 

In preparation for the upcoming discussion on this topic at the next Validation SC meeting, I captured and summarized the feedback from this and other threads into the following Google Doc: https://docs.google.com/document/d/1Q1JgRmf42sIdTTiNFw_mcRrntMX0Ns2qrD-BDIXBOm4/edit?usp=sharing . 

Thanks!

M. Slaughter

[Mike Shaver]

Hi Henry,

On Thu, Dec 5, 2024 at 11:01 PM Henry Birge-Lee <henryb...@gmail.com> wrote:

However, I think there are actually several aspects of static identifiers for domain control validation that largely align with certificate consumers' stated objectives of improved security, improved automation, and validation methods that rely on modern protocols/cryptography. In fact, I even feel there are some superior security properties of a hypothetical validation method using such static identifiers over several existing methods.

This is very interesting! Do you have any suggested reading that elaborates on these points? I'd love to understand them better.

Thanks,

Mike

[Aaron Gable]

Attempting to put my thought's from today's discussion into a concrete proposal. Obviously what follows is a very rough draft, but I figure it helps to get a strawman down on paper at the very least.

Add the following text to Method 7 DNS Change:

"If the CA or an Affiliate of the CA operates a DNS zone to which Applicants can delegate (via CNAME) their underscore-prefixed Domain Label, the CA MUST ensure that each Applicant delegates to a unique FQDN within that zone. A CA or Affiliate of a CA SHOULD NOT operate such a service, and SHOULD direct any Applicants using such a service to use Method 21 Static DNS instead."

Add a new method as Section 3.2.2.4.21 Static DNS:

"Confirming the Applicant's control over a FQDN by confirming the presence of a durable record identifying the Applicant in a DNS TXT record for an Authorization Domain Name.

The CA MUST confirm the presence of a record containing the following whitespace-delimited tokens:

- "ca=X", where X is an Issuer Domain Name disclosed by the CA in Section 4.2 of the CA's Certificate Policy and/or Certification Practices Statement;

- "accounturi=X", where X is a unique URI (as described by RFC 8657, Section 3) identifying the account of the Applicant which requested validation for this FQDN; and

- optionally "pubkey=X", where X is a base64-encoded DER public key (i.e. the body of a PEM "BEGIN PUBLIC KEY" block, with headers and whitespace removed) matching the public key provided by the Applicant in their certificate request.

For example, the record might look like (using the EC P256 test key from RFC 9500, Section 2.3):

    TXT ca=example.com accounturi=https://example.com/acct/123 pubkey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQiVI+I+3gv+17KN0RFLHKh5Vj71vc75eSOkyMsxFxbFsTNEMTLjVuKFxOelIgsiZJXKZNCX0FBmrfpCkKklCcg==

The CA MUST validate DNSSEC when querying for this record.

CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. TXT record) as the Primary Network Perspective.

Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names."

Aaron

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADQzZqvaxCQufKQE%2BodUc6L5Z7tJPOm_F%3Dc1SUDkD0uOL07wTg%40mail.gmail.com.

[Henry Birge-Lee]

Hi Mike,

I think there are several dimensions to this which should each be considered separately and have their own background material:

1. Improved automation: The classical model for an automated certificate client requires 3 external communication channels: 1) to communicate with the CA, 2) to upload domain control validation tokens and 3) to install the certificate at the server (this can be seen in figure 1 of our Usenix '21 paper) . With static DCV (name pending) one entire channel (the channel to complete domain control validation) can be eliminated making automation much simpler. The existing solutions for automation of this channel are actually fairly involved. If a domain is served from a single server that also terminates TLS connections, certbot or another ACME client can modify the domain's web server config or file structure to complete the challenge. Even this (optimal) cause introduces a less-than-optimal coupling between the ACME client and the webserver config (e.g., if the root directory of the website is changed, using the --web-root plugin on certbot could cause an error). As you consider more complex domain backend infrastructure, the systems of establishing this DCV token channel become more complex. If we instead consider a domain that is run behind a TLS-terminating reverse proxy, there is no web root to modify since the TLS termination point != http-layer hosting service. Here the logical answer is to switch from http-01 validation to tls-alpn-01 validation. Our research with Let's Encrypt indicates that this is one of the least used and most likely to get wrong validation methods (this is under submission, but I we will have a preprint out shortly) and once again requires a tight coupling between the ACME client and the software that terminates TLS connections. However, both of these centralized domain hosting cases are arguably the most favorable conditions for automation. High-traffic/high-availability domains are hosted as distributed systems where multiple geo-distributed nodes terminate TLS and all need valid certificates. However, each node cannot ensure that DCV challenges will be routed to that particular node. Thus, in this case DNS validation becomes a tempting solution. However, this once again introduces a complex external dependency where DNS credentials must be distributed to the ACME client and the client needs to have code to support different DNS providers. Examples of this are in the cert-manager DNS-01 challenge where the APIs of many different popular providers need to be enumerated to allow broad compatibility support (https://cert-manager.io/docs/configuration/acme/dns01/). The ACME DNS library is another example of a library that solely exists to handle the task of ACME clients validating dns-01 challenges.

While automation solutions do exist, I think it is important to remember that as complexity increases, engineering time increases and deployment becomes disincentivized. It is worth comparing the engineering time of integrating one of these automated solutions compared to just having a sysadmin upload a certificate once a year. Removing the need to interact with DNS, TLS endpoints, or HTTP servers makes creating a certificate management cron/automated certificate client much simpler. Furthermore, with static DCV, a node can run a web service and renew certificates with no knowledge of the other nodes running the web service or even the DNS infrastructure that is pointing to it. That is not currently possible with active DCV.

2. Security: There are cases where static DCV is arguably more secure than existing DCV methods. A more rigorous security argument is presented in the slides attached to this email where I use proof by contradiction to show that static DCV using certain parameters is as secure as existing DCV methods. Essentially, if an adversary capable of completing static DCV existed, this adversary could also bypass existing DCV methods. The intuition behind this is that if an applicant can prove that they can upload an arbitrary CNAME to an underscore-prefixed subdomain of the requested domain (e.g., _acme-challenge.example.com or _dcv.example.com) even only once and the static record is still present at time of certificate request, this applicant could just have easily uploaded a CNAME to a domain they controlled where they could answer "online"/active DCV challenges there.

While the above reasoning shows a static DCV is as secure as an existing DCV method, you can further find cases where static DCV is more secure than existing methods. Consider validation method 3.2.2.4.13 "Email to DNS CAA Contact". Here, an email address is included in a CAA record which is retrieved by the CA. After retrieval, the CA sends an email to this address with a one-time random value. Let's compare this to a (hypothetical) method where an applicant has to one-time upload a static value to a CAA. Existing method 3.2.2.4.13 can be compromised two ways: 1. an attack on the email system (where an adversary intercepts an email being sent to a legitimate email address contained in a CAA record for a domain) or 2. an attack on the CAA record itself (where an adversary modifies the CAA record and puts in a malicious email address). Either of these compromises will lead to a misissueance under 3.2.2.4.13. However, the static value upload method only shares one of these two attack surfaces (the compromise of the CAA record itself). Thus, introduction of a static-value-based method is introducing a new validation method that is provably more secure than an existing method. A more formal approach is to consider two proofs by contradiction: proof 1: if there was an adversary that could complete the static one-time CAA change, could this adversary be used to bypass 3.2.2.4.13. This proof holds because if an adversary can put a random token in a CAA record, it could put an adversary-controlled email in that record that would allow it to pass 3.2.2.4.13. Thus, the static CAA change method has >= security than 3.2.2.4.13. However if we attempt proof 2: if there was an adversary capable of bypassing 3.2.2.4.13 could this adversary bypass the static CAA change? This is not the case because even if the adversary can somehow intercept email to the specified CAA email, this does not ensure the adversary can actually compromise the domain's CAA records. Thus 3.2.2.4.13 has < security than the static CAA change (i.e., there exist adversaries that could compromise 3.2.2.4.13 but not static CAA change but there exist no adversaries that can compromise static CAA change but not 3.2.2.4.13).

The technique using DNS TXT records Aaron shared from today's call has the same security reasoning but is based on 3.2.2.4.14 (i.e., the method Aaron proposed is arguably strictly more secure than 3.2.2.4.14 which it largely shares a threat space with).

Beyond just the methods being more secure, there are security benefits for domain operators given that some systems for issuing certificates require secrets like global DNS credentials (see https://cert-manager.io/docs/configuration/acme/dns01/cloudflare/ ) solely for the purpose of completing dns-01 challenges. Ideally these credentials would be scoped to only the validation-related subdomains for security, but I think however you look at it, taking all DNS provider credentials off of live, deployed, public-facing systems is preferable.

3. Use of modern protocols. The advantage of these static methods is that they rely heavily on DNS (or HTTP if a 302/301 redirect based method is ever considered). These are protocols integral to the web ecosystem that DCV will likely always have some linkage to. Several existing validation methods rely on Email, Phone, Fax or SMS (Fax and SMS were recently voted out via ballot SC-80v3 which had unanimous certificate consumer support). Introduction of these static methods may cause more domains to move away from email/phone based validation and reduce the reliance of the PKI on the PSTN, SS7, and email ecosystems which represent (substantial) additional attack vectors for the PKI.

The only potential downside I see of introducing static DCV is account compromise. If a domain chooses to use this method, compromise of a subscriber's account could lead to misissuance (the CA would perform DCV and notice the account-specific token was there and then issue). However, even today, validation reuse means compromising a subscriber's account would likely lead to misissuance. Furthermore, even for CAs that have very short validation reuse periods, an adversary could use CT to tell when a DCV challenge had recently been completed and then use the compromised account to request a certificate shortly afterwards. Thus, I feel there is little existing security against an account compromise adversary. Furthermore, use of static DCV could potentially be predicated on some types of account hardening (e.g., 2FA, limited scope API keys, accounts backed by crypto credentials, etc...).

Even though it may not be obvious at first, I believe the introduction of these new methods would align quite nicely with certificate consumer's objectives of improving security and automation.

Best,

Henry

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADQzZqvaxCQufKQE%2BodUc6L5Z7tJPOm_F%3Dc1SUDkD0uOL07wTg%40mail.gmail.com.

[Henry Birge-Lee]

Hi Aaron,

I like this proposal. There were a couple minor points I wanted to clarify:

1. You explicitly mention an RFC 8657, Section 3 account URI. This is fine for ACME clients but I personally do not see any reason this method should be exclusive to ACME. Digicert uses an account specifier format of "account=<ACCOUNT_NUMBER>" in CAA records, and I think a similar approach would work OK in this context (particularly since the ca= field already uniquely identifies the CA, so we do not run the risk of account number collisions). Would it make sense to change this language to "a value that uniquely identifies a subscriber account (e.g., an  RFC 8657, Section 3 account URI)" to permit non-ACME values?

2. You have an optional ability to specify a public key which I presume is the public key of a certificate request. The P256 you give as an example is pretty short, but an RSA 2048 key is a good amount longer and a post-quantum key could be quite long. Additionally, the way DNS works, when a resolver retrieves a TXT record set (even if it is just to retrieve an SPF value), the DNS infrastructure must return the entire TXT RRSET. If the RRSET contains multiple RSA 2048 or post quantium keys, this could easily degrade DNS performance causing TCP fallback for the query. There is also some recent research about DNS's (in)ability to deliver responses signed by very large key sizes in the context of DNSSEC. With this in mind, would it make sense to just replace this field with the SHA256 hash of a public key or at least allow for the option of specifying a key hash?

3. I personally think the most secure way to enable this is actually not to bind the authorization to an account but instead authorize a particular secret token/key pair that is provisioned within that account. Somewhat like an API key that has only the restricted privilege of requesting certificates for the domain(s) that contain the corresponding static authorization token. This has more elegant scoped security and (presuming tokens cannot be redownloaded) security even in the event of a subscriber account compromise. Even in the ACME case where an accounturi is bound to a private key, there is still a benefit of using some other token system. In part due to the Let's Encrypt rate limit exemption system, several organizations process millions of certificate requests from one ACME account. Binding domain authorization for millions of domains to this single account creates somewhat of a one-key-to-rule-them-all phenomena. I would personally prefer if there was the option to have a layer of indirection here where domain authorizations could be tied to a secret that was more fine-grained than an ACME account. Would it make sense to explicitly permit this use case by adding something like "authtoken=X" where X uniquely identifies a certificate requesting agent authorized to obtain a certificate for this domain.

Also, an auxiliary note on syntax, it may be helpful to start the record with a token identifying the purposes of the record and not just go directly into ca= . Something like "static-dcv ca=...." Aslo, SPF1 records use ":" between keys and values, CAA records use ";" between different properties. This seems to be a bit in the middle (equals signs between keys and values but spaces between different properties). Finally, for the eventual standard an ABNF syntax definition may be helpful as this would allow the generation of auto parsers and validators.

Thanks again Aaron and all for the proposal. I think this is a great direction to go in.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcAfF-bbhy6FcYjDPEq69%2BVQAoERdn%3D5uyCVtu%2BtfTHpw%40mail.gmail.com.

[Aaron Gable]

On Fri, Dec 13, 2024 at 3:19 PM Henry Birge-Lee <henryb...@gmail.com> wrote:

Hi Aaron,

I like this proposal. There were a couple minor points I wanted to clarify:

1. You explicitly mention an RFC 8657, Section 3 account URI. This is fine for ACME clients but I personally do not see any reason this method should be exclusive to ACME. Digicert uses an account specifier format of "account=<ACCOUNT_NUMBER>" in CAA records, and I think a similar approach would work OK in this context (particularly since the ca= field already uniquely identifies the CA, so we do not run the risk of account number collisions). Would it make sense to change this language to "a value that uniquely identifies a subscriber account (e.g., an  RFC 8657, Section 3 account URI)" to permit non-ACME values?

Yes, for the first draft I wanted to stick with something for which there was obvious prior art, but I'm certainly open to other ways to tie the record to the Applicant's account. Another possibility (for ACME) would be a hash of the account's JWK pubkey.

 

2. You have an optional ability to specify a public key which I presume is the public key of a certificate request. The P256 you give as an example is pretty short, but an RSA 2048 key is a good amount longer and a post-quantum key could be quite long. Additionally, the way DNS works, when a resolver retrieves a TXT record set (even if it is just to retrieve an SPF value), the DNS infrastructure must return the entire TXT RRSET. If the RRSET contains multiple RSA 2048 or post quantium keys, this could easily degrade DNS performance causing TCP fallback for the query. There is also some recent research about DNS's (in)ability to deliver responses signed by very large key sizes in the context of DNSSEC. With this in mind, would it make sense to just replace this field with the SHA256 hash of a public key or at least allow for the option of specifying a key hash?

Yes, I'm certainly open to allowing the record to contain a key hash, much as DANE uses the "matching type" field to indicate how the content is hashed. However, also much like DANE, that would require some way to indicate the hashing algorithm used, and I wasn't interested in tackling that level of complexity in the first draft.

 

3. I personally think the most secure way to enable this is actually not to bind the authorization to an account but instead authorize a particular secret token/key pair that is provisioned within that account. Somewhat like an API key that has only the restricted privilege of requesting certificates for the domain(s) that contain the corresponding static authorization token. This has more elegant scoped security and (presuming tokens cannot be redownloaded) security even in the event of a subscriber account compromise. Even in the ACME case where an accounturi is bound to a private key, there is still a benefit of using some other token system. In part due to the Let's Encrypt rate limit exemption system, several organizations process millions of certificate requests from one ACME account. Binding domain authorization for millions of domains to this single account creates somewhat of a one-key-to-rule-them-all phenomena. I would personally prefer if there was the option to have a layer of indirection here where domain authorizations could be tied to a secret that was more fine-grained than an ACME account. Would it make sense to explicitly permit this use case by adding something like "authtoken=X" where X uniquely identifies a certificate requesting agent authorized to obtain a certificate for this domain.

Interesting! I think a CA could accomplish the same goal just with the "account=" field. There's no reason that a CA couldn't establish a mechanism where multiple account values all map to the same logical account (as long as no single value can map to multiple accounts). That would allow a CA to establish whatever mechanism it wants for negotiating those values with its Applicants/Subscribers, including scoping those tokens to only be valid for specific account+hostname pairs, or any other scoping mechanism it desires.

So I don't think there's much reason to have "account=" and "authtoken=" side-by-side in the spec. But perhaps that's an argument for wholly replacing/renaming "account=" to "authtoken=". This would have the upside of encouraging such CA behavior, and the downside of being less intuitive to the humans who are creating these long-lived records. I'm currently neutral on the idea.

 

Also, an auxiliary note on syntax, it may be helpful to start the record with a token identifying the purposes of the record and not just go directly into ca= . Something like "static-dcv ca=...." Aslo, SPF1 records use ":" between keys and values, CAA records use ";" between different properties. This seems to be a bit in the middle (equals signs between keys and values but spaces between different properties). Finally, for the eventual standard an ABNF syntax definition may be helpful as this would allow the generation of auto parsers and validators.

Yes for sure, a whitespace-delimited set of key=value pairs is a lazy syntax (though textual separators come with their own issues!), I just didn't take the time to survey the current state-of-the-art. The important bit for the first draft was the content.

 

Thanks again Aaron and all for the proposal. I think this is a great direction to go in.

Best,

Henry

Thank you for the feedback!

Aaron

[Dimitris Zacharopoulos (HARICA)]

Hi Michael,

Assuming you want to continue driving this effort, would it make sense to start a new thread under a new ballot number?


Thanks,
Dimitris Zacharopoulos
SCWG Chair

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErfVccRdnD_WC_vGaLhAX%3Dkt2k4ji33ci_n17vR0EXTd8Q%40mail.gmail.com.