[cabf_validation] Draft Minutes for the Validation Subcommittee Meeting held on August 11, 2022
Chris Clements
cclements at google.com
Thu Aug 11 16:43:38 UTC 2022
Hello!
Minutes from today's meeting are detailed below.
Attendees:
1.
Aaron Poulsen - Amazon Trust Services
2.
Amanda Mendieta - Apple
3.
Aneta Wojtczak - Microsoft
4.
Ben Wilson - Mozilla
5.
Bruce Morton - Entrust
6.
Chris Clements - Google Chrome
7.
Clint Wilson - Apple
8.
Corey Bonnell - DigiCert
9.
Corey Rasmussen - OATI
10.
Doug Beattie - Globalsign
11.
Dustin Hollenback - Microsoft
12.
Joanna Fox - TrustCor Systems
13.
Joe Ramm - OATI
14.
Johnny Reading - GoDaddy
15.
Li-Chun Chen - Chunghwa Telecom
16.
Martijn Katerbarg - Sectigo
17.
Michelle Coon - OATI
18.
Pekka Lahtiharju - Telia
19.
Rebecca Kelley - Apple
20.
Ryan Dickson - Google Chrome
21.
Tobias Josefowitz - Opera
22.
Trevoli Ponds-White - Amazon Trust Services
23.
Tyler Myers - GoDaddy
24.
Wayne Thayer - Certainly
25.
Wendy Brown - US Federal PKI Management Authority
Discussion:
-
Roll Call and Begin Recording
-
Meeting recording was enabled.
-
Chris volunteered to capture meeting minutes.
-
Corey read attendance, presented above (see “Attendees”).
-
Read Antitrust Statement
-
Corey read the anti-trust statement.
-
Minutes approval
-
Ryan shared previous meeting minutes (July 29).
-
No objections for approval of minutes.
-
Minutes approved due to the absence of objections.
-
Agenda Topics
-
Continue grooming the backlog. We’ll be reviewing the “On Deck” items
at https://github.com/orgs/cabforum/projects/1.
-
(Time permitting) Review several in-progress work items:
-
Aneta’s keyUsage PR:
https://github.com/cabforum/servercert/pull/376
-
Bruce’s “EV Enterprise RA” change:
https://lists.cabforum.org/pipermail/validation/2022-July/001790.html
-
Bruce’s removal of the EV 3-second rule:
https://lists.cabforum.org/pipermail/validation/2022-July/001789.html
-
GitHub On Deck Review
-
Delegating DNS to the CA for purposes of validating domains #362
-
Discussed last time and falls under the better automation bucket.
-
No additional thoughts on this issue.
-
Will remain as is.
-
Define standard CAA semantics for limiting cert issuance #353
-
Was moved from the Backlog in the previous meeting, made more
generic, and moved up in priority.
-
No additional thoughts on this issue.
-
Will remain as is.
-
Require domain validations to be performed from multiple network
perspectives or some other form of BGP hijack mitigation #359
-
DNS is fundamentally insecure.
-
Clint suggested this issue be moved to a lower priority in the On
Deck queue due to the complexity and multiple moving parts
associated with
its resolve.
-
Trevoli suggested reviewing all existing On Deck issues to
determine if they remain or get moved to Backlog and then taking a
prioritization pass of the issues that remain as On Deck.
-
Corey agreed and continued down the list to consider any
additional issues that needed to be moved to Backlog.
-
Improve requirements where the CA is the Applicant/Subscriber #366
-
Was moved to On Deck in the last meeting.
-
Will remain as is.
-
Validity period for Technically Constrained Sub-CA and validation
period for Domain Namespace #326
-
Corey’s understanding was this issue would address the concern
where a CA originally performed domain name validation and a
certificate
with a long validity period, administrator forgets to renew the domain
registration and someone else ends up registering the domain name. The
proposal would either restrict the validity period or require
revalidation
of the domain name.
-
Clint voiced he has no strong opinion and that this appears to be
a valid problem that on the surface has a solution for resolve.
-
Corey suggested moving to Backlog and Clint agreed.
-
Clarify validation requirements for .arpa #153
-
Historically, some CAs have issued TLS certificates with DNS names
that include .arpa.
-
Corey mentioned ongoing discussion within the IETF of using .arpa
in the TLD. This could create confusion if a TLS certificate
includes a DNS
name with .arpa and the TLS protocol is using the SNI value
that includes
.arpa.
-
Clint supports keeping this in On Deck.
-
Standardize State and Province names #364
-
A good idea, but seems to be very complex in resolution.
-
Corey suggested moving to Backlog. No disagreement.
-
Information reuse - varying reuse period based on factors such as
length of domain registration, site popularity, etc.
-
Trevoli and Corey suggested this issue was related to EV/OV. Site
popularity was added as a metric but the original context is unclear.
-
Trevoli voiced no strong feelings for chasing this issue.
-
Corey agreed and suggested the issue be moved to Archive.
-
No objection moving to Archive.
-
Trevoli is not convinced we would get extra information from the
Registrar's.
-
Corey will archive after today’s call.
-
On Deck Prioritization (ordered in github)
-
Clint suggested the Delegating DNS (#362) issue as having the most
immediate impact.
-
Ryan suggested we prioritize these issues against automation and
agility themes. Trevoli and Wayne agreed.
-
Corey suggested the .arpa (#153) issue may be low hanging fruit and
an easy win for the group.
-
Clint suggested there may be some overlap between the Delegating DNS
(#362) and the CA is the Applicant/Subscriber (#366) issues.
-
Trevoli suggested the CA is the Applicant/Subscriber (#366) issue may
contribute to resolving the Delegating DNS (#362) issue.
-
Wayne suggested the CAA (#353) issue has more value and ecosystem
impact in resolution when compared to the .arpa (#153) issue.
-
Corey asked for any disagreement on the proposed final five ordering
(as stacked in github, and detailed below). No disagreement was received.
-
Improve requirements where the CA is the Applicant/Subscriber #366
-
Delegating DNS to the CA for purposes of validating domains #362
-
Define standard CAA semantics for limiting cert issuance #353
-
Clarify validation requirements for .arpa #153
-
Require domain validations to be performed from multiple network
perspectives or some other form of BGP hijack mitigation #359
-
Changes to Key Usage values for Subscriber Certificates #376
-
Corey asked if there were any objections with this PR. If not, it
will be merged.
-
Aneta asked if we should add a note of “will be forbidden soon” or
similar?
-
Clint mentioned it is hard to define how soon is “soon” but he is
not opposed to the idea.
-
Trevoli recalls past conversations of adding “not recommended on
path to deprecation” or similar. Is there a small phrase we
can place in
the table to indicate that we do intend to completely deprecate in the
future? We should be very clear and remove ambiguity in these types of
statements.
-
General conversation surrounding “not recommended”, “deprecated”,
“discouraged”, and “pending prohibition”.
-
Corey suggested we come to a definition of this term that clearly
describes the intent. Consider using “pending prohibition”.
-
Ryan suggested creating a new issue so that we do not lose sight
of these future sunsets long term. The same is true for other items
deferred from Profiles V1.
-
Aneta volunteered to create a new PR.
-
Remove "3-second rule" for downloading CRLs for EV certificate chains
#345
-
Straight forward cleanup.
-
Clint is not aware of anyone who is actively measuring this
requirement.
-
Next step, open a PR against the BRs.
-
This could be correlated with the EV Enterprise RA language clean up.
-
Clean up EV Enterprise RA language #344
-
No value in having two terms defined slightly differently.
-
Why create two roles to do almost the same thing? This creates an
implementation challenge.
-
Clint suggested we perform due diligence and read through the EVG’s
with a lens for EV RA and ensure there are no conflicts with the BRs.
-
Action for a second person (other than Bruce) to perform the review.
-
Corey suggested adding #345 and #344 to the existing cleanup ballot.
-
Ben and Bruce agreed.
-
Conclusion
-
The group can expect to spend some time looking at certificate
profiles in the next meeting.
-
Any additional time in the next meeting can be spent on the highest
On Deck priorities.
Thank you!
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220811/d783ff8b/attachment-0001.html>
More information about the Validation
mailing list