[cabf_validation] Draft Minutes for the Validation Subcommittee Meeting held on July 28, 2022
Ryan Dickson
ryandickson at google.com
Fri Jul 29 11:57:36 UTC 2022
Minor correction below, looks like I missed Wendy in the attendees list
(sorry, Wendy!):
Attendees:
- Aaron Poulsen - Amazon Trust Services
- Amanda Mendieta - Apple
- Andrea Holland - SecureTrust
- Aneta Wojtczak - Microsoft
- Bruce Morton - Entrust
- Ben Wilson - Mozilla
- Chris Clements - Google Chrome
- Clint Wilson - Apple
- Corey Bonnell - DigiCert
- Dustin Hollenback - Microsoft
- Joanna Fox - TrustCor Systems
- Joe Ramm - OATI
- Johnny Reading - GoDaddy
- Li-Chun Chen - Chunghwa Telecom
- Michael Slaughter - Amazon Trust Services
- Rebecca Kelley - Apple
- Ryan Dickson - Google Chrome
- Tobias Josefowitz - Opera
- Trevoli Ponds-White - Amazon Trust Services
- Wayne Thayer - Certainly
- Wendy Brown - US Federal PKI Management Authority
Discussion:
-
Roll Call and Begin Recording
-
Wayne enabled meeting recording.
-
Ryan volunteered to capture meeting minutes.
-
Corey read attendance, presented above (see “Attendees”).
-
Read Anti-trust Statement
-
Corey read the anti-trust statement.
-
Agenda Topics
-
Review work items logged in Github (
https://github.com/cabforum/servercert/projects/2) to identify future
work items
-
Discussion on certificate profiles (progress, questions that came up
while addressing items, etc.), if needed
-
Minutes approval
-
Dimitris shared previous meeting minutes (July 14).
-
There was minor discussion and refinements to minutes (July 15).
-
No objections for approval of minutes.
-
Minutes approved in the absence of objections.
-
GitHub Review
-
Intent is to ensure momentum is not lost on other priority items
while the group concludes Profiles V1.
-
Corey led the group through a review of the items in the GitHub
<https://github.com/cabforum/servercert/projects/2> issues list to
help prioritize future work efforts.
-
There were two (1 <https://github.com/cabforum/servercert/issues/374>
and 2 <https://github.com/cabforum/servercert/issues/375>) other
issues posted by Wayne a few weeks ago that have not yet been triaged by
Corey (either setting status as “Backlog” or “On Deck”).
-
Reviewing “Backlog” Items
-
Peter’s registrar challenge-response validation method
-
Clint said it’s an interesting method, but not necessarily
something that seems to be immediately beneficial to spend
our time on.
-
Wayne indicated a more general desire to promote automation in
validation and come up with validation methods that are
easier to support
automation. Feedback from the group offered consensus that
the overall goal
of promoting automation is more compelling than this
specific method.
-
Corey described an “On Deck” item that is more aligned with the
goals of automation.
-
Conclusion: Dedicate future time to discuss automaton goals and
how we might promote this initiative. Leave this item in
the backlog.
-
Require DNSSEC
-
Clint expressed the information security community is
conflicted on the value of DNSSec.
-
No strong response from the group to prioritize this issue.
-
Conclusion: Keep in the backlog.
-
DNS Fragmentation Attacks
-
A few years ago there was an interesting presentation on
fragmentation attacks. Back then, we discussed this as a
future item, but
have not explored further.
-
No strong response from the group to prioritize this issue.
-
Conclusion: Keep in the backlog.
-
Define CAA Semantics for limiting cert issuance to DV/OV/IV/EV
-
Corey described that CAs can technically achieve this today,
but the intended goal was to establish an industry-wide standard of
accomplishing this goal.
-
Clint mentioned he sees value in defining semantics related to
CAA at the CA/B Forum level, and probably more as S/MIME
BRs progress, but
the general idea of defining what semantics/expectations
of the forum is
helpful to ensure consistency across working groups. There
should be
broader discussion on risk whether this is an appropriate
use of the CAA
record, or if we risk overloading the record.
-
Wayne recalled discussion on previously using CAA to limit the
domain validation methods CAs could use. Clint also
recalled discussion
about specific account identifiers that could constrain issuance.
-
Trev agreed with Clint’s meta-point, describe/define use of CAA
to promote consistent implementations.
-
Conclusion: This particular item isn’t a priority, but
standardizing and clarifying CAA records, especially in
the context of
potential for automation, is of interest. Moved to “On-Deck”.
-
Require Validation Method OIDs in Certificates
-
Wendy expressed a concern about the agility / impact of
including these policy OIDs in CA certificates (needing to
reissue CA certs
as new methods are established).
-
Clint mentioned this would just be for leaf-certificates.
-
Intent possibly used to identify problematic validation methods.
-
Recording the domain validation method does not seem to offer
clear security value and also causes bloat within certificates.
-
Michael described past discussions about allowing consumers to
restrict certificates based on validation methods being used.
-
No strong response from the group to prioritize this issue.
-
Ryan asked about how we remove items from the backlog / closing
them long-term, given the absence of clear value and
long-term retention of
the issue just creates clutter/future distraction for
similar activities in
the future.
-
Group discussed that we could close the issue and record final
determination, if needed to be re-opened, we could.
-
Update EVGL to improve vetting rigor
-
Context not carried over from Trello, seems collectively the
group has expressed interest and the need to prioritize
the EVGLs - so
perhaps this issue represents a broader need to update the
EVGLs (aligned
with annual goal/priority as discussed at F2F).
-
Wayne found reference to Ballot 225 in the issue - Section 11.8
“Operational Existence”. The mailing list may hold further
context (later
discussion indicated this was related to the reliability
of QIS vetting.
-
https://lists.cabforum.org/pipermail/validation/2018-May/000882.html
-
https://archive.cabforum.org/pipermail/validation/2018-June/000905.html
-
Corey expressed that we should have targeted updates for the
group’s attention, rather than just a general update to a
given document or
section.
-
Conclusion: Retire this issue, create a new issue with specific
action. Bruce volunteered to research further.
-
Define CAA extensions for validation methods (Define CAA Semantics
for limiting cert issuance to DV/OV/IV/EV)
-
Similar to earlier discussion on CAA.
-
Conclusion: Moved to “On-Deck”.
-
Analyze JOI disclosures resulting from ballot SC30
-
No strong response from the group to prioritize this issue.
-
Clint indicated he’d like to see this issue left open.
-
Conclusion: Retain in the backlog.
-
Ensure consistency of “applicant” definition in 3.2.2.4 with
remainder of BRs
-
Long thorn in the BRs - there are language issues when the CA
is an applicant and how CAs issue certificates to
themselves (subscriber
key generation issue).
-
Conclusion: the issue title is a little misleading, but it
seems worthwhile to revisit the relationships of terms - and
especially issues in the BRs where the CA is a subscriber.
Issue is broader than the Validation Subcommittee, bubble
up to SCWG or
maybe the future definitions working group to direct
attention to the
issue.
-
How this specific issue fits in scope of this subcommittee is
open for debate, but there’s agreement the issue should be
addressed.
-
Conclusion: Item moved to “On-Deck” but the focus will be on
the challenges / absence of clarity in the BRs where CA is
the subscriber.
-
Issues with EV Enterprise RA Language
-
Bruce: Goal to make “enterprise-RA” for EV and not EV the same
definition (different definitions for similar roles, which
should be
considered the same role).
-
Conclusion: Bruce volunteered to draft some concrete language
and follow-up. Moved to “On-Deck”.
-
Permit inclusion of LEIs in Subject Fields
-
No clear context copied over from Trello to GitHub. Problem
space is not clear. Is it a matter of being able to assign
a single,
unique, global identifier for an organization?
-
S/MIME working group drafted requirements to allow LEIs in
S/MIME certs. Perhaps we can explore the language being
added there and see
if it’s appropriate for TLS?
-
Tobias clarifies that this should not be in scope for DV.
-
Several others (Ryan/Trev/Corey) agreed that scope should not
include DV.
-
No strong response from the group to prioritize this issue.
-
Conclusion: Retain, but keep in backlog. Follow-up once S/MIME
BRs are further along.
-
Before moving on, Ryan asked about why CAs would be compelled
to add more data to subject name to only add further risk
of misissuance.
It seems most mis-issuance/incidents we see in EV certs
are related to
issues with JOI or other organization attributes, so why
would CAs be
motivated to increase potential for mis-issuance,
perceived or otherwise?
-
Corey indicated that the S/MIME BRs are standardizing on a
subset of identifiers (for example, removing JOI) so
this could help reduce
mis-issuance long-term)
-
Create Allow-List of RA Agencies used by CAs for EV JOI
-
Discussion: Retain in backlog.
-
Improve CAA logging requirements
-
Related to a misissuance event, more on MDSP (linked in issue).
Seems like this issue is missing concrete update
needs/recommendations, but
more of a broader review related to what CA’s record to
help detect/triage
mis-issuances.
-
Clint indicated it seems specific language would be difficult
to come by, but perhaps more this is about clarifying
expectations about
logging. This could already be addressed by the updates in SC-51.
-
Issue framing from Trev: Ensure CAs are collecting sufficient
data to investigate CAA errors.
-
Conclusion: Revisit and evaluate against the changes made in
SC-51.
-
Reviewing “On Deck” Items
-
To be discussed on the next call (out of time).
-
Profile Progress Review
-
Deferred (out of time).
-
Other business:
-
None, next meeting on 8/11.
-
Conclusion
On Thu, Jul 28, 2022 at 12:40 PM Ryan Dickson <ryandickson at google.com>
wrote:
> Hi all,
>
> Draft minutes below. Please review and propose edits, if necessary.
>
>
> Attendees:
>
> -
>
> Aaron Poulsen - Amazon Trust Services
> -
>
> Amanda Mendieta - Apple
> -
>
> Andrea Holland - SecureTrust
> -
>
> Aneta Wojtczak - Microsoft
> -
>
> Bruce Morton - Entrust
> -
>
> Ben Wilson - Mozilla
> -
>
> Chris Clements - Google Chrome
> -
>
> Clint Wilson - Apple
> -
>
> Corey Bonnell - DigiCert
> -
>
> Dustin Hollenback - Microsoft
> -
>
> Joanna Fox - TrustCor Systems
> -
>
> Joe Ramm - OATI
> -
>
> Johnny Reading - GoDaddy
> -
>
> Li-Chun Chen - Chunghwa Telecom
> -
>
> Michael Slaughter - Amazon Trust Services
> -
>
> Rebecca Kelley - Apple
> -
>
> Ryan Dickson - Google Chrome
> -
>
> Tobias Josefowitz - Opera
> -
>
> Trevoli Ponds-White - Amazon Trust Services
> -
>
> Wayne Thayer - Certainly
>
>
> Discussion:
>
>
> -
>
> Roll Call and Begin Recording
> -
>
> Wayne enabled meeting recording.
> -
>
> Ryan volunteered to capture meeting minutes.
> -
>
> Corey read attendance, presented above (see “Attendees”).
>
>
>
> -
>
> Read Anti-trust Statement
> -
>
> Corey read the anti-trust statement.
>
>
>
> -
>
> Agenda Topics
> -
>
> Review work items logged in Github (
> https://github.com/cabforum/servercert/projects/2) to identify
> future work items
> -
>
> Discussion on certificate profiles (progress, questions that came
> up while addressing items, etc.), if needed
>
>
>
> -
>
> Minutes approval
> -
>
> Dimitris shared previous meeting minutes (July 14).
> -
>
> There was minor discussion and refinements to minutes (July 15).
> -
>
> No objections for approval of minutes.
> -
>
> Minutes approved in the absence of objections.
>
>
>
> -
>
> GitHub Review
> -
>
> Intent is to ensure momentum is not lost on other priority items
> while the group concludes Profiles V1.
> -
>
> Corey led the group through a review of the items in the GitHub
> <https://github.com/cabforum/servercert/projects/2> issues list to
> help prioritize future work efforts.
> -
>
> There were two (1
> <https://github.com/cabforum/servercert/issues/374> and 2
> <https://github.com/cabforum/servercert/issues/375>) other issues
> posted by Wayne a few weeks ago that have not yet been triaged by Corey
> (either setting status as “Backlog” or “On Deck”).
> -
>
> Reviewing “Backlog” Items
> -
>
> Peter’s registrar challenge-response validation method
> -
>
> Clint said it’s an interesting method, but not necessarily
> something that seems to be immediately beneficial to spend our time on.
> -
>
> Wayne indicated a more general desire to promote automation
> in validation and come up with validation methods that are easier to
> support automation. Feedback from the group offered consensus that the
> overall goal of promoting automation is more compelling than this specific
> method.
> -
>
> Corey described an “On Deck” item that is more aligned with
> the goals of automation.
> -
>
> Conclusion: Dedicate future time to discuss automaton goals
> and how we might promote this initiative. Leave this item in the backlog.
> -
>
> Require DNSSEC
> -
>
> Clint expressed the information security community is
> conflicted on the value of DNSSec.
> -
>
> No strong response from the group to prioritize this issue.
> -
>
> Conclusion: Keep in the backlog.
> -
>
> DNS Fragmentation Attacks
> -
>
> A few years ago there was an interesting presentation on
> fragmentation attacks. Back then, we discussed this as a future item, but
> have not explored further.
> -
>
> No strong response from the group to prioritize this issue.
> -
>
> Conclusion: Keep in the backlog.
> -
>
> Define CAA Semantics for limiting cert issuance to DV/OV/IV/EV
> -
>
> Corey described that CAs can technically achieve this today,
> but the intended goal was to establish an industry-wide standard of
> accomplishing this goal.
> -
>
> Clint mentioned he sees value in defining semantics related
> to CAA at the CA/B Forum level, and probably more as S/MIME BRs progress,
> but the general idea of defining what semantics/expectations of the forum
> is helpful to ensure consistency across working groups. There should be
> broader discussion on risk whether this is an appropriate use of the CAA
> record, or if we risk overloading the record.
> -
>
> Wayne recalled discussion on previously using CAA to limit
> the domain validation methods CAs could use. Clint also recalled discussion
> about specific account identifiers that could constrain issuance.
> -
>
> Trev agreed with Clint’s meta-point, describe/define use of
> CAA to promote consistent implementations.
> -
>
> Conclusion: This particular item isn’t a priority, but
> standardizing and clarifying CAA records, especially in the context of
> potential for automation, is of interest. Moved to “On-Deck”.
> -
>
> Require Validation Method OIDs in Certificates
> -
>
> Wendy expressed a concern about the agility / impact of
> including these policy OIDs in CA certificates (needing to reissue CA certs
> as new methods are established).
> -
>
> Clint mentioned this would just be for leaf-certificates.
> -
>
> Intent possibly used to identify problematic validation
> methods.
> -
>
> Recording the domain validation method does not seem to offer
> clear security value and also causes bloat within certificates.
> -
>
> Michael described past discussions about allowing consumers
> to restrict certificates based on validation methods being used.
> -
>
> No strong response from the group to prioritize this issue.
> -
>
> Ryan asked about how we remove items from the backlog /
> closing them long-term, given the absence of clear value and long-term
> retention of the issue just creates clutter/future distraction for similar
> activities in the future.
> -
>
> Group discussed that we could close the issue and record
> final determination, if needed to be re-opened, we could.
> -
>
> Update EVGL to improve vetting rigor
> -
>
> Context not carried over from Trello, seems collectively the
> group has expressed interest and the need to prioritize the EVGLs - so
> perhaps this issue represents a broader need to update the EVGLs (aligned
> with annual goal/priority as discussed at F2F).
> -
>
> Wayne found reference to Ballot 225 in the issue - Section
> 11.8 “Operational Existence”. The mailing list may hold further context
> (later discussion indicated this was related to the reliability of QIS
> vetting.
> -
>
>
> https://lists.cabforum.org/pipermail/validation/2018-May/000882.html
> -
>
>
> https://archive.cabforum.org/pipermail/validation/2018-June/000905.html
> -
>
> Corey expressed that we should have targeted updates for the
> group’s attention, rather than just a general update to a given document or
> section.
> -
>
> Conclusion: Retire this issue, create a new issue with
> specific action. Bruce volunteered to research further.
> -
>
> Define CAA extensions for validation methods (Define CAA
> Semantics for limiting cert issuance to DV/OV/IV/EV)
> -
>
> Similar to earlier discussion on CAA.
> -
>
> Conclusion: Moved to “On-Deck”.
> -
>
> Analyze JOI disclosures resulting from ballot SC30
> -
>
> No strong response from the group to prioritize this issue.
> -
>
> Clint indicated he’d like to see this issue left open.
> -
>
> Conclusion: Retain in the backlog.
> -
>
> Ensure consistency of “applicant” definition in 3.2.2.4 with
> remainder of BRs
> -
>
> Long thorn in the BRs - there are language issues when the CA
> is an applicant and how CAs issue certificates to themselves (subscriber
> key generation issue).
> -
>
> Conclusion: the issue title is a little misleading, but it
> seems worthwhile to revisit the relationships of terms - and
> especially issues in the BRs where the CA is a subscriber.
> Issue is broader than the Validation Subcommittee, bubble up to SCWG or
> maybe the future definitions working group to direct attention to the
> issue.
> -
>
> How this specific issue fits in scope of this subcommittee is
> open for debate, but there’s agreement the issue should be addressed.
> -
>
> Conclusion: Item moved to “On-Deck” but the focus will be on
> the challenges / absence of clarity in the BRs where CA is the subscriber.
> -
>
> Issues with EV Enterprise RA Language
> -
>
> Bruce: Goal to make “enterprise-RA” for EV and not EV the
> same definition (different definitions for similar roles, which should be
> considered the same role).
> -
>
> Conclusion: Bruce volunteered to draft some concrete language
> and follow-up. Moved to “On-Deck”.
> -
>
> Permit inclusion of LEIs in Subject Fields
> -
>
> No clear context copied over from Trello to GitHub. Problem
> space is not clear. Is it a matter of being able to assign a single,
> unique, global identifier for an organization?
> -
>
> S/MIME working group drafted requirements to allow LEIs in
> S/MIME certs. Perhaps we can explore the language being added there and see
> if it’s appropriate for TLS?
> -
>
> Tobias clarifies that this should not be in scope for DV.
> -
>
> Several others (Ryan/Trev/Corey) agreed that scope should not
> include DV.
> -
>
> No strong response from the group to prioritize this issue.
> -
>
> Conclusion: Retain, but keep in backlog. Follow-up once
> S/MIME BRs are further along.
> -
>
> Before moving on, Ryan asked about why CAs would be compelled
> to add more data to subject name to only add further risk of misissuance.
> It seems most mis-issuance/incidents we see in EV certs are related to
> issues with JOI or other organization attributes, so why would CAs be
> motivated to increase potential for mis-issuance, perceived or otherwise?
> -
>
> Corey indicated that the S/MIME BRs are standardizing on a
> subset of identifiers (for example, removing JOI) so this could help reduce
> mis-issuance long-term)
> -
>
> Create Allow-List of RA Agencies used by CAs for EV JOI
> -
>
> Discussion: Retain in backlog.
> -
>
> Improve CAA logging requirements
> -
>
> Related to a misissuance event, more on MDSP (linked in
> issue). Seems like this issue is missing concrete update
> needs/recommendations, but more of a broader review related to what CA’s
> record to help detect/triage mis-issuances.
> -
>
> Clint indicated it seems specific language would be difficult
> to come by, but perhaps more this is about clarifying expectations about
> logging. This could already be addressed by the updates in SC-51.
> -
>
> Issue framing from Trev: Ensure CAs are collecting sufficient
> data to investigate CAA errors.
> -
>
> Conclusion: Revisit and evaluate against the changes made in
> SC-51.
> -
>
> Reviewing “On Deck” Items
> -
>
> To be discussed on the next call (out of time).
>
>
>
> -
>
> Profile Progress Review
> -
>
> Deferred (out of time).
>
>
>
> -
>
> Other business:
> -
>
> None, next meeting on 8/11.
>
>
>
> -
>
> Conclusion
>
>
> Thanks,
> Ryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220729/a0f74cf0/attachment-0001.html>
More information about the Validation
mailing list