[cabf_validation] Minutes for the Validation Subcommittee Meeting held on January 25, 2024

[Corey Bonnell]

These minutes were approved on today's validation-sc call.

 

Minutes from Validation Working Group Meeting 2024-01-25

Minute Taker: Janet Hines (VikingCloud) 

Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Abhishek
Bhat (eMudhra), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla),
Bruce Morton (Entrust), Cade Cairns (Google), Chris Clements (Google), Clint
Wilson (Apple), Corey Bonnell (DigiCert), David Kluge (Google), Doug Beattie
(GlobalSign), Eva Vansteenberge (GlobalSign), Inigo Barreira (Sectigo),
Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Joseph Ramm (OATI),
Keshava Nagaraju (eMudhra), Kiran Tummala (Microsoft), Mads Henriksveen
(Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon),
Michelle Coon (OATI), Miguel Sanchez (Google), Nargis Mannan (VikingCloud),
Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Pekka
Lahtiharju (Telia Company), Rebecca Kelley (Apple), Roman Fischer
(SwissSign), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Stephen Davidson
(DigiCert), Thomas Zermeno (SSL.com), Tim Hollebeek (DigiCert), Tobias
Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer
(Fastly), Wendy Brown (US Federal PKI Management Authority)

Corey Bonnell read the note well statement.

 

Agenda:

1.	Status update on MPIC work (if needed)
2.	Discussion on GlobalSign's automation improvement language (proposal
will be circulated prior to meeting)
3.	Continue discussion on identifying Delegated Third Parties (DTPs) in
the context of domain validation.

 

Approval of minutes:

December 14, 2023 meeting minutes were approved.

January 11, 2024 meeting minutes which were recirculated with minor
correction were approved.

 

Upcoming Meetings:

*        The February 8 meeting will be spent preparing for the face-to-face
meeting.  

*        The February 22 meeting may be canceled due to travel for the
face-to-face meeting.

 

Status update on MPIC work:

*        Chris Clements:  IP disclosure commitment from Princeton was
finalized and signed.  It grants a worldwide royalty free license for MPIC
work.  This will be attached to the ballot preamble.  Anticipate public
discussion on this ballot to start in March 2024.

*        Tim Hollebeek: Raised concerns around Princeton not signing the
Cabforum IPR agreement and how to deal with any members voting 'no' because
of the legal IP aspect of this ballot and the ballot passing as this forum
ballot could override those members legal rights.

*        Chris: Wanted to have an extended discussion for the ballot due to
the IPR.

*        Clint Wilson: Need more concrete examples of what the IPR concerns
may be to have a better discussion on that.

*        Tim: The dynamics of IPR conversations are such that it may not be
possible to have an open and public discussion around all the relevant
concerns.  Hopeful that everyone's legal counsel will review this ballot as
well.  The forum working group should discuss how to avoid ever having this
problem going forward.

 

Automation Improvement language:

*        Eva Van Steenberge presented on this topic.  She will distribute
the PowerPoints with the background information and thoughts around the
changes. 

o   Slide 2: Due diligence and domain validation (11.13) - Removing the
reference to suggest that these checks must be performed for each
certificate, but rather a check be done prior to issuance.

o   Slide 3: Due diligence and domain validation (11.13) - Trying to
out-scope the domain validation if automated.

o   Slide 4: Due diligence and domain validation (11.13) - Specific
out-scoping of domain validation, regardless of automated or manual, as
there isn't anything to cross-correlate.

o   Slide 5: Requirements for Re-use of Existing Documentation (11.14) -
Wanted to make sure that the due diligence could be relied upon with prior
collected information for multiple issuances, such as organization
information.

o   Slide 6: Requirements for Re-use of Existing Documentation (11.14) -
Changed wording around age for data to add conditions of reuse.

o   Slide 7: Requirements for Re-use of Existing Documentation (11.14) - The
due diligence is not reused, but rather relied upon.  Added a couple of
conditions on it such as reliance on due diligence only where age is
appropriate.  Wanted to have the preapproved approver give their approval
via an automated way.

*  Tim: What methods are manual verses automated?

*  Eva: Manual examples are phone call or notarized letter.  Automated
example would be approval via the portal.  11.9.2 is very similar.

*  Tim: May not agree that there is meaningful difference that should cause
policy differences but will review in more detail.

*  Eva: If automated means for the approval, then no reason to review that
verses a telephone call with notes that should be reviewed.

o   Slide 8: Separation of Duties (14.1.3) - Removed the notion that it must
be done for every certificate.  It may be done for the organization and then
reused in automation.

o   Slide 9: Verification of Approval of EV Certificate Request (11.10) -
Use 'ensure' rather than 'verify' so not necessarily something that needs to
be checked on each certificate.

*  Tim: Both words appear to say the same thing.  Maybe some more words
rather than changing the verb.

*  Eva: There is a difference in the meanings.

*  Tim: Don't rely on the difference but make it more explicit.

o   Slide 10: Verification of Signature on Subscriber Agreement and EV
Certificate Requests (11.9) - Previous language suggests Certificate Request
was pre-authorized, when 11.8.4 is about pre-authorization of the
certificate Approver (who can subsequently post-authorize new requests).
Noticed this and changed it.

o   Slide 11: Data Security (16) - At least two people needed to be involved
in the issuance of a certificate.  This caused more confusion.

*        Clint: on Slides 3 and 4 - Wants to give the language more
attention.  The goal is understood, but don't want additional consequences.

