[cabf_validation] Draft Minutes for the Validation Subcommittee Meeting held on July 28, 2022

Ryan Dickson ryandickson at google.com
Thu Jul 28 16:40:25 UTC 2022


Hi all,

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


Attendees:

   -

   Aaron Poulsen - Amazon Trust Services
   -

   Amanda Mendieta - Apple
   -

   Andrea Holland - SecureTrust
   -

   Aneta Wojtczak - Microsoft
   -

   Bruce Morton - Entrust
   -

   Ben Wilson - Mozilla
   -

   Chris Clements - Google Chrome
   -

   Clint Wilson - Apple
   -

   Corey Bonnell - DigiCert
   -

   Dustin Hollenback - Microsoft
   -

   Joanna Fox - TrustCor Systems
   -

   Joe Ramm - OATI
   -

   Johnny Reading - GoDaddy
   -

   Li-Chun Chen - Chunghwa Telecom
   -

   Michael Slaughter - Amazon Trust Services
   -

   Rebecca Kelley - Apple
   -

   Ryan Dickson - Google Chrome
   -

   Tobias Josefowitz - Opera
   -

   Trevoli Ponds-White - Amazon Trust Services
   -

   Wayne Thayer - Certainly


Discussion:


   -

   Roll Call and Begin Recording
   -

      Wayne enabled meeting recording.
      -

      Ryan volunteered to capture meeting minutes.
      -

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



   -

   Read Anti-trust Statement
   -

       Corey read the anti-trust statement.



   -

   Agenda Topics
   -

      Review work items logged in Github (
      https://github.com/cabforum/servercert/projects/2) to identify future
      work items
      -

      Discussion on certificate profiles (progress, questions that came up
      while addressing items, etc.), if needed



   -

   Minutes approval
   -

      Dimitris shared previous meeting minutes (July 14).
      -

      There was minor discussion and refinements to minutes (July 15).
      -

      No objections for approval of minutes.
      -

      Minutes approved in the absence of objections.



   -

   GitHub Review
   -

      Intent is to ensure momentum is not lost on other priority items
      while the group concludes Profiles V1.
      -

      Corey led the group through a review of the items in the GitHub
      <https://github.com/cabforum/servercert/projects/2> issues list to
      help prioritize future work efforts.
      -

      There were two (1 <https://github.com/cabforum/servercert/issues/374>
      and 2 <https://github.com/cabforum/servercert/issues/375>) other
      issues posted by Wayne a few weeks ago that have not yet been triaged by
      Corey (either setting status as “Backlog” or “On Deck”).
      -

      Reviewing “Backlog” Items
      -

         Peter’s registrar challenge-response validation method
         -

            Clint said it’s an interesting method, but not necessarily
            something that seems to be immediately beneficial to spend
our time on.
            -

            Wayne indicated a more general desire to promote automation in
            validation and come up with validation methods that are
easier to support
            automation. Feedback from the group offered consensus that
the overall goal
            of promoting automation is more compelling than this
specific method.
            -

            Corey described an “On Deck” item that is more aligned with the
            goals of automation.
            -

            Conclusion: Dedicate future time to discuss automaton goals and
            how we might promote this initiative. Leave this item in
the backlog.
            -

         Require DNSSEC
         -

            Clint expressed the information security community is
            conflicted on the value of DNSSec.
            -

            No strong response from the group to prioritize this issue.
            -

            Conclusion: Keep in the backlog.
            -

         DNS Fragmentation Attacks
         -

            A few years ago there was an interesting presentation on
            fragmentation attacks. Back then, we discussed this as a
future item, but
            have not explored further.
            -

            No strong response from the group to prioritize this issue.
            -

            Conclusion: Keep in the backlog.
            -

         Define CAA Semantics for limiting cert issuance to DV/OV/IV/EV
         -

            Corey described that CAs can technically achieve this today,
            but the intended goal was to establish an industry-wide standard of
            accomplishing this goal.
            -

            Clint mentioned he sees value in defining semantics related to
            CAA at the CA/B Forum level, and probably more as S/MIME
BRs progress, but
            the general idea of defining what semantics/expectations
of the forum is
            helpful to ensure consistency across working groups. There
should be
            broader discussion on risk whether this is an appropriate
use of the CAA
            record, or if we risk overloading the record.
            -

            Wayne recalled discussion on previously using CAA to limit the
            domain validation methods CAs could use. Clint also
recalled discussion
            about specific account identifiers that could constrain issuance.
            -

            Trev agreed with Clint’s meta-point, describe/define use of CAA
            to promote consistent implementations.
            -

            Conclusion: This particular item isn’t a priority, but
            standardizing and clarifying CAA records, especially in
the context of
            potential for automation, is of interest. Moved to “On-Deck”.
            -

         Require Validation Method OIDs in Certificates
         -

            Wendy expressed a concern about the agility / impact of
            including these policy OIDs in CA certificates (needing to
reissue CA certs
            as new methods are established).
            -

            Clint mentioned this would just be for leaf-certificates.
            -

            Intent possibly used to identify problematic validation methods.
            -

            Recording the domain validation method does not seem to offer
            clear security value and also causes bloat within certificates.
            -

            Michael described past discussions about allowing consumers to
            restrict certificates based on validation methods being used.
            -

            No strong response from the group to prioritize this issue.
            -

            Ryan asked about how we remove items from the backlog / closing
            them long-term, given the absence of clear value and
long-term retention of
            the issue just creates clutter/future distraction for
similar activities in
            the future.
            -

            Group discussed that we could close the issue and record final
            determination, if needed to be re-opened, we could.
            -

         Update EVGL to improve vetting rigor
         -

            Context not carried over from Trello, seems collectively the
            group has expressed interest and the need to prioritize
the EVGLs - so
            perhaps this issue represents a broader need to update the
EVGLs (aligned
            with annual goal/priority as discussed at F2F).
            -

            Wayne found reference to Ballot 225 in the issue - Section 11.8
            “Operational Existence”. The mailing list may hold further
context (later
            discussion indicated this was related to the reliability
of QIS vetting.
            -


               https://lists.cabforum.org/pipermail/validation/2018-May/000882.html
               -


               https://archive.cabforum.org/pipermail/validation/2018-June/000905.html
               -

            Corey expressed that we should have targeted updates for the
            group’s attention, rather than just a general update to a
given document or
            section.
            -

            Conclusion: Retire this issue, create a new issue with specific
            action. Bruce volunteered to research further.
            -

         Define CAA extensions for validation methods (Define CAA Semantics
         for limiting cert issuance to DV/OV/IV/EV)
         -

            Similar to earlier discussion on CAA.
            -

            Conclusion: Moved to “On-Deck”.
            -

         Analyze JOI disclosures resulting from ballot SC30
         -

            No strong response from the group to prioritize this issue.
            -

            Clint indicated he’d like to see this issue left open.
            -

            Conclusion: Retain in the backlog.
            -

         Ensure consistency of “applicant” definition in 3.2.2.4 with
         remainder of BRs
         -

            Long thorn in the BRs - there are language issues when the CA
            is an applicant and how CAs issue certificates to
themselves (subscriber
            key generation issue).
            -

            Conclusion: the issue title is a little misleading, but it
            seems worthwhile to revisit the relationships of terms - and
            especially issues in the BRs where the CA is a subscriber.
            Issue is broader than the Validation Subcommittee, bubble
up to SCWG or
            maybe the future definitions working group to direct
attention to the
            issue.
            -

            How this specific issue fits in scope of this subcommittee is
            open for debate, but there’s agreement the issue should be
addressed.
            -

            Conclusion: Item moved to “On-Deck” but the focus will be on
            the challenges / absence of clarity in the BRs where CA is
the subscriber.
            -

         Issues with EV Enterprise RA Language
         -

            Bruce: Goal to make “enterprise-RA” for EV and not EV the same
            definition (different definitions for similar roles, which
should be
            considered the same role).
            -

            Conclusion: Bruce volunteered to draft some concrete language
            and follow-up. Moved to “On-Deck”.
            -

         Permit inclusion of LEIs in Subject Fields
         -

            No clear context copied over from Trello to GitHub. Problem
            space is not clear. Is it a matter of being able to assign
a single,
            unique, global identifier for an organization?
            -

            S/MIME working group drafted requirements to allow LEIs in
            S/MIME certs. Perhaps we can explore the language being
added there and see
            if it’s appropriate for TLS?
            -

            Tobias clarifies that this should not be in scope for DV.
            -

            Several others (Ryan/Trev/Corey) agreed that scope should not
            include DV.
            -

            No strong response from the group to prioritize this issue.
            -

            Conclusion: Retain, but keep in backlog. Follow-up once S/MIME
            BRs are further along.
            -

            Before moving on, Ryan asked about why CAs would be compelled
            to add more data to subject name to only add further risk
of misissuance.
            It seems most mis-issuance/incidents we see in EV certs
are related to
            issues with JOI or other organization attributes, so why
would CAs be
            motivated to increase potential for mis-issuance,
perceived or otherwise?
            -

               Corey indicated that the S/MIME BRs are standardizing on a
               subset of identifiers (for example, removing JOI) so
this could help reduce
               mis-issuance long-term)
               -

         Create Allow-List of RA Agencies used by CAs for EV JOI
         -

            Discussion: Retain in backlog.
            -

         Improve CAA logging requirements
         -

            Related to a misissuance event, more on MDSP (linked in issue).
            Seems like this issue is missing concrete update
needs/recommendations, but
            more of a broader review related to what CA’s record to
help detect/triage
            mis-issuances.
            -

            Clint indicated it seems specific language would be difficult
            to come by, but perhaps more this is about clarifying
expectations about
            logging. This could already be addressed by the updates in SC-51.
            -

            Issue framing from Trev: Ensure CAs are collecting sufficient
            data to investigate CAA errors.
            -

            Conclusion: Revisit and evaluate against the changes made in
            SC-51.
            -

      Reviewing “On Deck” Items
      -

         To be discussed on the next call (out of time).



   -

   Profile Progress Review
   -

       Deferred (out of time).



   -

   Other business:
   -

      None, next meeting on 8/11.



   -

   Conclusion


Thanks,
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220728/57249e9c/attachment-0001.html>


More information about the Validation mailing list