[cabf_validation] Draft Minutes for the Validation Subcommittee Meeting held on September 8, 2022

Ryan Dickson ryandickson at google.com
Fri Sep 9 03:19:00 UTC 2022

Hi all,

Draft minutes below. Please review and propose edits, if necessary.




   Andrea Holland - SecureTrust

   Aneta Wojtczak - Microsoft

   Ben Wilson - Mozilla

   Bruce Morton - Entrust

   Chris Clements - Google Chrome

   Clint Wilson - Apple

   Corey Rasmussen - OATI

   Dimitris Zacharopoulos - HARICA

   Doug Beattie - Globalsign

   Inigo Barreira - Sectigo

   Jamie Mackey - US Federal PKI Management Authority

   Janet Hines - SecureTrust

   Joanna Fox - TrustCor Systems

   Joe Ramm - OATI

   Johnny Reading - GoDaddy

   Li-Chun Chen - Chunghwa Telecom

   Michael Slaughter - Amazon Trust Services

   Michelle Coon - OATI

   Pekka Lahtiharju - Telia

   Rebecca Kelley - Apple

   Ryan Dickson - Google Chrome

   Tim Hollebeek - DigiCert

   Tyler Myers - GoDaddy

   Wayne Thayer - Certainly

   Wendy Brown - US Federal PKI Management Authority



   Roll Call and Begin Recording

      Meeting recording was enabled.

      Ryan volunteered to capture meeting minutes.

      Wayne read attendance, presented above (see “Attendees”).


   Read Antitrust Statement

       Wayne read the anti-trust statement.


   Agenda (and corresponding discussion)

      Certificate Profiles

         GRID Certificate Update

            Dimitris will coordinate with Corey and Clint on next steps re:
            GRID certificates (following-up on an action included in
the last meeting’s

            TL;DR: ongoing actions in response to the discussions from F2F
            56 and subsequent Validation Subcommittee calls will
likely delay changes
            to the profiles that impact GRID certificate validation.

         All Encompassing Effective Date

            GitHub Link: https://github.com/cabforum/servercert/pull/381

            Corey proposed moving to April 15th, no objections from the

         Certificate Policies in OCSP Responder Certificates

            GitHub Link: https://github.com/cabforum/servercert/pull/381

            Consensus moving from NOT RECOMMENDED to MUST NOT

            Question: why were we going to use “not recommended” rather
            than the more RFC 2119 accepted “should not”. Discussion
highlighted this
            specific phrasing was intended to more strongly
communicate use of the
            practice is not advised.

         Pending Prohibition Definition Discussion

            GitHub Link: https://github.com/cabforum/servercert/pull/388

            No concerns with the definition proposed by Aneta.

            The pull request will be accepted.

      Continued discussion on use of “applicants”

         Wayne summarized the intent of the discussion.

         The group walked through the BRs to review instances of the term
         “Applicant”, enumerated below

            Definitions (Section 1.6.1):

               Discussed “Applicant”

                  Wendy recommended we change “Once the Certificate issues"
                  to "Once the Certificate is issued".

               Discussed “Applicant Representative”

                  Tim highlighted that the phrase “authorized agent who has
                  express authority to represent the Applicant”
(definition of “Applicant
                  Representative”) may be a source of confusion.

                  Discussion continued to suggest “Applicant
                  Representative” may be an overloaded term.

                     Could consider splitting this into two terms to better
                     clarify and distinguish the roles we see in some
implementations (i.e.,
                     cloud service providers).

               Discussed “Random Value”

                  Discussed removing “Applicant” from the definition

                     If removed, we need to make it clear that the CA shall
                     ONLY share this value with the applicant.

                     Tim mentioned an older draft ballot that identified
                     which values MUST be kept secret might be worth revisiting.

                     Further, some definitions, like this, mix definitions
                     with requirements (bad practice - the same is
true with “Request Token”).

               Discussed “Reliable Data Source”

                  Concern: in cloud implementations, the Applicant (i.e.,
                  cloud service customer) may never obtain the
certificate (included in the

               Discussed “Request Token”

                  Warning: the note includes an RFC 2119 requirement term
                  (i.e., “may”)

               Discussed “Subscriber Agreement”

                  Uses the phrase “Applicant/Subscriber”.

                  Later in the BRs, we distinguish “Subscriber Agreement”
                  and “Terms of Use” (applies when the CA or an
affiliate of the CA is the

                  “Terms of Use” is the only explicit location in the BRs
                  where we identify the CA can be a subscriber.

                  Discussion suggested we should not modify or otherwise
                  consolidate these terms.

                     Past work cleaned up and standardized the use of these
                     terms, though they are often referenced in close proximity.

                     Modifying these terms would require legal review, we
                     should tread lightly here.

            3.2.2 (Authentication of ORganization and Domain Identity)

               Opening sentence “If the Applicant requests a certificate…”

                  We could remove the phrase “Applicant” because it’s not
                  necessarily germane to the requirement.

                  But, later, where we discuss subject identity
                  information, “applicant” is relevant (as it is later
in this paragraph
                  where the “applicant” is the subject initiating an action).

                  Thought Exercise #1: walking through the section
                  replacing “Applicant” with “CA” seemed to generally read fine

                  Thought Exercise #2: walking through the section
                  replacing “Applicant Representative” with “cloud
service provider” also
                  seemed to read fine


               Reads strange that a CA would be verifying its own identity
               through a communication mechanism.

               We want to identify that a verification method that works
               for applicants should also be able to work for CAs.

                  i.e., accepting that the bulleted list of 4 items is
                  acceptable for when the Applicant is a CA.


               If you follow the thought exercise where you replace
               “Applicant” with “CA”, it seems to read fine.

   (Verification of Country)

               If you follow the thought exercise where you replace
               “Applicant” with “CA”, it seems to read fine.

   (Validation of Domain Authorization or Control

               Group discussed deferring this section to a later time

               Source of issues in this section: cloud service provider
               confirmation of the validation of FQDNs included in the
certificate prior
               to issuance

               Might make progress by describing what validating ownership
               or control of the domain actually means

               Observation: this is an area where several CAs have
               misunderstood the requirement, where they are not
validating their own
               domain names. Perhaps note that even for the CA, they
need to perform this
               for their own domains.

            Broader comments on approach:

               From Dimitris: would it be worth having a discussion to
               better describe the operational models in use today
(i.e., those of cloud
               service providers), and from that, refine definitions?

               From Tim: generating a RACI chart re: roles may be

         Defining next steps:

            Go through each of the subsections looking at use of
            “applicant” and “applicant representative” for continued
discussion at the
            next meeting.


   Minutes approval

       No objections to approval of last meeting’s minutes


   [Call concluded]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220908/b2d2a131/attachment-0001.html>

More information about the Validation mailing list