[cabf_validation] 2023-05-04 Minutes of the Validation Subcommittee [DRAFT]
ryandickson at google.com
Thu May 11 20:09:30 UTC 2023
Meeting Date: May 4, 2023
Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Ben Wilson
(Mozilla), Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson
(Apple), Corey Bonnell (DigiCert), Daryn Wright (GoDaddy), Doug Beattie
(GlobalSign), Dustin Hollenback (Microsoft), Eva Vansteenberge
(GlobalSign), Georgy Sebastian (Amazon), Kiran Tummala (Microsoft), Li-Chun
Chen (Chunghwa Telecom), Martijn Katerbarg (Sectigo), Michael Slaughter
(Amazon), Nargis Mannan (VikingCloud), Pedro Fuentes (OISTE Foundation),
Rebecca Kelley (Apple), Rollin Yu (TrustAsia Technologies, Inc.), Ryan
Dickson (Google), Thomas Zermeno (SSL.com), Tim Hollebeek (DigiCert),
Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne
Corey greeted participants, started the recording, read the attendance
(above), and read the “note well.”
Approving previous meeting minutes:
Doug shared the previous meeting minutes yesterday (May 3rd).
A few people did not receive them, possibly something going on with
the mail server.
The archive appears to have them listed.
We will approve them at the subsequent meeting to give participants
time to review.
Corey summarized the meeting’s planned agenda
Finish discussion of the ACME certificate issuance flow
Discuss any other issuance flows that haven’t already been discussed
Discuss delegation of domain validation (as was identified and
briefly discussed on the April 6th call)
Discussion from Pedro re: EVGs
[No additional items]
ACME Certificate Issuance Workflow
Corey shared screen (presenting this
Summarized where we stopped last time (approximately Step 6, as
listed) - and how third party services can participate in the domain
validation process (i.e., 3rd party provider populates random
values to TXT
records on the applicant’s behalf).
Aaron pointed out that the CNAME delegation is useful for the use
case of migrating from one hosting provider to another because
you can get
your upcoming hosting provider to issue a certificate for your
you have actually transferred your hosting over to them by delegating a
subdomain to them (i.e., prevent interruption of business).
Corey also described an associated IETF draft
to using multiple service providers to get certificates for a domain.
Tim described a scenario where a website operator is running a large
website with numerous renewals happening - and how finding a
window to move
the ACME challenge delegation over to a new provider adds
use case would be helped by having multiple ACME challenge URLs.
Aaron described what might be a common scenario for the type of
transition described earlier (going from a “plain” hosting provider to
something more complex like a CDN).
Wayne shared another example. He indicated that Fastly has customers
that either have a multi-CDN strategy - and they want to integrate with
more than one CDN and both require certs for the domain, or, they have a
domain where some subdomains are pointed to a CDN and others aren’t and
they need the flexibility to support multiple validations
CAs or from multiple providers.
Discussion concluded that the IETF draft aligns well with the
existing Method 7 text.
The authors should consider changing the draft name to “dns-02”
rather than dns-account-01.
[Group continued walking through the steps.]
Aaron clarified the ACME server isn’t just checking the random
value in the subdomain, it’s looking for a concatenation
of two values
(Random value + a value derived from the subscriber's ACME
described earlier in the doc.) This isn’t required per the
BRs, but by RFC
8555. All various ACME flows look for this combined value
some extra transport security over who is presenting the
Note: Correctly computing the concatenated value is
something ISRG often
sees ACME clients struggle with.
CSR: RFC requires public key + SANs requested.
Aaron clarified, the CSR can also sometimes serve an additional
purpose, specifying an EKU (like clientAuth) or other
custom requests (like
including the ‘must-staple’ extension).
Clarification: Technically step 13 can download multiple chains, for
example, to consider cross signs. ACME protocol can expose these and let
the client choose between them.
Closing comment from Clint: earlier, we mentioned that the CSR offered a
mechanism for customizing requests. To some extent, External Account
Binding (EAB) also offers the same, because we can tie requests to a
specific customer account where other configurations might be specified).
Last time we spoke about applicants setting up a CNAME alias to
delegate parts of the domain validation process.
Many ways to do this, to include a CNAME pointed to…
a new hosting provider.
a third party validation service (example
<https://github.com/joohoi/acme-dns> linked in doc).
the CA itself, which might be offering a validation service.
a cloud service provider (CSP)
Historically, conversations around which of these methods are allowed
focused on the legal structure of the CA and the validation
it might offer.
Previous discussion on CSPs that offer CA services and these
CSP contains domain zone, can create records
Differing opinions on what’s allowed or disallowed.
Previous conversation in 2018 determined it is allowed. BRs are open
ended on where the applicant can have a relationship with their providers
to complete domain validation.
Defining a clear set of requirements that promote automation and
security are a good outcome of this discussion.
Doug: It would be good to get guidance and agreement on the entities
that can host CNAME’d locations. Prior guidance from root
programs was that
CAs must not do this.
But, why can’t CAs do this?
Previous argument: the BRs state the applicant has to explicitly
post the random value. This statement could be updated, and we could
improve language such that we do not introduce additional risk.
Tim: Some concern exists, for example, using the same URL for
everyone - and all customers delegate to that same URL, that’ll end very
badly for you. That’s one security risk we might think to address.
Doug: account should be delegated to a domain name, not a specific CA
account. (preclude the option for takeover attacks)
Trev: As a CA, you have to validate correctly that someone controls
the domain. It seems like that solves concerns re: how that’s
set up? Do we
need to define them or define the goal?
Tim: CA is only required to follow an acceptable method. Pointing
everyone to the same URL is compliant with the requirements. It shouldn’t
be, but it is.
Wayne: I think a lot of the work we’ve done to improve the validation
methods has made them more prescriptive so there aren’t these
ways to make
mistakes. Clarifying this is a great candidate and easy opportunity for
Aaron: This problem is not inherent to the CA also being the CDN or
hosting provider. It is totally possible that there could be a
service that says “hey, use me, I’m like certbot but with a web interface
and I’m easy to use — just delegate your ACME challenge CNAME to
and I’ll complete DCV process for you” — that service could
to delegate to a subdomain of the same domain and then anyone could get
certificates for names anyone else is using. The service could also issue
certificates for any domain used by any one of its customers. In the case
that the CA is the provider, this community has influence over those
Tim: we should think about things we can do for the more general
case where it’s not a regulated CA that’s doing this.
Trev: so much of what we’ve discussed is things that people will
just choose to do. Customers choose their providers. If they use a
weird/sketchy third-party service, is that this community’s
do we draw the line?
Aaron: I agree. My hypothetical example was just to make sure my
understanding of why we’re thinking about this (such that the
CA case can’t
be any less secure than one of the described microservices).
Slaughter: concern about being too prescriptive. Applicant or
domain owner would be a threat actor, not the CA. BRs are about CA
behavior. Applicant’s should be free to make terrible decisions and we
should recognize that CAs can’t control this.
Trev: Don’t make prescriptive rules that we can’t enforce or that
can’t be assessed or checked. We can’t do that for applicants.
Corey: BRs could define characteristics if a CA ran a validation
service. Even if we have requirements for CAs, they’ll be incomplete
(because of random services). Not arguing there’s no value in defining
requirements, just highlighting.
Tim - perhaps it should be a “should” requirement. CAs should
think about these things and consider appropriate
mitigations. We can’t
stop this problem completely. I’m skeptical that CAs are
others aren’t. (because CAs are audited and trusted,
third-parties are not).
Trev: We should aim to strike a balance … make something that
achieves the underlying security goals, but is also easy for
people to use.
Use the secure things, not some insecure service that is just easy to use.
Next meeting - discuss whether it’s beneficial to have
requirements related to this initiative
From there, define next steps to possibly include...
Modify the definition of random value…or,
Modify the definition of random value + prescribe specific
language for minimal security considerations.
Pedro's discussion re: EVGs:
EVGs mandate disclosure of registration and incorporation agencies
By omitting the disclosure of QGIS, strict reading is that we
disallow use of those sources during validation
Not all registration/incorporate agencies facilitate means for
verification, so it’s required to use QGIS to retrieve the
Using QGIS is not explicitly allowed, so it would imply
mis-issuances when used
Using QGIS can lead to errors about the JOI, as the QGIS can group
information about subscribers registered in different JOI
levels, and CAs
must properly associate the JOI to the subscriber and not the
Pedro is concerned about using an approach that is not explicitly
Pedo presents a proposed redline that allows use of QGIS.
[Participants indicated the update sounds reasonable.]
Implementation path: Could roll into 3647 reformat update, but
Pedro cited he was uncomfortable with current practices given current
Pedro to raise at SCWG (collect more feedback and to help identify
ordering of the related ballot compared to the 3647 update).
No additional comments
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation