[cabf_validation] Minutes of 9 May 2019

[Wayne Thayer]

Minutes from the Validation Subcommittee Meeting of 9 May 2019.

Attendees: Tim Hollebeek, Doug Beattie, Shelley Brewer, Bruce Morton,
Enrico Entschew, Frank Corday, Janet Hines, Li-Chun Chen, Rich Smith, Wayne
Thayer, Ryan Sleevi.
Agenda: SC17, 3.2.2.4.6

Minute taker was assigned and the antitrust statement was read.

SC17
Tim said that Wayne had pointed out that the motivation section of the
ballot is a bit out of date. Not planning to update it unless other changes
are required. Tim also noted that Ryan responded via email to a question
related to the history of the compromise that led to the current language.
Voting can begin on Monday.


3.2.2.4.6
Dimitris sent an email to the list asking if we could simplify the first
paragraph of 3.2.2.4.6. The copy that Dimitris sent out is quite confusing,
but it doesn’t match the BRs. Tim displayed and read the actual language:

Confirming the Applicant's control over the FQDN by confirming one of the
> following under the “/.wellknown/pki-validation" directory, or another path
> registered with IANA for the purpose of Domain Validation,
> on the Authorization Domain Name that is accessible by the CA via
> HTTP/HTTPS over an Authorized Port:
> 1. The presence of Required Website Content contained in the content of a
> file. The entire Required Website Content MUST NOT appear in the request
> used to retrieve the file or web page, or
> 2. The presence of the Request Token or Random Value contained in the
> content of a file where the Request Token or Random Value MUST NOT appear
> in the request.
> If a Random Value is used, the CA SHALL provide a Random Value unique to
> the certificate request and SHALL not use the Random Value after the longer
> of (i) 30 days or (ii) if the Applicant submitted the Certificate request,
> the timeframe permitted for reuse of validated information relevant to the
> Certificate (such as in Section 4.2.1 of these Guidelines or Section
> 11.14.3 of the EV Guidelines).
>

Tim: It’s not immediately obvious how we would simplify the sentence,
although agree that it is complex.

Ryan: Suggested that other standards have written requirements as an
ordered list. For example: “The CA first opens a connection via HTTP or
HTTPS over an Authorized Port…” Beneficial because it provides a set of
steps for implementation. Tradeoff is that specs often include “or any
other implementation that meets these requirements”. We don’t want that. We
would need to deal with the ambiguity of permitting additional steps. It is
also a different style than the rest of the BRs.

Tim: you also might end up with only two steps.

Ryan: What are the two steps? I see six.

Tim: Request file and validate file are the two steps.

Ryan: Agree. Also, are the two bullets really only one? Does anyone
remember why there are two?

Wayne: I just recall discussing in the past that they are duplicative.

Tim: If you’re doing #1, you’re also doing #2

Ryan: Does paragraph after #2 apply to both #1 and #2? It’s unclear because
#2 is the only reference to Random Value. If we combine #1 and #2 we
resolve that issue. Then we can make it an ordered sequence of steps.

Tim: Unclear why you would use a Request Token as Required Website Content.

Ryan: Request Token is bound to the request. Required Website Content is
bound to the Subscriber (should be Applicant).

Ryan: What are the essential properties that we want to maintain? What is
the reaction to describing it in a chronological sequence of events.

Doug: Chronological is good. Tim agreed.

Ryan: There is a natural chronology to the two events - get file, validate
it.

Wayne: We’re already planning a bunch of other fixes to this section, so
this is just another piece.

Tim: Actually, 3 steps. First is creating the Random Value or Request Token.

NOTE: Tim ended up documenting the following four steps:
A. Create a Request Token and/or Random Value and/or Required Website
Content
  - conditions
B. Make the request
  - subrequirements
C. Recieve the response
  - successful response
D. Validate the response
  - subrequirements

Ryan: And each step has a set of criteria to meet

Ryan: We also talked about making this an ACME method. Do we have a list of
all the issues we want fix. Ryan volunteered to draft the changes

Tim: I had also volunteered at some point to draft changes. We have a list
of recommended updates in the Validation Summit Findings document

Ryan: Do we want to support ACME and other variants? How much time is worth
spending on this if an ACME method is coming.

Wayne: We want to add the ACME variant as a new method. Meanwhile need to
fix 3.2.2.4.6

Ryan: The first part is clarity of the existing requirements. The second
part is tightening them, and the timeframe associated with that. If we
create more specificity, then some CAs will have to change. What are the
timelines for that? Is there a point at which we want to sunset 3.2.2.4.6?

Wayne: We don’t have plans to sunset 3.2.2.4.6

Tim: It’s important to fix 3.2.2.4.6.

Ryan: Are we taking about a ballot that just restructures 3.2.2.4.6?

Doug: Only need a new method if CAs aren’t doing the things we put into the
changes.

Tim: I doubt that all CAs would be doing everything we want to require.
There is no downside to a new method number.

Ryan: Consensus is on adopting a new method. A reasonable amount of time
for implementation is going to depend on the substance of the changes. A
transition to ACME will take a greater period of time. Next steps are to
produce a draft ballot that introduces a new 3.2.2.4.6 and the ACME method,
then sets a reasonable transition timeline.

Tim:Not sure I want to include ACME in the same ballot.

Wayne: Is the ACME method through the IETF process?

Ryan: Makes sense to propose two separate ballots.

Tim: Now we just need someone to find the time to draft a ballot. Tim and
Ryan both expressed motivation.

Any Other Business:
Doug said that he plans to begin voting on SC19 later today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190509/7d81becd/attachment.html>