[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