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

[Ryan Dickson]

Meeting Date: May 4, 2023

Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Ben Wilson
(Mozilla), Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson
(Apple), Corey Bonnell (DigiCert), Daryn Wright (GoDaddy), Doug Beattie
(GlobalSign), Dustin Hollenback (Microsoft), Eva Vansteenberge
(GlobalSign), Georgy Sebastian (Amazon), Kiran Tummala (Microsoft), Li-Chun
Chen (Chunghwa Telecom), Martijn Katerbarg (Sectigo), Michael Slaughter
(Amazon), Nargis Mannan (VikingCloud), Pedro Fuentes (OISTE Foundation),
Rebecca Kelley (Apple), Rollin Yu (TrustAsia Technologies, Inc.), Ryan
Dickson (Google), Thomas Zermeno (SSL.com), Tim Hollebeek (DigiCert),
Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne
Thayer (Fastly)

Discussion:



   -

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



   -

   Approving previous meeting minutes:
   -

      Doug shared the previous meeting minutes yesterday (May 3rd).
      -

      A few people did not receive them, possibly something going on with
      the mail server.
      -

      The archive appears to have them listed.
      -

      We will approve them at the subsequent meeting to give participants
      time to review.



   -

   Corey summarized the meeting’s planned agenda
   -

      Finish discussion of the ACME certificate issuance flow
      -

      Discuss any other issuance flows that haven’t already been discussed
      (none known)
      -

      Discuss delegation of domain validation (as was identified and
      briefly discussed on the April 6th call)
      -

      Discussion from Pedro re: EVGs
      -

      [No additional items]



   -

   ACME Certificate Issuance Workflow
   -

      Corey shared screen (presenting this
      <https://docs.google.com/document/d/1H_DZ_ZLhOGrHz-GAWkJtHDE-7_7-jn8Q7Tx3xfb20Z4/edit>
      link)
      -

      Summarized where we stopped last time (approximately Step 6, as
      listed) - and how third party services can participate in the domain
      validation process (i.e., 3rd party provider populates random
values to TXT
      records on the applicant’s behalf).
      -

      Aaron pointed out that the CNAME delegation is useful for the use
      case of migrating from one hosting provider to another because
you can get
      your upcoming hosting provider to issue a certificate for your
name before
      you have actually transferred your hosting over to them by delegating a
      subdomain to them (i.e., prevent interruption of business).
      -

      Corey also described an associated IETF draft
      <https://datatracker.ietf.org/doc/draft-todo-chariton-dns-account-01/02/>related
      to using multiple service providers to get certificates for a domain.
      -

      Tim described a scenario where a website operator is running a large
      website with numerous renewals happening - and how finding a
window to move
      the ACME challenge delegation over to a new provider adds
complexity. That
      use case would be helped by having multiple ACME challenge URLs.
      -

      Aaron described what might be a common scenario for the type of
      transition described earlier (going from a “plain” hosting provider to
      something more complex like a CDN).
      -

      Wayne shared another example. He indicated that Fastly has customers
      that either have a multi-CDN strategy - and they want to integrate with
      more than one CDN and both require certs for the domain, or, they have a
      domain where some subdomains are pointed to a CDN and others aren’t and
      they need the flexibility to support multiple validations
against multiple
      CAs or from multiple providers.
      -

      Discussion concluded that the IETF draft aligns well with the
      existing Method 7 text.
      -

         The authors should consider changing the draft name to “dns-02”
         rather than dns-account-01.
         -

      [Group continued walking through the steps.]
      -

         Step 9
         -

            Aaron clarified the ACME server isn’t just checking the random
            value in the subdomain, it’s looking for a concatenation
of two values
            (Random value + a value derived from the subscriber's ACME
account key
            described earlier in the doc.) This isn’t required per the
BRs, but by RFC
            8555. All various ACME flows look for this combined value
that provides
            some extra transport security over who is presenting the
random value.
            Note: Correctly computing the concatenated value is
something ISRG often
            sees ACME clients struggle with.
            -

         Step 11
         -

            CSR: RFC requires public key + SANs requested.
            -

            Aaron clarified, the CSR can also sometimes serve an additional
            purpose, specifying an EKU (like clientAuth) or other