*        Eva: Maybe we rely on the BRs for domain validation.

*        Tim: Think this section is obsolete but will review as well.

*        Corey: Next steps for people to review the language and move on
from there.

 
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/compar
e/main...chrisbn:servercert:improve-evg-automation-issue-467___.YXAzOmRpZ2lj
ZXJ0OmE6bzoxMzJmNTVkODE5MzhjNDk3Yjk3YjNjZDY0NmJiZmU0ZTo2OmRiM2M6MjBmMzdiZjJj
ZDBmYTJmNGFjNWY3YmRhZTJiZmM2NDBlNmQwODEyZTBiZDc1MzEzMjVkYzYwMzdiNGNhZTdlMDpo
OkY>
https://github.com/cabforum/servercert/compare/main...chrisbn:servercert:imp
rove-evg-automation-issue-467

 

Identifying DTPs in the context of Domain Validation:

*        Server Cert and Validation are both working on this.  How to divide
it up?

*        Aaron Gable:
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/4
75___.YXAzOmRpZ2ljZXJ0OmE6bzoxMzJmNTVkODE5MzhjNDk3Yjk3YjNjZDY0NmJiZmU0ZTo2Om
E2ZTI6MDVmZGU1NzVhZGVlOGYzNDljNjdjMTFkZDMzNGVlZTRmYjVjMTUyNjZjMTMyOWEzOTI5Mm
Q4NmM1NmVmNmE1ZDpoOkY> https://github.com/cabforum/servercert/pull/475
Dimitris Zacharopoulos and Mads Henriksveen have been helping with the
wording, then going to send out for an official discussion period.

o   Trying to rely on definitions and similar sentence added to 3.2.2.4 and
3.2.2.5.

o   This ballot does not attempt to solve the entire problem.

*        Tim: There is a challenge in getting the language correct for this.
For example, I look up the baseline requirements to read a specific
requirement while doing my validation, I open a browser to do that, have I
made an error using a third-party resolver?

*        Aaron: It is not a requirement that you look up the baseline
requirements to do the validation.

*        Tim: So change it to 'the DNS queries conducted during the course
of validation .' to tighten up the language.

*        Aaron: I worry about this language, for example, for email, fax,
SMS, or postal mail to domain contact, there are multiple ways to get the
domain contacts so that if I used the query to DNS to get an SOA record, the
DNS query isn't required to be since there are other ways to get the
information.

*        Tim: So, that is not the right language either.  Maybe further
clarification on which DNS queries are in scope and which ones aren't
without ambiguity.  I don't know what the language is.

*        Ben Wilson: I liked the language, i.e. without the use of recursive
resolvers, but when it gets down to the allowed sources, that gives me
concern.  You are referencing somewhere else in the document, but I am not
sure where.

*        Aaron: The intent is BR 1.6 for domain contact for the 3 allowed
sources.

*        Ben: Figure out how to refer to it so that the reader looks at 1.6
for information.

*        Martijn Katerbarg: Looking at the language and what Tim pointed out
and the section is within 3.2.2.4, does it mean that it counts for the
entire BRs or only the subsection of 3.2.2.4?  Where does CAA fall?  

*        Aaron: The intent is just for 3.2.2.4.  But 3.2.2.8 CAA records
would not be covered.  However, MPIC ballot will cover this.  I will work on
suggestions here.

*        Mads Henriksveen: Prepared some slides on Allowed Sources for
3.2.2.4.2

o   Domain Contact: - Is DNS SOA misplaced?   Similar to method 13 and 14.

*  WHOIS from Domain Name Registrar and Registry Operator.  What are
authoritative sources for WHOIS Records?

o   WHOIS Lookups - using Domain Name Registrar - Which Domain Name
Registrar may be used for: .com, .gr, .no, etc.

*  Is there any risk here when using one of these as DTP?

*  Need more definition around this.

*        Tim: Isn't it clear for any specific DNS Name for the registrar
registry?

*        Mads: It isn't clear from our perspective.

*        Paul van Brouwershaven: Who is the authoritative name server?  If
you query for the domain at IANA should tell you which registrar to use.
The problem with a third-party use here is in the parsing of that data.

*        Mads: Which type of service are we allowed to use?

*        Tim: RDAP allowance was added for the format issues.  We should
check in on the progress of the conversion.

*        Corey: Bringing this up in the Server Cert meeting may be a quicker
resolution on this.

 

Meeting Adjourned.

 

 






Company Registration Details
VikingCloud is the registered business name of Sysxnet Limited. Sysxnet
Limited is registered in Ireland under company registration number 147176
and its registered office is at 1st Floor, Block 71a, The Plaza, Park West
Business Park, Dublin 12, Ireland. 

Email Disclaimer
The information contained in this communication is intended solely for the
use of the individual or entity to whom it is addressed and others
authorized to receive it. It may contain confidential or legally privileged
information. If you are not the intended recipient you are hereby notified
that any disclosure, copying, distribution or taking any action in reliance
on the contents of this information is strictly prohibited and may be
unlawful. If you have received this communication in error, please notify us
immediately by responding to this email and then delete it from your system.
Sysxnet Limited is neither liable for the proper and complete transmission
of the information contained in this communication nor for any delay in its
receipt..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240208/42cee85f/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240208/42cee85f/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/20240208/42cee85f/attachment-0001.p7s>