[cabf_validation] Draft Minutes of Meeting Held February 9, 2023

[Ben Wilson]

*Validation Subcommittee – Minutes of Thursday, February 9, 2023*

*Minute Taker:*  Ben Wilson  (*Next Up:*  Andrea Holland)

*Attendance*:  Aaron Poulsen - Amazon Trust Services, Andrea Holland -
VikingCloud, Aneta Wojtczak – Microsoft, Bruce Morton – Entrust, Ben Wilson
– Mozilla, Chris Clements - Google Chrome, Clint Wilson – Apple, Corey
Bonnell – DigiCert, Doug Beattie – GlobalSign, Dustin Hollenback –
Microsoft, Enrico Entschew - D-Trust, Iñigo Barreira – Sectigo, Joe Ramm –
OATI, Kiran Tummala – Microsoft, Martijn Katerbarg – Sectigo, Michelle Coon
– OATI, Nargis Mannan – VikingCloud, Paul van Brouwershaven – Entrust,
Pekka Lahtiharju – Telia, Rebecca Kelley – Apple, Rollin Yu – TrustAsia,
Ryan Dickson - Google Chrome, Michael Slaughter – Amazon, Stephen Davidson
– DigiCert, Tobias Josefowitz – Opera, Trevoli Ponds-White - Amazon Trust
Services, Wendy Brown - FPKIMA

*Antitrust Statement:* Read by Corey Bonnell

*Previous Minutes:  *Minutes of January 26, 2023, prepared by Aneta
Wojtczak, unanimously approved.

*Agenda Review:*   Notably, the certificate profiles topic is no longer on
the list, because that is now up in the Server Certificate Working Group,
and the discussion period has started.

Face-to-face planning:  The role of the Applicant and Applicant
Representatives as defined in the BRs. We've also had some discussion on
LEIs, which is another topic that we can discuss.  What else?

There is the OCSP-optional ballot, but maybe that is a Server Certificate
Working Group topic and not a Validation Subcommittee topic. Ryan Dickson
was planning on pursuing that more seriously after the profiles ballot
because of the way that that changes would flow. With regards to business
of the Server Certificate WG, there was also the other OCSP ballot proposed
by David Kluge regarding SLAs, but for these kinds of things we do not seem
to find time during the WG meetings to discuss them.  We might use some of
the time to discuss Server Certificate WG items. Still, the problem seems
to be that we only have half an hour every other week because we are with
the Forum call, so it’s something we should think about for the
face-to-face meeting.  Bruce agreed with looking at the face-to-face
schedule to see what we can address from the Server Certificate WG
perspective.

Ryan proposed that we discuss multi-perspective domain validation, because
we will hear from a guest speaker, Henry Briggs-Lee of Princeton, who
specializes in multi-perspective domain validation or multi-vantage point
domain validation, BGP hijacking, and network style attacks. We could have
proactive discussions following the presentation.

It was agreed that we should discuss multi-perspective validation and the
research findings. It will be presented and then we can also do the
Applicant/Applicant’s Representative next-steps discussion as well.

Ben mentioned that he would talk about incident report types and that about
50% of the incidents in Bugzilla have been EV or OV misissuances, and he’d
like to discuss how we can bring that number down.  However, he didn’t
think he was ready to address that yet, because he needs to look more
carefully at the underlying causes, and he hasn’t done a full analysis of
those.

Bruce suggested that because the EV Guidelines are coming up on being 17 or
18 years old, maybe it was time to revise them.  They are too legal and not
techie/not as technical as the rest of our specs, and maybe EV misissuances
will go down with simpler EV requirements.

Ben said that from his recollection, there is always some field that got
mis-validated, either in OV or EV, and there's certainly more OV than EV.

We should look to where the requirements can be improved to mitigate
against misissuance, but until we have more root cause analyses, it might
be difficult to have the discussion.

We have two potential topics--Applicant Representative next steps and
multi-perspective domain validation.  Do we want to split the time half and
half and go 45 minutes with each one?  Well if there's no strong opinion,
we can go half and half.

The third agenda item for today is to look at next steps in our analysis of
the BR's “Applicant” and “Applicant Representative”.  The notable items
have been divided into 3 buckets, the first of which is “To keep in mind”,
the second is “To discuss further,” and the third is “To do”.  Discussion
items might warrant further discussion to come up with actionable next
steps in terms of developing concrete requirements, while to-do items are
more straightforward.

First, we have noted that we should try to maintain the current language in
the Subscriber Agreement and Terms of Use requirements to avoid any messy
legal changes. But in BR Section 9.6.3 we have talked about replacing
Subscriber with Applicant/Subscriber, and then also changing the language
to differentiate “initial certificate requests” and “subsequent requests”.  Ben
was in favor of making the changes proposed in BR section 9.6.3.

Second, there are five “to discuss further” items that Corey distilled from
the conversations.  From his email of February 6, they were:

1. Do we need a term to encompass the concept of a current Subscriber that
has submitted a Certificate Request for a new Certificate?

2. Ben's language for section 1.3.3:
https://lists.cabforum.org/pipermail/validation/2022-November/001826.html

a. Does this resolve concerns around CAs issuing Test Website certificates,
etc.?

3. More closely examine references to "hosting providers" in section 9.6.3
and other locations

