[cabf_validation] 2022-09-22 Minutes of the Validation Subcommittee

[Wayne Thayer]

*Validation Subcommittee – 22 September 2022Attendees: Aaron Poulsen
(Amazon), Andrea Holland (SecureTrust), Aneta Wojtczak-Iwanicka
(Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chris Clements
(Google), Clint Wilson (Apple), Corey Bonnell (Digicert), Corey Rasmussen
(OATI), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft),
Joanna Fox (TrustCor Systems), Johnny Reading (GoDaddy), Kiran Tummala
(Microsoft), Martijn Katerbarg (Sectigo), Michelle Coon (OATI), Rebecca
Kelley (Apple), Ryan Dickson (Google), Tim Hollebeek (Digicert), Tobias
Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer
(Fastly)Corey Bonnell read the antitrust statement.The minutes from the
8-September meeting were approved.Agenda - Certificate profiles ballot-
Review of the BRs for the use of the term “Applicant” 1. Review of PR that
adds specification for EV attributes -
https://github.com/cabforum/servercert/pull/391
<https://github.com/cabforum/servercert/pull/391>Corey said that without
specifying EV specific attributes, the encoding isn’t specified, so he
added a section containing those attributes. it does not enforce ordering,
but does specify encoding and maximum length.Tim Hollebeek said that this
is a big improvement, but the relative ordering requirement in the sentence
above the table is subtleCorey said that he and Tim will work together to
improve the clarity of the ordering requirement. 1. Integrating Ryan
Sleevi’s table improvementsCorey said that this work has been merged in. It
would be helpful if some members could review the section
numbering.Dimitris Zacharopoulos asked if there was a plan to rebase the
profiles branch to synch with the master branch.Corey said that he is
planning to do that as the final step before the discussion period begins.
1. Review of the BRs for use of the defined terms Applicant and Applicant
RepresentativeCorey said we left off at section 3.2.2.4 at the last
meeting, so we’ll begin there.Corey said that the term ‘ownership’ is used
in addition to ‘control’, which may be a holdover from old methods.Tim
asked if we have really removed all the methods that rely on ownership
instead of control. Ownership is better than control if you can prove
it.Trevoli Ponds-White asked if an Applicant is an Applicant if they also
hold a certificate from the CA, making them a Subscriber.Tim and Clint said
that you can be both at the same time depending on the context.Trev asked
about the Subscriber Agreement - are you an Applicant if you have already
agreed to the CA’s Subscriber Agreement? This also applies to renewals -
are you an Applicant or a Subscriber?Tim said that it makes no sense to
force the Subscriber/Applicant to agree again.Clint said that the term
Applicant applies to the collection and verification of data during the
certificate request process. Does this cause a conflict?Trev asked if an
Applicant is only someone who has no relationship with the CA? This is
bizarre, for example, for someone using ACME.Tim said that the BRs are more
concerned with whether you have gone through the application process or
not. Maybe there should be different rules for recertification. Separating
technical requirements from business/legal requirements might make
automation easier.Trev agreed. Applicant is also tied up with business
processes.Corey restated that the idea is to separate business and
technical application requirements.Tim said that it is worth
considering.Clint said that refining the problem statement might help us to
determine if separating processes is a good idea.Looking at the top of page
36, Corey said that the use of the term Applicant is scoped to a single
request: “Completed validations of Applicant authority may be valid for the
issuance of multiple Certificates over time”Viewing the language “For
purposes of domain validation, the term Applicant includes the Applicant’s
Parent Company, Subsidiary Company, or Affiliate.“, Corey asked about the
definition of “Affiliate” and TIm read the definition from the BRs. The
definition infers a close legal relationship. 3.2.2.4.2 states “Confirming
the Applicant’s control over the FQDN…”Corey said that Applicant is used in
the definition of “Random Value”.TIm said that this method sometimes
confirms ownership and sometimes confirms control, so this method should
refer to both.Wayne Thayer said that the term ‘ownership’ is not
appropriate for domain names.Corey proposed replacing “ownership” with “is
the Registrant”.3.2.2.4.3 is no longer in use.Ben Wilson asked if thi
section should be removed.Tim said that we should add this to a cleanup
ballotCorey said that he is working on a cleanup ballot3.2.2.4.4, 5, and 6
methods use the term in the opening sentence. It was agreed to skip over
those uses as redundant.3.2.2.4.7 states “if the Applicant submitted the
Certificate request…”Tim asked what that means? Is the alternative that the
Applicant Representative submits the request? This language might be
wrong.Corey said that regardless of the existence of an Applicant
Representative, the request comes from the Applicant.Trev referenced ballot
190 for this language.Corey said that he would follow up on this
issue.Corey said that 3.2.2.4.8 doesn’t make any unique use of
“Applicant”.Tim said that 3.2.2.4.12 is a case where ownership is
confirmed.Nothing unique in the use of “Applicant” was discussed when
reviewing methods 13-17.For 3.2.2.4.18, Corey asked about random value
freshnessCorey said that method 18 shares security properties with method
7, but 18 does not include the freshness language from method 7. We need to
look into this because both methods share the same security properties.Tim
mentioned a ballot from a few years ago that would distinguish values that
require freshness from values that are secrets.Corey said that we can
remove the effective dates from methods 18 and 19.No concerns were noted
with method 20.Tim suggested skipping the IP address section 3.2.2.5 when
we continue the review at the next call.Meeting adjourned.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220924/da72005a/attachment-0001.html>