[cabf_validation] Final minutes for 2023-10-19 Validation-sc meeting

Mon Nov 6 22:15:20 UTC 2023

Here are the approved minutes for the 2023-10-19 Validation-sc meeting, as
taken by Scott Rea (thanks!).

Roll call

Aaron Poulsen (Amazon), Abhishek Bhat (eMudhra), Andrea Holland
(VikingCloud), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns
(Google), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell
(DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris
Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback
(Microsoft), Enrico Entschew (D-TRUST), Janet Hines (VikingCloud), Michael
Slaughter (Amazon), Michelle Coon (OATI), Nargis Mannan (VikingCloud), Nate
Smith (GoDaddy), Rebecca Kelley (Apple), Rollin Yu (TrustAsia Technologies,
Inc.), Ryan Dickson (Google), Scott Rea (eMudhra), Stephen Davidson
(DigiCert), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White
(Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management
Authority)

Note well read

Approval of minutes

Minutes for the F2F meeting (Oct 4th ) session that were distributed to
management list a week ago, were approved.

Next meeting

Next meeting planned for Nov 2nd and Corey will be traveling, so Wayne will
lead the discussion

Review of Agenda

Approved

*	Update from MPIC team (Ryan & Chris)
*	Update from domain validation threat modelling team (Slaughter)
*	Revisit project items on backlog/tracking on Git Hub to prioritise
what to work on next

Update from MPIC team

Ryan gave the update. 2nd endorser (Wayne) has been obtained so ballot has
now been created: SC-067 Require Multi-Perspective Issuance Corroboration.
Currently fielding and adjudicating comments on Git Hub in respect to
proposed modification to the draft. Ryan going on paternity leave (congrats)
so GH account for this purpose will transition to Chris (as an FYI for those
seeking it's location). Plan is to capture a clear draft that
includes/addresses the comments/edits to date across the pre-ballot work.

Update from domain validation threat modelling team

Michael explained that the threat modelling Tiger Team presented results for
delegated domain validation at the F2F which generated wonderful discussion
and feedback, so now next step is to move on to actual language
modifications. Its anticipated there will be 2 tracks: a) modifications to
existing methods; b) introduction of a new validation method.

A Google Doc will be created with proposed language based on discussion and
comments/feedback solicited for track (a). Track (b) is anticipated to be a
longer process and invitations or expressions of interest in participating
in that were sought from the group. NOTE: link to report will be circulated
appropriately once permissions are validated.

Parked/Backlog items

Corey leads this review:

In-Progress Items

*	3 Items in In-Progress list (#366, #359, #362) are all progressing
well
*	#366 Improving Requirements where CA is the Applicant/Subscriber -
one of the items being talked about is the "servicer", and of course #366
kicked off other separate items in our list

On-Deck Items

*	#353 Define standard CAA semantics for limiting cert issuance - 3
different types of potential restrictions envisioned. After Discussion of
individual items (below) it was decided not to split this into 3 separate
items just yet, but to evaluate and prioritise them as a group, and decide
if splitting out is relevant after sufficient consideration and discussion.

1.	DCV method - to specify which methods should be allowed, could be
placed with random value in DNS TXT record. 
2.	Account Identifier - Only the specified CA account can make the
request

*	Dimitris: Concern over potential for applicant to lock themselves
out of being able to get a cert (like pinning created previously). Better
the Identifier is used only as a preference.
*	Slaughter: Do we have any historical data about lockouts when CAA
was introduced? (any lock outs were resolved quickly)
*	Corey: there is an RFC (8657) for CAA records related to ACME that
defines Account ID and main validation methods. No reason it can't be
generalized beyond ACME.
*	Scott: Concern over potential leakage of private info if Acct ID is
not constructed appropriately. Take away is to go read the RFC.
*	Ryan: Would Forum draft recommendations on this or funnel things
through the RFC? Suggested approach for us to make recommendations on which
methods in the RFC Should or Shall be utilized and leave the definition
language in the RFC itself.

3.	Cert type (DV/IV/OV/EV) - only the specified cert type can be
requested

*	Scott: Was the intention to have globally defined types or is each
implementation CA-specific? That level of detail has not been discussed at
this point.

*	#153 Clarify validation requirements for .arpa. Proposed to sunset
this issue since there are no logged recent issuance of these. Suggestion to
specify them as no longer publicly trusted and sunset this item. Volunteers
to shepherd this one through are called for - it would be a good exercise
for newbie's to cut their teeth on because it should not be too onerous.
*	#448 CAA checking for Onion Domain Names - Discussion on this item
leads to the outcome to delay any dealing with this for now until it become
relevant (when other work on Onion related stuff is complete).

Backlog Items

#457 Amend 3.2.5 to not require IV validation for DV - This came out of
analysis of BRs and there is conjecture over whether there is an issue or
not. Expected to be a fast resolution, so decision to move it to In-Progress
list.

#351 Peter's register challenge-response validation method ("Method 13") in
validation summit document - (originally raised by Peter Bowen - Amazon)
Discussion centered around situation where CA is also a Registrar. Some
discussion regarding whether this would constitute creating a Method 13 or
not or whether it was just a mod of Method 12 - but if 12 is deprecated then
it could indeed become a new Method 13 in the doc (since 12 does not have
challenge-response). Path forward was to have existing registrars to discuss
to see if there is value in promoting this still.

#352 Require DNSSEC validation for CAA records when the domain is DNSSEC
enabled - This item may become superfluous as MPIC may negate the need for
the original reason this was raised. Decision to leave this item in the
Backlog until MPIC work is completed and then revisit.

Adjourned

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20231106/04d44a14/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20231106/04d44a14/attachment-0002.p7s>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20231106/04d44a14/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20231106/04d44a14/attachment-0003.p7s>