[cabf_validation] Draft Minutes for the Validation Subcommittee Meeting at F2F 57 held on October 26, 2022
Chris Clements
cclements at google.com
Thu Dec 1 19:34:12 UTC 2022
Hello!
Minutes from the VSC meeting on Day 3 at F2F 57 are drafted below.
---
Server Certificate WG Meeting - Validation Subcommittee Meeting
Leader: Corey Bonnell (DigiCert)
Minute Taker: Chris Clements (Google Chrome)
Presentation Link:
Minutes:
Corey Bonnell started the meeting and confirmed the Validation Subcommittee
is still in context of the Server Certificate Working Group, thus there is
no need to rehash attendance or antitrust.
Minutes Approval:
-
Dimitris circulated the Meeting Minutes from the October 6 meeting to
the list.
-
Corey asked if there were any objections to approving the minutes.
-
No objections were voiced and the minutes were approved.
Progress since Summer F2F:
Corey shared a slide describing the committee's progress since the last F2F
meeting.
-
Previously discussed EVG “cleanup” items were put to ballot:
-
SC-56 included several editorial issues that were identified in the
Baseline Requirements and Extended Validation Guidelines over the past 2
years.
-
Certificate Profiles:
-
Resolving issues identified at previous F2F meetings. Prior
discussions were very productive.
-
Moving collaboration point to the CAB Forum GitHub repository. Easier
collaboration.
-
Final reviews/tweaks of the language are ongoing.
-
Kicked off analysis on the “Applicant” and “Applicant Representative”
roles.
-
In general, the committee deferred a lot of other topics for the
certificate profile work.
Agenda for today:
Corey outlined the agenda for today’s meeting.
1.
Certificate Profiles Open Items:
-
The committee has been working on this ballot for well over 2 years. He
believes this work can be pushed to ballot with a few remaining to-do’s.
1.
Continue review of BRs for use of “Applicant” and “Applicant
Representative”:
-
There are several areas in the BRs where the separation between
Applicant and the CA are not well defined.
-
CAs issuing Certificates to itself (Test Websites, etc.)
-
Domain validation
-
Key generation
-
A strict reading of the requirements may imply you are violating one or
the other.
-
To holistically identify these issues, we are reading through the BRs
and identifying all usages of the term “Applicant” and “Applicant
Representative”.
Certificate Profiles Ballot:
There are 2 PRs open right now 395 & 398.
-
Clarify OUs in CA Certificates #398 (
https://github.com/cabforum/servercert/pull/398)
-
This PR introduces a sunset with a separate effective date. Want to
define a top-level effective date.
-
Tim voiced concern of the PR specifying requirements for non-TLS CAs
and the thought that other working groups should weigh in on requirements
for these other types of CAs. The TLS BRs should focus on TLS
requirements.
-
Jeremy noted this example highlights the need for a “forum of forums”
to walk these types of requirements. Specifically, the Server Cert Work
Group should not create requirements that the SMIME Work Group is
responsible for.
-
Martjin asked if the language drafted as is, would still allow for an
OU in a TLS Root CA certificate?
-
The committee agreed the language should be adjusted slightly to
reflect that the requirement applies to Root CA certificates.
-
Dimitirs stated he would update the PR to reflect the conversation
from today and include some formatting edits.
-
Add order and encoding requirement for DC attribute #395 (
https://github.com/cabforum/servercert/pull/395)
-
In Warsaw the committee agreed that the DC attribute should continue to
exist in Web PKI.
-
Corey asked for any objections and none were received.
-
This PR will be merged.
-
Minor fixes and cleanups #399 (
https://github.com/cabforum/servercert/pull/399)
-
Corey stated this is another open PR, but it is still in draft.
-
He expects it to be pushed next week.
-
For OCSP responders, OCSP pointers are allowed but CA issuers are not.
Is this backwards?
-
Corey stated he received this question last week related to the profiles
ballot and wanted to raise it to the committee.
-
Should we adjust the profile to allow for the CA issuer pointer?
-
Clint asked if this something CAs are currently including.
-
When Corey researched a few months ago there were a few certificates
with the value but he does not recall the specific count.
-
The person that raised the question is not present today, so no
additional context can be provided at this time.
-
Corey will raise the question on the distribution list.
-
Corey stated we have had a couple other ballots that intersected with
the certificate profiles ballot, so there will be a bit of work to
integrate those additional edits into the profiles ballot. He will perform
those edits.
-
Corey asked if there were any other questions on the certificate
profiles ballot that the committee wants to raise. There were no additional
questions or comments on the certificate profiles ballot.
Applicant and Applicant Representative:
-
The committee has reviewed the BRs through section 4.1.2 and has
identified a few issues to date.
-
Section 4.1.2 Review:
-
In the last conversation the committee left off with discussing what a
“certificate request” is, as is not exactly clear, as stated today.
-
Corey stated we need to clarify what this section is requiring of CAs.
-
Ben highlighted the fact that the BRs have had multiple contributing
authors over the years and multiple perspectives may have been built into
the existing wording.
-
Trevoli stated the BRs do not currently have a concept of renewing
certificates. Ambiguity exists over what is the beginning of a certificate
request.
-
Ben suggested using the Let’s Encrypt model as the use case and
rewriting this section with that model in mind.
-
Corey stated this conversation touches on some of the improvement ideas
from the last meeting.
-
Jeremy suggested it may make sense to completely overhaul the request
requirements, as they were originally defined back in 2014.
-
Tim seconded the suggestion, stating even the CSR models have shifted
over time.
-
Clint steered the conversation back to the original question and
suggested this section as written does not cause any issues, but it may be
helpful to clarify a certificate request may come from a CA itself if the
CA is the applicant/subscriber. We should add a backlog item to track the
definition of a certificate request.
-
The committee agreed with the suggestion and Clint will add an issue to
GitHub.
-
Section 4.2 Review:
-
The 3rd paragraph that starts with Section 6.3.2 warrants a review.
-
Section 4.6 Review:
-
This section could be used for defining certificate renewal
requirements.
-
Jeremy stated the original direction of the BRs included each
certificate request being treated as a new request.
-
Tim stated the BRs currently handle certificate renewals differently
than traditional PKIs. We should also consider certificate re-key
requirements, specifically with key compromise responses in mind.
-
Corey stated a need to review RFC 3647 and determine what is stated for
subject identity information for these types of requests.
-
Section 4.9 Review:
-
4.9.1.1 has a use of “Applicant” that should be “Subscriber”.
-
Section 5 Review:
-
Does not use the term “Applicant”.
-
The next Validation Sub Committee meeting should resume with Section 6.
-
Clint identified after Section 6, the group will move into the profiles
section, which may conflict with the profiles branch.
Corey concluded the meeting.
---
Thank you
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221201/dfdcba78/attachment-0001.html>
More information about the Validation
mailing list