a. This ties very closely into the extensive discussion in November on
"Cloud Providers" issuing certificates from CAs that are controlled by the
"Cloud Provider":
https://lists.cabforum.org/pipermail/validation/2022-November/001827.html

4. What exactly is a “certificate request”? Sections 4.1 and 4.2 need help,
as it's not clear what exactly a "certificate request" is or what exactly a
"certificate request" is comprised of (
https://github.com/cabforum/servercert/issues/400)

5. What do the Terms of Use accomplish when the Subscriber is the CA?



The first item is that we need a term to encompass the concept of a current
subscriber that has submitted a certificate request for a new certificate.
Ben asked if we could just use the term “current subscriber”?  Or there
might be some other phrase that says “the subscriber seeking renewal”.  We
looked at BR sections 4.1.2, 4.1.4, and 4.2.1. The concept expressed there
is that one certificate request may suffice for multiple certificates being
issued to the same applicant.  One idea was that if we used
Applicant/Subscriber down in section 9.6.3, then we could use
Applicant/Subscriber elsewhere in the BRs, too.  However, would it change
the meaning of the section where the certificate may not be issued yet. So
there was concern about introducing the word “Subscriber” and whether it
might cause confusion.

Corey said it would be good to have a term that addresses the different
situations where the applicant is seeking to renew a certificate or obtain
additional certificates.

Clint said that a subscriber can be an applicant, and an applicant can be a
subscriber, and sometimes both at once, and sometimes separately, but it is
unclear where that causes confusion for CAs and where and how it can be
fixed to address any concerns or provide more clarity.

Doug said that we have the definition for Applicant and Applicant
Representative, but we don't have the same for Subscriber, and should we
adopt something for a “Subscriber Representative”? They would be delegated
certain abilities to manage certificates that the subscriber may have
allocated to them, like revocation by a third party or something like that?

Trev said that we need to address how people want to manage certificates.
They want to obtain a certificate and get another one so that their service
stays up and running. There may be places in the BRs where we have written
the rules in a way that is hostile to automation. Can someone just say,
“for this duration, I am using this other service just to manage my
certificates for me”?

Doug asked about delegating responsibilities to a reseller or partner.  Can
you delegate revocation responsibilities to a reseller for all the
certificates that they resell?  Can the subscriber explicitly say,
somewhere along the way, “that's OK”?

Clint said that it made sense to provide clarity in those areas, such as a
subscriber representative, because there is delegation and shared
responsibility, preserving the idea that ultimately the subscriber is
responsible, but that doesn’t address the question of whether the
subscriber can be an applicant.

Trev said we need to look at how people want to use certificates.  For
example, 10-day certificates--some people might interpret the BRs to mean
that every time someone gets a new ten-day certificate they need to have
performed a manual action to agree to a subscriber agreement.  That's the
opposite of what we want, and what people want to do with certificates.

Corey said that the notion of a subscriber representative, and also the
aspects of automation, touch closely on some of the other discussion points
that we raised and have discussed previously around hosting providers and
cloud providers, which is in Point 3.  Maybe if we address that first, then
it can feed into these other issues?

Ben asked whether we needed someone to write up a use case or a conceptual
model that we can use to compare how these service providers do automated
certificate renewal or issue additional certificates. And then we could go
through the BRs and determine whether the current language works or not or
where we need to make an adjustment to the BRs to accommodate these newer
service models. Whatever that thing is that manages certificates for the
users, and then we identify those rough parts in the BRs.

Corey asked whether we should look at different models, like CDNs, hosting
providers, and any other services we can think of, and try to model those
services in terms of the applicant, the subscriber, and the CA, and their
relationships, and then identify misalignment with the BRs in terms of
those models.

There was general agreement that we should look at how these things work,
or how we want them to work, and then come back to the BRs.  It was also
suggested that between the meeting and the upcoming face-to-face meeting
that work could be done on each of these different models so that we could
discuss them at the face-to-face meeting.  We could also have people
identify their pain points, because in this respect there may be groups
using ACME that have pain points with the current BRs.

The group then discussed some of the differences between a traditional
hosting provider and the cloud service provider.  In some situations, the
Subscriber generates the key on the hosting provider’s machine, and is
given a CSR. The Subscriber then finds a CA and brings back the certificate
chain and then an administrator, or some automated interface, takes that
certificate chain and installs it on the web server, whereas in the cloud
model it is more automated.

The ACME model was also mentioned. Ryan explained that with ACME, you first
register an account with the CA, and at that point you accept the terms of
service or subscriber agreement. You register an account that basically
creates a local key pair that is then used to sign all subsequent requests
to that service. You're accepting the subscriber agreement once and then
thereafter anytime you make any request either to replace an existing
certificate, renew or revoke. You do not sign a new subscriber agreement.
It's basically accept once, use many.  RFC 8555 basically describes two
life cycles within the service itself. The first is registration, and the
second is certificate management. So you perform registration once, and
that's where you're creating a specific account with the ACME server, which
we can think of as like the CA. And once that is done, you basically have a
local key pair on your device, that is, that is then used to authenticate
feature requests to the CA.

The group then discussed spinning up some document sharing to explore the
different service models, and Corey will be sending an email seeking
volunteers.

The meeting on February 23, 2023, will be cancelled.  The next meeting
following the face-to-face will be on March 9, 2023.

Meeting adjourned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230215/1b74f9ba/attachment-0001.html>