[cabf_validation] Draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - November 18, 2021
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Nov 25 17:38:38 UTC 2021
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
1. CRL validity period ballot (SC52)
2. Certificate Profiles and effective dates
3. Delegate DNS to the CA for Domain Validation
* 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
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
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
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation