[cabf_validation] Draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - November 18, 2021

[Dimitris Zacharopoulos (HARICA)]

These are the Draft Minutes of the Teleconference described in the 
subject of this message as prepared by Dimitris Zacharopoulos (HARICA).*
*

Please review the minutes and propose edits if necessary. These minutes 
will be considered for approval at the next meeting. The recording of 
the meeting will be deleted once the minutes are approved.


    Attendees(in alphabetical order)

Amanda Mendieta (Apple), Ben Wilson (Mozilla), Bruce Morton (Entrust), 
Clint Wilson (Apple), Corey Bonnell (Digicert), Dimitris Zacharopoulos 
(HARICA), Enrico Entschew (D-TRUST), Inigo Barreira (Sectigo), Joanna 
Fox (TrustCor Systems), Johnny Reading (GoDaddy), Kati Davids (GoDaddy), 
Michael Slaughter (Amazon), Michelle Coon (OATI), Niko Carpenter 
(SecureTrust), Paul van Brouwershaven (Entrust), Rebecca Kelley (Apple), 
Ryan Dickson (Google), Steven Deitte (GoDaddy), Thomas Zermeno 
(SSL.com), Tim Hollebeek (Digicert), Tyler Myers (GoDaddy), Wayne Thayer 
(Mozilla).


    Agenda

 1. CRL validity period ballot (SC52)
 2. Certificate Profiles and effective dates
 3. Delegate DNS to the CA for Domain Validation


    Minutes


      Preparation

  * The recording started
  * Roll call was taken by Tim
  * The antitrust statement was read by Tim
  * Minute taker was assigned (Dimitris)


      1. SC-52: Specify CRL Validity Intervals in Seconds

Tim asked for Members to check the ballot and whether the changes will 
negatively affect other areas like Request Tokens, Audit periods, etc.


      2. Certificate Profiles and effective dates

  * A ballot becomes effective when it clears IPR
  * Possible explicit effective dates in the actual ballot

Tim said it would be very challenging to write a version of the BRs that 
contains the old profiles, the new profiles and effective dates for those.

The problem is simple. After the transition date, we want CAs to use the 
new profiles. Before that effective date, CAs would be OK to use the old 
profiles.

All certificates issues after the transition date, must comply with the 
new certificate profiles. Until that transition date, the CA MAY use the 
profiles described in the previous BR version.

The cleanup for this would just remove the transition date when it is no 
longer necessary.

Bruce agreed that this is a nice approach. He asked what would happen if 
a subsequent ballot changed the language in the profiles sections. Tim 
said we could agree not to modify the profiles section until the 
transition date of the Profiles ballot. In case we find an issue in the 
profiles, there will still be a linked version to a BRs version and 
follow-up ballots will be able to modify this language in whatever ways 
necessary in order to express the changes required.

Clint agrees with the approach.

If we discover that we have made a mistake in the language, we will have 
time to run a subsequent ballot to fix issues before the problematic 
language becomes effective.

Wayne says that CAs could pick-and-choose which corrupts the 
interpretation of the new changes. CAs should either comply entirely 
with the old or entirely with the new profiles. That might eliminate 
some of the risk of pick-and-choose. The implementation time period is 
relatively short so it's not a huge risk and would only apply for 6 months.

Tim had the impression that the current language already forbids the 
pick-and-choose option and would welcome suggestions for improvements to 
making this clearer.

In any case, Tim considers that everything in the new profiles is not 
considering anything done in the previous profiles as "illegal". Wayne 
said that we need to confirm that something in the new profiles is not 
prohibited by the old profiles. Tim replied that he doesn't think this 
is the case and Wayne suggested we add a sentence to state that clearly 
for readers as for the intent.

Wayne said that if the Profiles ballot extends to parts of the BRs 
outside section 7, for example definitions and such, modulo other 
ballots that happen in the interim period, we could say that the CA 
either must comply with this version or that version, but not 
pick-and-choose. However, he agreed that this is difficult to achieve 
when there are subsequent ballots.

Dimitris said that the BRs say that CAs must always comply with the 
latest version. Tim said that if auditors asked, we would point to 
explicit text of the latest BRs that says you may comply with a previous 
version.


      3. Delegating DNS to the CA for Domain Validation

Wayne described the issue of method 7 DNS domain control authorization. 
Method 7 allows the use of CNAME records to redirect from one domain to 
another where at some point you check a TXT record that contains the 
Random Value and complete the Domain Validation process.

The CA can register a Domain Name "cadomainvalidations.com". Then create 
subdomains off of that Domain Name and ask Applicants to create CNAME 
records that point to those subdomains. This would allow the CA to 
essentially self-authorize and self-issue renewed certificates.

The topic was discussed in m.d.s.p. back in 2019 where Jeremy Rowley 
from Digicert and Ryan Sleevi from Google had a disagreement about 
whether this practice is allowed in the BRs or not.

Some CAs might be using this practice today. It's best if we are 
explicit about it and either explicitly allow or forbid this practice.

What are the associated risks?

If a CA were to use this method, without having any binding between the 
organization that was instructed to create a CNAME that points to a 
subdomain controlled by the CA, if there was no binding between that and 
the actual request coming in for the certificate, then anyone could 
request a certificate once it was CNAMEd, once the CNAME was set by the 
rightful Domain Name holder. The CA cannot distinguish whether the 
request comes from the Domain Name holder or not. You have to bind this 
delegation with a particular account at the CA systems so to accept only 
requests that are authorized and linked to this delegated account.

Add language to method 7 that says that the Random Value must be bound 
to the Applicant's account. So, you might have a Random Value but also 
have an account authorization.

Would this be a new method? Wayne suggests that this is a yes, it should 
be an entirely new method that describes what is and what is not allowed.

