[cabf_validation] 2023-11-30 Approved Minutes
Chris Clements
cclements at google.com
Mon Dec 18 20:21:58 UTC 2023
These are the Approved Minutes of the Teleconference described in the
subject of this message, prepared by Chris Clements.
Meeting Date: 2023-11-30
Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Andrea
Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson
(Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Chris Clements
(Google), Christophe Bonjean (GlobalSign), Clint Wilson (Apple), Corey
Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos
(HARICA), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Eva
Vansteenberge (GlobalSign), Inigo Barreira (Sectigo), Janet Hines
(VikingCloud), Johnny Reading (GoDaddy), Joseph Ramm (OATI), Mads
Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter
(Amazon), Miguel Sanchez (Google), Nargis Mannan (VikingCloud), Nate Smith
(GoDaddy), Pekka Lahtiharju (Telia Company), Robert Lee (GlobalSign),
Rollin Yu (TrustAsia Technologies Inc), Roman Fischer (SwissSign), Scott
Rea (eMudhra), Thomas Zermeno (SSL.com), Tim Hollebeek (DigiCert), Tobias
Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer
(Fastly)
Discussion:
-
Corey Bonnell greeted participants, confirmed the recording was started,
read the attendance (above), and read the “note well.”
-
Approving previous meeting minutes:
-
Updated draft minutes were re-circulated on Tuesday. These will be
approved on the next call to allow for more time to review.
-
Corey summarized the meeting’s planned agenda:
-
Status update from Chris on MPDV/MPIC ballot work
-
Walkthrough of proposed ballot language for improvements to 3.2.2.4
(7)
-
Proposed update regarding due diligence and cross correlation in the
context of automation
-
Corey added an administrative note saying he created a github issue
to track the EV language improvements
-
MPDV/MPIC Ballot Work:
-
Chris Clements stated he intends to pick up where Ryan Dickson left
off before his parental leave.
-
The most recent activity from a ballot proposer perspective has been
Google Counsel and Princeton Counsel reviewing/iterating on the Princeton
IP release, which intends to address any IP related concerns with a
worldwide, perpetual, royalty-free license grant. Coordination
amongst the
various parties, combined with the holiday, slowed progress, but he is
hoping for positive movement in the next week or so.
-
Ryan’s PR is currently still open and Chris wants to get it closed
and forked to his own repo. There have been a few more comments
in the PR,
and most recently the one from Aaron Gable regarding now being a
convenient
time to move CAA-relevant language out of Section 2.2 and into 3.2.2.8,
which makes sense. He wants to work that and others into the next PR.
-
Once the IP release is settled amongst the Counsel’s, he will fork
Ryan’s work and use a new PR for discussion.
-
Tim Hollebeek asked a question of how careful are they being with the
drafted language aligning with the existing IPR agreement which
others are
familiar with. Chris stated he cannot answer exactly how close
the language
matches, but that consideration has been given to alignment with the
existing language and there is a desire to align as closely as possible.
-
Proposed ballot language for improvements to 3.2.2.4 (7):
-
Michael Slaughter provided background on the proposed ballot starting
with context from F2F 59. The outcome of that discussion was to
formulate a
tiger team to analyze the practice and develop a threat model, which was
then presented at F2F 60. The plan after F2F 60 was to go down two tracks
(1) was to add additional clarifying language to the existing section
3.2.2.4.7 and (2) was to start working on a new validation
method centered
around the practice of delegation and automation.
-
Today’s discussion is about changes to the existing validation
method. The presentation is sharable.
-
Today’s goal is to seek feedback on the PR (
https://github.com/slghtr-says/servercert/pull/1/files) and the
modified language and step through each of the four clauses.
-
Clause #1: “[ADD] CAs MAY operate domains for the purpose of
assisting customers with this validation, and MAY instruct
customers to add
a CNAME redirect from an Authorization Domain Name to such a domain.”
-
Originally proposed by Tim Hollebeek a few years ago. This clause
is pulled directly from that proposed language. The goal of
this clause is
to specify that CAs are ALLOWED but NOT REQUIRED to operate a
DNS domain
that can be used as part of 3.2.2.4.7 DNS Change. It also
constrains the
usage of this practice to delegation meaning that the
Authorization Domain
Name (ADN) is intended to be used as the CNAME value of the
ADN used for
the rest of the validation method. The real goal is to
address the lack of
clarity that this is allowed.
-
Wayne Thayer asked if the term “CNAME redirect” is a common
industry term? Is there a way to more clearly state that you can put a
reference to the other domain in the CNAME? Slaughter is open
to better
phrasing. Tim agreed it would be better to use something more
concrete like
the CNAME RFC, where redirection is explicitly defined and
then point to
that reference so that nobody can misunderstand it.
-
Slaughter emphasized receiving comments is great, but if you have
proposed changes or suggestions on wording, that's even better.
-
Dimitris Zacharopoulos suggested removing the word “customers”
from the text because it's not used anywhere else and instead
replacing it
with “applicants”.
-
Clause #2: “[ADD] If the CA does so, the CA SHALL ensure that each
domain name is used for a unique Applicant, and not shared
across multiple
Applicants.”
-
This language addresses the primary threat identified in the
threat model, where a flawed or poor implementation of this
practice is
used, such as the same DNS name is used for multiple
applicants. This may
cause someone who is not authorized to have a certificate for a given
domain to be able to successfully validate one. This adds
guardrails to the
practice if a CA chooses to perform this practice.
-
Tobias Josefowitz asked why “SHALL” is used instead of “MUST”. Tim
suggested switching to a “MUST” since the term is used more
often in the
BRs. Slaughter agreed and confirmed that “MUST” is the
preferred verbiage.
-
Thomas Zermeno asked for clarification regarding which “domain
name” is being referenced here. Is this a fully qualified
domain name, base
domain name, subdomain name? Others agreed that this requires
clarification. Tim suggested that this is the target domain
name (i.e., the
one setup by the CA). Aaron Gable stated the difficulty is
that both the
domain name hosting the CNAME record and the domain name
pointed to by that
CNAME record are potentially ADNs according to the definition
in 1.6.1.,
where the FQDN actually used by the CA to check
authorization. There are
restrictions on what domain names you can use, but it can be
(1) the FQDN
in the certificate, (2) a parent of that, or (3) something
pointed to by a
CNAME from there.
-
Aaron highlighted that the use of ADN in Clause #1 is not
necessarily correct because if the CA does follow a CNAME from the
Subscribers domain name to a CA operated domain name, then
the Subscribers
domain name is no longer technically an ADN and this clause
becomes oddly
messed up. We should define names for both the Subscribers
domain name and
the CA operated domain name and then use those consistently
through this
section.
-
Slaughter asked to clarify his understanding that the ADN is the
actual name being validated, meaning the identity in the
certificate and if
so, it's not clear how that could be confused with the domain
operated by
the CA, unless you're saying the CA is doing domain validation for
themself. Clint Wilson referred to the existing definition
for ADN stating
it can be the FQDN that is in the certificate or it can be
the FQDN that
the FQDN in the certificate resolves to, so if there is a
CNAME on that
FQDN then it could be that value. So the definition includes CNAME
redirect.
-
Tim provided an example scenario where we’re validating
www.example.com and we’re validating it via example.com, so you
think example.com is the ADN, but it turns out example.com is also
a CNAME over to clintwilson.com, so at some point your actually
doing domain validation against clintwilson.com to prove control of
example.com, which proves control of www.example.com. Slaughter
asked if in this example could you issue a certificate to
clintwilson.com? Yes, you will prove domain control for
clintwilson.com and then say hey I’ve also proven domain control
for example.com using example.com CNAME over the previous proof
and since www.example.com is a subdomain of an existing domain
that I’ve proven control over that one as well so you can issue a
certificate with all three in the SAN. Slaughter asked if
this is implicit.
Tim stated the model is written assuming we only validate one
domain name
at a time, but yes, because there is an ability to reuse sub steps of
evidence from sub steps from multiple validations that may
come together.
If you’re validating a.example.com and b.example.com via the
common parent example.com, you're technically doing three
validations, according to the BRs. But what everybody is
going to do is
they will do the example.com validation first and if successful
then repeat the validations for a.example.com and b.example.com
and we’re going to note that it reduces to a previously
solved problem.
Aaron stated this is the reuse of documents obtained during validation
concept, where if you do things in the right order, then you can reuse
these documents.
-
Slaughter asked in that last scenario, what is the ADN? example.com.
Tim highlighted that there are three validations being done.
The ADN for
all three authorizations is example.com, but when we go through
the validation of a.example.com thats where the reuse happens, but
we also switch the ADN where we’re doing a.exmaple.com but the CA
has chosen the ADN of example.com so that they can reuse the
previous validation. That’s why the ADN is different from the
name that was
actually requested because someone has gone up the chain a bit to make
their validation simple. Aaron used the first example
provided stating, if
example.com itself were a CNAME to clintwilson.com, then
clintwilson.com would be the ADN for all three of these. This is
why the use of ADN in this clause needs to be super careful
because it is
not necessarily the thing we expect.
-
Aaron suggested changing the statement to “MAY instruct customers
to add a CNAME from a customer controlled domain name to a CA operated
domain name” or something similar. Basically, invent two
terms here and use
them through the paragraph. Aaron suggested the important
part of the ADN
definition is “The FQDN used to obtain authorization for a
given FQDN to be
included in a Certificate. The CA may use the FQDN returned from a DNS
CNAME lookup as the FQDN for the purposes of domain
validation.” These two
sentences together say the ADN is whatever FQDN we actually
use, and one
FQDN you may use is something pointed to by a CNAME. Later in the
paragraph, you see another FQDN you may use is one derived by trimming
labels from the left. Aaron interprets this paragraph to say,
here are a
bunch of ways you can derive alternate potential FQDNs from
the FQDN that
is going to be included in the certificate and then whatever
derivation
process you use, that thing you arrive at, that is the ADN.
This paragraph
in this draft language is saying you are following a CNAME
redirect from
some FQDN to some other FQDN and then using the other one for
validation,
then the other one is the ADN, not the one we’re following
the CNAME from.
Dimitris disagreed, as he interprets the ADN to be the opposite. He
interprets the ADN is always part of the domain name that
will be included
in the certificate. Tim agreed with Aaron and suggested what
we’re really
trying to say is, the Applicant may use an ADN provided by
the CA. If true,
then we don’t need a new term because the new domain name
that the CA has
setup for the purpose of assisting customers with authorizing
certificates
is just a CA operated ADN that an Applicant may redirect
their domain names
to. Clint believes there is benefit from developing a
definition because
it's a bit nuanced and being able to clearly reference “this
is what an ADN
is in the rest of the BRs and this is a special case ADN” or similar.
-
Corey suggested looking at the language at the top of 3.2.2.4.7
where it says “Confirming the Applicant's control over the FQDN by
confirming the presence of a Random Value or Request Token
for either in a
DNS CNAME, TXT or CAA record for either 1) an Authorization
Domain Name; or
2) an Authorization Domain Name that is prefixed with a
Domain Label that
begins with an underscore character.” Can we take the
language from #2 and
add it to the ADN definition? Will that fix the issue? Tim
asked if that
means the CA operated domain names would always have to start with an
underscore character. Corey suggested it would not, since we’re saying
“from” an ADN in the proposed language so that it is clear
that the owning
domain is the ADN that is prefixed with a Domain Label that
begins with an
underscore character. Corey wonders if using this language
consistently in
both parts will tie the language together so that it's clear. Dimitris
thinks it would be helpful to define which domain name is
operated by the
CA and which one is operated by the Applicant.
-
Dimitris stated he was still trying to match the last sentence of
the ADN definition, which says that you can prune 0 or more
Domain Labels
until you reach the base domain name, and if the other
interpretation is
correct, and example.com is pointing to myca.com, and we start
pruning domain names in the myca.com, that doesn't make sense. Tim
suggested we need to be careful. Say we’re validating
www.example.com and that goes down to example.com that has a
prefixed redirect off to customer1.timca.com. One of the things
we’re going to have to make sure you cannot do is just validate
timca.com and say that means that validation is good enough for
every single one of the customer labels. We need to make sure
every one of
the customer labels are validated and not its parent. It's close to a
subset of an ADN, but it's great to have an additional
defined term because
there will be additional requirements such as you cannot
prune labels from
this special CA provided ADN. It has to be explicitly per
customer domain
that you validate. Aaron’s interpretation of ADN is that this
is already
the case, but everyone may not share that interpretation.
Aaron’s read of
the ADN definition as providing three separate options for
how a CA may
derive an ADN from the FQDN to be included in the certificate
and not that
the CA can mix and match these methods in any order. These
methods being
(1) you can follow a CNAME, (2) you must do pruning if it's a
wildcard, and
(3) you may prune labels from the left up until you arrive at
a base domain
name. Aaron does not believe this means you can prune a
label, then follow
a CNAME, then prune two more labels, then follow another
CNAME, then prune
one more label. That is not the intent. This should be
clarified in the ADN
definition. Slaughter agreed with the intent, but argues if
you do actually
do this, don't you effectively control the domain? If, for
example, you have
example.com that points to foo.myca.com and you control myca.com
then you also control foo.myca.com, which is the interpretation of
doing the “follow CNAME, prune, prune” type thing. Tim
agreed, effectively
if you're worried about who actually controls it then the
more expansive
definition is correct, any of those people could cause funny
business and
basically do control the domain. 10 years ago when these rules got
developed, this was the character of the discussion, where
it's okay to
prune stuff from the left because it's really the same domain
or you have
to follow CNAMEs because that’s what browsers do. It's really the same
domain. It's basically just based on what actually shows
control of the
domain. That's where we got the note that sits on a lot of
them on whether
they validate the entire subspace below them or just the
particular one.
-
Slaughter suggested there is more work to be done to clarify this
language and likes the recommendation by Aaron to capture the
intent in a
more explicit way that does not rely on a complicated
definition of ADN.
Aaron thinks there is one more issue with this first
sentence, where the
statement “instruct customers to add a CNAME redirect from an
Authorization
Domain Name to such a domain.” excludes option 2 in the first
paragraph of
the section where adding a CNAME from an ADN that is prefixed with the
Domain Label that begins with an underscore character is somehow not
acceptable here. Martijn suggested that option 1 makes a lot
of sense when
you use TXT records, which is also allowed. Corey doesn't believe that
anyone will be doing delegation to the CA with the actual
ADN, as it will
most likely be the underscore prefix. Tim agreed and
suggested we write it
that way, where we prohibit delegation of the ADN directly.
-
Dimitris called attention to the chat where you can have a prefix
label starting with an underscore and then point that with a
CNAME to the
CA in a unique way that is only used by that specific
applicant but the ADN
is example.com (i.e., _delegated.example.com ->
customerAB123456.myca.com <http://customerab123456.myca.com/>).
That's what Tim originally thought, but Aaron has since convinced him
otherwise. It's actually more reasonable to consider the
CNAME redirect to
be just yet another CNAME redirect and then the ADN (the
domain name being
validated by the appropriate 3.2.2.4 method for the proof of
control) is
actually the CA operated ADN, which is customer1.myca.com. This is
the actual ADN that goes through the validation procedure. Dimitris
suggested the ADN is the first input in the validation process. Aaron
disagreed and does not think that is what 1.6.1 says. It may
have been the
intent, but that is not what it says. The thing that we need
to be careful
of and where we may be encountering a bug in the BRs is that
the definition
of ADN basically provides a set of mechanisms you can use to
derive an ADN
from an input FQDN that will be provided in a certificate.
Great. However
the current language for DNS Change says that you can confirm
control by
looking at an ADN as derived by the definition above in 1.6.1
or an ADN
prefixed with a Domain Label that begins with an underscore.
The thing that
actually happens is people put CNAMEs in that thing prefixed by an
underscore character and follow those and the thing you
arrive at there, is
not an ADN. It does not meet any of the algorithms described
in 1.6.1 for
deriving an ADN because what you’ve done is added an
additional label and
then follow the CNAME from there, not pruned and followed
CNAMEs, which is
what the definition of ADN allows. So we’ve actually arrived
at a place
where DNS Change says follow the ADN definition to arrive at
some domain
name that you’re going to use for this DNS Change method and
then add an
underscore Domain Label and now we’re out of scope of ADN.
Anything we do
from here no longer meets the definition of ADN, you’re just doing the
special thing that exists only for the purposes of the DNS
Change method.
Tim agreed that minimally there is a lack of clarity
especially around the
scope of whether you can or cannot repeat some of these iterations.
Slaughter stated the language needs to make it clear that by
doing this you
do not control account.myca.com. You should never be able to get a
certificate from account.myca.com.
-
Aaron suggested editing the first paragraph of DNS Change to say
something like “by confirming the presence of a Random Value
or Request
Token in a TXT or CAA record for either 1) an Authorization
Domain Name; or
2) an Authorization Domain Name that is prefixed with a
Domain Label that
begins with an underscore character; or 3) the target of a
CNAME redirect
from an Authorization Domain Name that is prefixed with a
Domain Label that
begins with an underscore character. Others agreed with this
suggestion.
-
Clause #3 and #4 were not discussed due to time constraints.
-
Proposed update regarding due diligence and cross correlation in the
context of automation:
-
Christophe Bonjean provided a high-level summary. The first thing
they did was look into a definition for cross-correlation and due
diligence, as it was not clear what cross-correlation meant in
the context
of EV. The second thing they did was add criteria for what was
in scope and
what was not in scope, especially in the context of automation and domain
validation.
-
Eva Van Steenberge provided more detail saying one of the things they
wanted to address was Aaron’s comment from the last meeting where Section
11.13 should be split into different checks, where each has its own scope
and purpose. They suggested due diligence is checking something that has
been done manually to make sure that it meets the requirements for that
specific process. For example organizational existence and physical
existence. They tried to explicitly say that if this task has been
automated they did not want to limit it to domain validation. If the task
is automated then it doesn't need a human review. If the decision wasn’t
made by a human then it doesn't need a human to review it. Secondly, have
the cross-correlation defined as “do all of these puzzle pieces fit
together nicely”. They outscoped domain name verification and also
suggested removing domain verification fully from the EVGs. The idea is
that cross-correlation happens on the subjects, organization information,
and different roles. They suggest due diligence and
cross-correlation being
able to be completed by a single person. The language will be shared, but
it's currently in a very draft stage.
-
Dimitris asked about the suggestion that due diligence is not
required for automated processes and procedures. I think you are
trying to
create an exception for manual processes that could be done in
an automated
way. We probably need to be more explicit because there are very specific
manual checks that are performed in the EVGs. Eva confirmed this was the
intention and they are open to suggestions.
-
Roman Fischer asked for clarity in the last paragraph where it's
stated it can be the same person because above this paragraph it’s stated
that this is not the same person. Eva explained that the collection of
information happens by person #1. Then we say that the due diligence must
be done by person #2, who is independent from the first
collection, but the
cross-correlation can also be done by person #2, who is independent from
that first collection. Roman agreed with the intent after clarification.
-
Aaron was going to raise the same concern similar to the first one.
There have been a number of incidents in Bugzilla for things like the
address of the business was validated manually but then the City that
contains that address and the State that includes that City were
determined
by automated lookup and the lookup tables were bad. It then turns out 100
certificates all claiming that City “foo” was in the State
“bar”, which was
wrong. It’s slightly concerning to say that was an automated process
therefore it doesn't need review because we’ve seen so many of
these types
of incidents. Eva suggested they can modify the language to only
do it for
domain validation if that is more comfortable for everyone.
-
Due to time constraints the remaining points will be discussed in the
next meeting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20231218/11694f8c/attachment-0001.html>
More information about the Validation
mailing list