[cabf_validation] 2023-05-18 Minutes of the Validation Subcommittee [DRAFT]

Chris Clements cclements at google.com
Fri May 19 19:06:50 UTC 2023

Meeting Date: May 18, 2023

Attendees: Aaron Poulsen (Amazon), Aneta Wojtczak-Iwanicka (Microsoft), Ben
Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Chris
Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Daryn
Wright (GoDaddy), Dimitris Zacharopoulos (HARICA), Dustin Hollenback
(Microsoft), Eva Vansteenberge (GlobalSign), Inigo Barreira (Sectigo),
Johnny Reading (GoDaddy), Joseph Ramm (OATI), Luis Cervantes (GoDaddy),
Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy),
Rollin Yu (TrustAsia Technologies, Inc.), Ryan Dickson (Google), Tobias
Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer



   Corey Bonnell greeted participants, started the recording, read the
   attendance (above), and read the “note well.”


   Approving previous meeting minutes:

      April 20th meeting minutes were approved

      May 4th meeting minutes were approved


   Corey summarized the meeting’s planned agenda:

      Check-in on multi-perspective domain validation work

      F2F agenda:

         Delegation of domain validation to other parties

         Other topics

      Should we meet on June 1st (week before F2F)?


   Check-in on multi-perspective domain validation work:

      The Chrome Root Program is trying to wrap up suggested comments in a
      doc hopefully by tomorrow.

      Ryan Dickson will be transitioning the proposed draft language into
      GitHub, such that it can be circulated more broadly with this group.

      This is for collecting more feedback and more perspective to help
      steer us down the path of a ballot.


   F2F agenda:

      Delegation of domain validation to other parties has been a hot topic
      and first and foremost in Corey’s mind.

      Corey asked if others had topics they would like to propose. None
      were offered.

      We have 1.5 hours scheduled for Thursday morning.

         Corey asked if an hour and a half was too much for this one topic
         or if we see this as a discussion that would take
significantly longer than
         an hour. His initial thinking was that an hour and a half was okay.

         Ben Wilson asked if we have looked back at past face-to-face
         discussion items that were not fully discussed and may need additional
         conversation or if this one topic is indeed all we have to discuss.

         Corey mentioned not having the list that was circulated previously
         in front of him, but he thought the next steps were clear and did not
         recall if we actually had any outstanding discussion.

      Corey does recall there being some discussion around some
      improvements to the subscriber language.

         Ben stated that was correct and that he and Dustin Hollenback were
         talking about it before this call. They were working on it
until about a
         month ago and then got busy with other priorities. They need
to check and
         see if there is something they can present for discussion.

         Corey will allocate some time for Ben and Dustin to present those

      Wayne Thayer asked to revisit the first topic of delegation of domain
      validation. He thinks the scope of that conversation could determine how
      much time we talk about it. If we are just talking about what are the
      conditions under which it’s okay to delegate domain validation, that’s
      pretty easily scoped or pretty narrowly scoped. He likes to think of the
      topic from the broader picture of how we make the whole process more
      automated, which could turn into a much bigger discussion and opens more
      opportunities for brainstorming.

         Trevoli Ponds-White suggested if we want to scope the conversation
         down to the clear desire by people to automate certificates
then we should
         frame it as such. It would be good to steer the discussion.
For example if
         we want to discuss when is it okay to delegate, we’re actually saying
         domain validation has to be delegated and these are the
situations that
         we’ve agreed to as a group and people can comment from there.

         Corey said it sounds like there is a desire to widen the topic a
         bit. In conversation weeks ago we were going to look at and
determine next
         steps on how we wanted to improve the Baseline Requirements
and whether or
         not CAs need some guard rails around delegation and domain
validation, or
         we could just have very surgical change to the BRs, which
would mainly just
         be changing the definition of random value.

         Trev clarified a desire to present our conclusions and allow
         people to provide feedback. Not start another discussion that
we’ve already
         had from scratch.

         Wayne stated on the broader issue of how to automate domain
         validation, they have not really reached any conclusions to present.

         Clint Wilson believes we’ve agreed on a very high level, but we
         haven’t done any of the granular “how” does domain delegation
happen, and
         how does it happen securely. We’ve agreed with the
overarching “this is a
         topic that we want to talk about” but all of the work is
still yet to be

         Trev stressed the importance of having a goal for the discussion
         and that we reach that goal. We should try to present
conclusions, similar
         to the guard rail concept mentioned by Corey. We should present a
         conclusion and then discuss it because that is easier than
saying “here’s
         some thoughts, what do people think?”

            For example one of the conclusions could be you have to
            determine the level of rules that you want to have around
this, you can’t
            constrain subscribers from going to other service
