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

[Ryan Dickson]

Hi all,

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

Thanks,
Ryan


Attendees:

   1.

   Andrea Holland - SecureTrust
   2.

   Aneta Wojtczak - Microsoft
   3.

   Ben Wilson - Mozilla
   4.

   Bruce Morton - Entrust
   5.

   Chris Clements - Google Chrome
   6.

   Clint Wilson - Apple
   7.

   Corey Rasmussen - OATI
   8.

   Dimitris Zacharopoulos - HARICA
   9.

   Doug Beattie - Globalsign
   10.

   Inigo Barreira - Sectigo
   11.

   Jamie Mackey - US Federal PKI Management Authority
   12.

   Janet Hines - SecureTrust
   13.

   Joanna Fox - TrustCor Systems
   14.

   Joe Ramm - OATI
   15.

   Johnny Reading - GoDaddy
   16.

   Li-Chun Chen - Chunghwa Telecom
   17.

   Michael Slaughter - Amazon Trust Services
   18.

   Michelle Coon - OATI
   19.

   Pekka Lahtiharju - Telia
   20.

   Rebecca Kelley - Apple
   21.

   Ryan Dickson - Google Chrome
   22.

   Tim Hollebeek - DigiCert
   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.
      -

      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
            minutes).
            -

            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
            group.
            -

         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
                  definition).
                  -

               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
                  applicant).
                  -

                  “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
                  -

            3.2.2.1 (Identity)
            -

               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.
                  -

            3.2.2.2 DBA/Tradename
            -

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

            3.2.2.3 (Verification of Country)
            -

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

            3.2.2.4 (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
               beneficial.
               -

         Defining next steps:
         -

            Go through each of the 3.2.2.4 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>