custom requests (like
            including the ‘must-staple’ extension).



   -

   Step 13
   -

      Clarification: Technically step 13 can download multiple chains, for
      example, to consider cross signs. ACME protocol can expose these and let
      the client choose between them.
      -

   Closing comment from Clint: earlier, we mentioned that the CSR offered a
   mechanism for customizing requests. To some extent, External Account
   Binding (EAB) also offers the same, because we can tie requests to a
   specific customer account where other configurations might be specified).



   -

   Delegation
   -

      Last time we spoke about applicants setting up a CNAME alias to
      delegate parts of the domain validation process.
      -

      Many ways to do this, to include a CNAME pointed to…
      -

         a new hosting provider.
         -

         a third party validation service (example
         <https://github.com/joohoi/acme-dns> linked in doc).
         -

         the CA itself, which might be offering a validation service.
         -

         a cloud service provider (CSP)
         -

      Historically, conversations around which of these methods are allowed
      focused on the legal structure of the CA and the validation
service(s) that
      it might offer.
      -

      Previous discussion on CSPs that offer CA services and these
      validation services.
      -

         CSP contains domain zone, can create records
         -

      Differing opinions on what’s allowed or disallowed.
      -

      Previous conversation in 2018 determined it is allowed. BRs are open
      ended on where the applicant can have a relationship with their providers
      to complete domain validation.
      -

      Defining a clear set of requirements that promote automation and
      security are a good outcome of this discussion.
      -

      Doug: It would be good to get guidance and agreement on the entities
      that can host CNAME’d locations. Prior guidance from root
programs was that
      CAs must not do this.
      -

      But, why can’t CAs do this?
      -

         Previous argument: the BRs state the applicant has to explicitly
         post the random value. This statement could be updated, and we could
         improve language such that we do not introduce additional risk.
         -

      Tim: Some concern exists, for example, using the same URL for
      everyone - and all customers delegate to that same URL, that’ll end very
      badly for you. That’s one security risk we might think to address.
      -

      Doug: account should be delegated to a domain name, not a specific CA
      account. (preclude the option for takeover attacks)
      -

      Trev: As a CA, you have to validate correctly that someone controls
      the domain. It seems like that solves concerns re: how that’s
set up? Do we
      need to define them or define the goal?
      -

      Tim: CA is only required to follow an acceptable method. Pointing
      everyone to the same URL is compliant with the requirements. It shouldn’t
      be, but it is.
      -

      Wayne: I think a lot of the work we’ve done to improve the validation
      methods has made them more prescriptive so there aren’t these
ways to make
      mistakes. Clarifying this is a great candidate and easy opportunity for
      improvement.
      -

      Aaron: This problem is not inherent to the CA also being the CDN or
      hosting provider. It is totally possible that there could be a
third-party
      service that says “hey, use me, I’m like certbot but with a web interface
      and I’m easy to use — just delegate your ACME challenge CNAME to
this value
      and I’ll complete DCV process for you” — that service could
direct everyone
      to delegate to a subdomain of the same domain and then anyone could get
      certificates for names anyone else is using. The service could also issue
      certificates for any domain used by any one of its customers. In the case
      that the CA is the provider, this community has influence over those
      services.
      -

         Tim: we should think about things we can do for the more general
         case where it’s not a regulated CA that’s doing this.
         -

         Trev: so much of what we’ve discussed is things that people will
         just choose to do. Customers choose their providers. If they use a
         weird/sketchy third-party service, is that this community’s
problem? Where
         do we draw the line?
         -

         Aaron: I agree. My hypothetical example was just to make sure my
         understanding of why we’re thinking about this (such that the
CA case can’t
         be any less secure than one of the described microservices).
         -

         Slaughter: concern about being too prescriptive. Applicant or
         domain owner would be a threat actor, not the CA. BRs are about CA
         behavior. Applicant’s should be free to make terrible decisions and we
         should recognize that CAs can’t control this.
         -

         Trev: Don’t make prescriptive rules that we can’t enforce or that
         can’t be assessed or checked. We can’t do that for applicants.
         -

      Corey: BRs could define characteristics if a CA ran a validation
      service. Even if we have requirements for CAs, they’ll be incomplete
      (because of random services). Not arguing there’s no value in defining
      requirements, just highlighting.
      -

         Tim - perhaps it should be a “should” requirement. CAs should
         think about these things and consider appropriate
mitigations. We can’t
         stop this problem completely. I’m skeptical that CAs are
constrained and
         others aren’t. (because CAs are audited and trusted,
third-parties are not).
         -

      Trev: We should aim to strike a balance … make something that
      achieves the underlying security goals, but is also easy for
people to use.
      Use the secure things, not some insecure service that is just easy to use.
      -

      Next steps:
      -

         Next meeting - discuss whether it’s beneficial to have
         requirements related to this initiative
         -

         From there, define next steps to possibly include...
         -

            Modify the definition of random value…or,
            -

            Modify the definition of random value + prescribe specific
            language for minimal security considerations.



   -

   Pedro's discussion re: EVGs:
   -

      Current situation:
      -

         EVGs mandate disclosure of registration and incorporation agencies
         -

         By omitting the disclosure of QGIS, strict reading is that we
         disallow use of those sources during validation
         -

         Not all registration/incorporate agencies facilitate means for
         verification, so it’s required to use QGIS to retrieve the
verification
         information.
         -

      Problems:
      -

         Using QGIS is not explicitly allowed, so it would imply
         mis-issuances when used
         -

         Using QGIS can lead to errors about the JOI, as the QGIS can group
         information about subscribers registered in different JOI
levels, and CAs
         must properly associate the JOI to the subscriber and not the
verification
         source.
         -

      Pedro is concerned about using an approach that is not explicitly
      allowed.
      -

      Pedo presents a proposed redline that allows use of QGIS.
      -

      Discussion:
      -

         [Participants indicated the update sounds reasonable.]
         -

         Implementation path: Could roll into 3647 reformat update, but
         Pedro cited he was uncomfortable with current practices given current
         wording.
         -

      Next Steps:
      -

         Pedro to raise at SCWG (collect more feedback and to help identify
         ordering of the related ballot compared to the 3647 update).
         -

      No additional comments
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230511/71306c15/attachment-0001.html>