providers and constrain
            what they do. You can only constrain the CAs, so it
doesn't make sense to
            constrain the CAs so much that what they are offering is
more difficult
            than what a subscriber could get from someone that's not a CA.

         Wayne proposed the prompt that it is okay for domain validation to
         occur without the subscribers involvement.

            Corey agreed this is good framing. It also provides us the
            opportunity to give more context and background on some of
the discussion
            that we’ve had in this group over the past couple of
months that the wider
            group may not be familiar with. We can lay out the
rationale and then open
            up the floor to any conversation.

         Trev wanted to add to what Wayne said, the subscriber does not
         directly need to be involved, but rather they can opt-in.
It’s not that the
         subscriber is not involved and validation happens without
their knowledge,
         but rather they can opt-into it.

            Corey agreed that it is useful clarification and this probably
            needs to be discussed but in his mind there should be an
explicit initial
            action undertaken by the applicant to allow that delegation.

            Ben suggested they could agree to it in the Subscriber

         Corey will create some slides to help stimulate conversation at
         the face-to-face.

      Trev asked what we want to close out in the face-to-face conversation.

         Corey thinks coming out with concrete language changes to the
         Baseline Requirements might be a bit of a stretch. At least having a
         direction on what guardrails the CA needs to have, if any, in terms of
         performing delegation.

         Trev suggested a general agreement that opt-in is okay and fewer
         guard rails makes the most rational sense because anything else is
         unenforceable. These two seem like blockers before we can change the
         Baseline Requirements.

         Corey said there was general consensus on previous calls.

         Wayne suggested the tension is when you say, okay, the logical
         conclusion of this is that you don’t have to perform domain validation
         every X days. You are essentially saying you can do it once and with
         certain provisions you’re done. When you say it that way, a
lot of people
         are going to say “no, we can’t do that”. To foster
discussion, what does it
         mean to say that you can assent to automated renewals?

         Corey agreed that phrasing is important. He does not see the
         delegation as an allowance for the CA to skip the domain
validation check.
         It was just that they would be performing all the actions,
but additionally
         the CA would potentially be publishing the random value. They
would still
         be performing the same mechanical steps that are required for domain
         validation (DNS lookups etc.) but it sounds like there might
be different
         interpretations of this.

         Wayne clarified that once you say an applicant or subscriber can
         agree to the use of their domain on a permanent basis until
they opt-out.
         This has implications, such as why is the CA creating a
random value, why
         are they not checking CNAME? At some level we’re saying a lot
of what CAs
         do during a renewal scenario today doesn't make a lot of
sense. It’s easy
         to say, “oh yea, that’s fine” but once you start thinking through the
         implications, some people may become uncomfortable.

         Michael Slaughter suggested thinking about the topic as two
         separate questions:


   Does this concept of delegated domain validation fit within the current
   construct of the Baseline Requirements as is today with maybe a few tweaks?
   Is this allowable?

   Is there a way to make the Baseline Requirements better align with this
   concept of domain delegation with changes to some of the fundamental ways
   we look at domain validation in this new way? We don’t have to answer both
   questions to make progress in the exact same way.


   Michael clarified he thinks there is room for targeted surgical changes
   to the BRs to make this concept of delegated domain validation more clearly
   allowable and perhaps add additional guardrails where it makes sense. The
   thoughts provided by Wayne lead us into some of the deeper fundamental
   questions and ways we look at domain validation, which is fascinating, but
   these can be explored on two different threads.

   Wayne agreed. The conversation about tactically making changes to
   clarify what's allowed with CNAME validation is relatively easy and we
   should have that conversation and fix that. There is a more interesting
   conversation to be had, but this can be treated as two separate threads.

   Corey asked if the group wants to first tackle the surgical approach
   versus the higher-level discussion with the potentially larger changes. Do
   we want to have the wider discussion or the more surgical discussion?

   Wayne believes the surgical approach is pretty well understood and we
   just need to write a ballot.

   Michale suggested we state the conclusion upfront to the group and say
   this is what the validation subcommittee discussed and this is what we
   concluded and let the group provide feedback or raise points that were not
   previously discussed, and then move on to the larger discussion that is
   potentially more interesting.

   Corey suggested we still need to discuss CA guardrails and we can do
   that in the context of the face-to-face.


   The topic around Subscriber Agreements from Ben and Dustin will go first
   and then we’ll discuss delegated domain validation.

      We can plan for 15-20 minutes for this topic.


   Should we meet on June 1st (week before F2F)?

      Historically we skip the week before so that everyone has time to
      prepare for potential travel.

      Corey asked if there were any objections with canceling the next

         No objections.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230519/e0b2e39c/attachment-0001.html>

More information about the Validation mailing list