[cabf_validation] 3-November 2022 Minutes of the Validation Subcommittee

[Wayne Thayer]

*Attendees: Aaron Poulsen (Amazon), Andrea Holland (SecureTrust), Aneta
Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton
(Entrust), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell
(DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Inigo
Barreira (Sectigo), Kiran Tummala (Microsoft), Michelle Coon (OATI), Paul
van Brouwershaven (Entrust), Rebecca Kelley (Apple), Ryan Dickson (Google),
Thomas Zermeno (SSL.com), Tyler Myers (GoDaddy), Wayne Thayer (Fastly)Corey
Bonnell read the rollCorey read the antitrust statement**Agenda:** - Review
and approval of new certificate profile PRs- Discussion of domain
validation using SVCB/HTTPS records
(https://lists.cabforum.org/pipermail/validation/2022-October/001820.html
<https://lists.cabforum.org/pipermail/validation/2022-October/001820.html>)-
Continue reading BRs for use of “Applicant” and “Applicant Representative”
- We will start at section 6**Clarify OUs in CA Certificates PR**Corey
displayed https://github.com/cabforum/servercert/pull/398
<https://github.com/cabforum/servercert/pull/398> and said that the
language has been further refined. There were no comments so Corey said
that the change would be merged in to the ballot.**Minor fixes PR**Corey
presented  https://github.com/cabforum/servercert/pull/399
<https://github.com/cabforum/servercert/pull/399> which includes:  - Add
order and encoding requirement for DC attribute- Remove overly specific
Cross-cert requirement; fix serialNumber encoding- Clarify NC exclusion-
Remove "Domain Name or IP Address" validation requirement for nowDimitris
Zacharopoulos asked what profile the last change applies to?Corey said that
it applies to all end-entity profiles and explained that the issue with the
existing language is that the definition of ‘domain name’ could even
include single words and is thus overly broad.Corey said that he would
merge in these changes and then the ballot should be ready to
proceed.**Domain Validation for SVCB/HTTPS Records**Corey shared the IETF
draft related to this work
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>). The idea
is to allow CAs to use these new records to validate domain names.Dimitris
asked if this would change anything with the current methods?Corey said
that the idea was to be able to use these records to look up hosts where
domain name validation would be performed. They are used to facilitate
domain resolution for CDNs. It is an alternate way of connecting to a
site.Dimitris said that the argument from Let’s Encrypt was that we could
use other ports, not just the standard ones.Corey said that the CA could
query these records to get the host name and then perform the domain name
check against that host.Wayne Thayer suggested that we add this as a work
item for the subcommittee, and Corey agreed.**Review the BRs for use of
“Applicant” and “Applicant Representative”**Corey said that we agreed to
skip section 5 and displayed section 6 of the BRsBen Wilson pointed out
that section 6.1.1.3 uses the term Subscriber to reference key pair
generation. Should that be changed to Applicant?Corey said that the correct
term is Applicant. This section points to the separation of obligations. If
the CA hosts websites and generates the key pair, is that compliant?Clint
suggested that the language should include both Applicant and Subscriber,
and Dimitris and Thomas Zermeno agreed.Clint WIlson said that one company
operating a CDN and being the CA is a big issue to tease apart. As long as
there is adequate separation this is okay, but determining how to create
that separation is challenging.Aaron Poulsen suggested excluding the
generation of key pairs for test websites.Ben said that there is a
carve-out for this in Mozilla policy.Wayne said that we should explicitly
state that CAs can also hold the role of a Subscriber because that is how
things currently work in practice.Ben suggested adding an exception to
section 1 stating that sometimes a CA may be an Applicant/Subscriber, and
also adding the Mozilla carve-out to section 6.1.1.3. Corey agreed with
adding the carve-out.Wayne said that the carve-out implies that the CA is
not the Applicant, and that causes problems in other sections such as
3.2.2.4 where the Applicant must authorize domain control.Ben disagreed
that this would be a problem, but said that we could add the statement
Wayne suggested to section 1.3.Corey said that is a big change.Ben wondered
if we’d need to further define that the two roles are distinct.Corey said
that the intent on the prohibition of CA generation of Subscriber keys is
to prevent CAs from issuing undesirable certs, e.g. MITM. Not to prevent
the CA from doing so if the Subscriber consents.Wayne said that this
relates to the situation where a cloud provider, e.g. Google Cloud,
operates a website for a customer. It’s common for the cloud provider to be
the Subscriber. There is no concept in the BRs for the cloud provider.Corey
said that the domain controller just sets up the DNS to allow the cloud
provider to do the rest.Ben said that having the CA and cloud provider be
separate legal entities would solve the problem. He suggested that a
subgroup is needed to solve this.Clint said that this group could focus on
the most problematic interpretations, such as the test websites, and that
would solve the most important problems.Ben said that issuing internally
and cloud providers are two separate issues. Clint said he is unsure.Clint
said that this issue needs someone to drive it.Be said that someone needs
to step forward before we create a subgroup.Dimitris asked if there is an
existing problem with this?Clint said that he has heard multiple CAs say
that this is confusing. A persistent annoyance.Wayne said that the biggest
problem he’s aware of is the 3.2.2.4 concept of the Applicant needing to
approve domain validation. If DNS is delegated via CNAME to a cloud
provider, that may not comply if the end customer is the Subscriber.Ben
said that these are two different issues. Ben volunteered to work on
something to clarify the rules around CAs issuing certs to themselves.Corey
said that this group could tackle the cloud provider issues.Corey suggested
the group look at the Subscriber agreement in section 9 at the next
call.The meeting ended.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221106/191064cc/attachment-0001.html>