[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



   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

      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
      time to move CAA-relevant language out of Section 2.2 and into,
      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 (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 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 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

         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

         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

         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
         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
         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
         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
         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
         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 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

      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

      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
      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