If the Applicant delegates via CNAME the Domain Authorization to a 
Domain that the CA controls, then the CA binds that delegation with an 
account in its systems, and then the risk is prevented. Then, when the 
CA wants to issue a certificate, it is practically self-validating. 
Then, why should the CA generate the Random Value in the first place? 
It's just an exercise that doesn't add any security value or prove 
anything. Just the fact of creating a CNAME pointing to a subdomain of 
the CA, should be considered authorization, and a "permanent" one.

This authorization starts to look like how the CAA works. Just like a 
Domain Name holder points the CAA to a domain name, it could point to a 
CNAME as a permanent authorization, or a CA "account identifier". The CA 
would then be able to issue certificates in perpetuity as long as this 
record is in place.

So, the idea is to codify that as a validation method that uses CAA or 
CNAME to delegate this issuance authorization to the CA under a 
particular "account identifier".

Dimitris asked if we should first discuss if this practice is 
problematic and introduces significant risks and whether it is specific 
to delegations to CA or delegations in general. In many ways today, it 
is very difficult, almost impossible for a CA to distinguish between an 
Applicant and a Reseller.

Is the delegation problem problematic in general?

Who is the Applicant (especially on a hosting provider)? Need to check 
if this is currently allowed in method 7.

Wayne recalled that in the 2019 email thread, there was discussion about 
whether Amazon Web Services is the Applicant for certificates asked by 
their customers or not.

Tim: There are ways to implement this, it is allowed, but you can do it 
in a very bad way. We need to update the BRs so that if someone is going 
to allow it, here's how it should be done, in a secure manner.

Dimitris said that method 7 clearly allows delegating Domain Names to 
hosting providers. Perhaps there is an issue for hosting providers that 
are also CAs that perform the validation. Is the problem identified in 
the fact that CAs could do it directly, so instead of having two 
parties, an "Applicant" and a "CA", we have the CA wearing two hats? Tim 
replied that it's unclear. It depends how you read some of those words 
in the BRs.

Wayne recalled that the original question came from a CA that asked "am 
I allowed to do this"? That spawned the discussion but it was not 
clearly resolved. The cases we should consider are Amazon, GoDaddy, 
Google and Microsoft who are also hosting providers and CAs. Are they 
allowed to do this? Can the CA do it directly? If not, can the CA /that 
is also a hosting provider/ do it?

Bruce recommended that we just assume that it is currently permitted and 
proceed with making it clear whether it is permitted or not going 
forward. CAs have been audited, nobody said it's not permitted, we can't 
change the past.

Wayne added that this is a typical situation where we should debate what 
are the CAs' and Browsers' expectations and in the end it doesn't really 
matter that much, it just needs to be clear so there is a common 
understanding going forward.

Binding a Random Value to a specific customer could be a trivial change. 
However, it doesn't really answer the question about whether this is 
allowed or not.

In general, adding random values to a domain that the CA controls, is 
just "theater".

Permanent delegations are risky. Tim said that CAs still need to check 
delegation every time. Currently it's probably not required because of 
the validation reuse clause.

Tim recommends that instead of allowing that in method 7, we should 
create a new method that allows it with better security properties.

Tim said that for the random value to work, the CA would need to check 
that the CNAME is in place so this is covered. However, Dimitris pointed 
out that this validation action can be reused for 398 days, except for 
the CAA that needs to take place on every certificate issuance. So, 
requiring the CNAME delegation check on every issuance, would be an 
improvement over the current requirements. Tim thought that this would 
then make this method special in a way he doesn't feel is necessary.

Wayne asked if we could add a sentence in method 7 that says "if a CNAME 
is used to redirect the Domain Control to the CA then something must be 
tied to the account".

Tim will write a straw-man proposal for further discussion.

Corey mentioned that this could easily be the case in method 2 where the 
Applicant adds a CA email address in the WHOIS record. Niko said it 
could also apply to method 18 with a permanent redirect that always 
redirects to the CA-controlled Domain Name.

It goes back to the original question whether delegating Domain Control 
validation to the CA is an acceptable practice or not. An arbitrary 
third-party is OK to be delegated for Domain Control validation. Why not 
for the CA?

Tim recommended to leave the other methods until we find good language 
for method 7. He also thinks that this delegation would be good for 
agility purposes.

Tim mentioned that the Random Value is like a "bearer token" between the 
Applicant and the CA. If the CA gets authorization by an action from the 
Applicant at the Authorization Domain Name level, then the "bearer 
token" becomes irrelevant.

Niko replied that, without stating whether this is for better or worse, 
the Random value shows intent at the time of setting that DNS record, 
while the CNAME record doesn't have that property.

Wayne said that he agrees with Corey that this delegation issue probably 
applies to several Domain Validation methods but it might make more 
sense to start with improving the DNS method first.

Wayne asked whether we should ban it for the other methods until we look 
at the issue thoroughly. Tim suggested not to touch the other methods 
until we do some analysis.

Bruce mentioned that we could ban it and wait for a CA that uses it to 
come forward. Tim was negative with that approach and asked how does one 
know whether an email address is or is not controlled by the CA?

Dimitris: This is probably the case for the WHOIS email addresses but 
not the constructed email address method. But, similarly, how can we 
differentiate whether a Domain Name is controlled by a CA or not? It 
could very well point to a Domain Name that is not the one the CA is 
using for their brand name. It's not possible to track this down.

Bruce made an observation that we tried very hard to remove "any other 
method" and it appears that we currently do have "any other method" 
being effectively allowed. Perhaps we didn't define things specifically 
enough? Tim replied that we always knew this would be an iterative 
process where methods and language would be continuously improved. We 
have made very good progress in the Domain Validation methods, things 
are much better than what they used to be. All agreed.


      Adjourned
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211125/dac06437/attachment-0001.html>