[cabf_validation] Draft minutes of Validation call May 7, 2020

[Ryan Sleevi]

## Attendees
Aneta Wojtczak-Iwanicka, Ben Wilson, Bruce Morton, Clint Wilson, Corey
Bonnell, Daniela Hood, Dean Coclin, Dimitris Zacharopoulos, Doug Beattie,
Janet Hines, Li-Chun Chen, Niko Carpenter, Robin Alden, Shelley Brewer,
Stephen Davidson, Taconis Lewis, Tim Hollebeek, Trev Ponds-White, Wayne
Thayer, Wendy Brown

## Agenda
* Reading of the Antitrust Statement
* Agenda Bashing
* “Face to Face” planning for June
* Ballot Discussion
  * Browser Alignment Ballot
  * Disclosure of Validation Sources
* Certificate Profiles
* Any other Business
  * Redirect Codes


## “Face to Face” Planning
Tim: The validation WG has two meetings left before the F2F, with the last
one being June 4, immediately before the F2F. The CSCWG has decided to
postpone their meeting, wanted to discuss what to do for the Validation WG.

Tim: At a minimum, the plan was to do a review of what happened in the last
one-third of the year and high-level work. Wanted feedback whether we
should have a detailed working session or should we keep it high level
reviewing the work for the next third of the year, given that we’ll have a
meeting before the F2F, a meeting after the F2F, and that people aren’t
traveling.

Bruce: Not sure how much detail to go into, but seems worth going at a
high-level of all the future proposed ballots being worked on, that people
not on the validation subcommittee may be aware of. At least discuss past
and future work.

Tim: Sounds good. June 1 and June 15 meetings can remain detailed, “get
stuff done” meetings. On the week of June 8, focus on overall status,
what’s happened since China, and what priorities and goals are until the
next meeting.

## Ballot Discussion
### Browser Alignment Ballot

During the Agenda Bashing, Tim wanted to know whether parts of the Browser
Alignment Ballot were in scope of the validation WG. Ryan indicated that he
wasn’t keen to try to split that ballot into separate ballots. Mozilla’s
sent out a CA communication regarding the ballot, and the summary of the
pull request includes details about what’s changed. There are some changes
to elements such as certificate profiles and OCSP profiles that people
should review. Microsoft has indicated that they’ll be looking at an update
to their root policy based on some of the ballot text. However, nothing
really touches on the validation subcommittee, it’s more SCWG overall.

Tim: Don’t need to discuss it here, but did want to point out that this is
the Validation and Certificate Content subcommittee, and so certificate
profiles are within scope.

### Disclosure of Validation Sources

During the Agenda Bashing, Ryan wanted to take time to discuss Validation
Sources as part of ongoing work. With the proposed timeline of September,
and the likelihood of it being required via Root Program regardless, wanted
to make sure to gather feedback from CAs in the Forum.

Ryan Sleevi: Sent out notes to the mailing list, looking at requiring it by
September. If there’s no feedback, Google will take it that there’s no
impact. Looking for concrete data that CAs can share about date or impact,
either to the CA or other important activities. The process has tried to be
designed as lightweight as possible, and September still sounds reasonable
to require this. It would be great to get this through as a Ballot through
the Forum, but it can also be accomplished through Root Policy.

Bruce Morton: Not sure of the details for Entrust-Datacard, but given the
broader circumstance everyone is in, and that CAs have had concern with
pushing ballots, not sure about the impact the date would have to CAs.
Should we be focusing on the date, or focusing on the content of the ballot?

Ryan Sleevi: Not sure I see the distinction. The draft circulated shows
what we’re thinking as well as a potential date, that even in spite of the
current circumstances, Google believes is reasonable. If there's a question
on content, then that’s worth discussing, the ballot tries to set out the
goal. If there’s concerns on the date, then providing data can help inform.
Google has heard objections to the date, but without any meaningful data
that explains the challenges.

Bruce Morton: It’s probably true that the lightweight approach can be
implemented by the date, but a really thorough solution can’t be. Which
would mean CAs would need to implement things twice: first the lightweight
solution, then something more robust. It might be easier to do right, from
the start, with more time.

Ryan Sleevi: We discussed this some on the previous call, and doing it
twice is more of a feature, not a bug. The goal is about making progress,
and while the robust solution is the long-term goal, this is about taking
steps to get there. Trying to solve it all would likely be a year or
longer, which is why this lightweight process is proposed, so that we can
continue to make progress. The lightweight process was the result of
feedback from CAs, who said the full process sounds like years of work,
which is probably true.

Wayne Thayer: Want to make sure I understand what’s required for CAs.
Recollection is that CAs are required to disclose in their CPS where they
publish this information. That could be anywhere, a website, a shared
Google doc, or something similar.

Ryan Sleevi: Correct. One other aspect, on the previous call, we discussed
how what the ballot requires can be implemented either manually or through
automation. This means it doesn’t require any automated processes or new
development for CAs to comply with.

Trevoli Ponds-White: It’s not just about disclosing what the source is, but
the CA also has to disclose the content at that source, the data being
disclosed.

Wayne Thayer: So this process requires CAs to go through a list of sources
they already use, which they presumably have, clean it up and put it in a
document format, put it on a document or in a GitHub repo or the like
somewhere, then update their CPS, and finally update their process to make
sure this document is updated prior to approval for validation of a new
source. Is that correct?

Ryan Sleevi: Yeah

Wayne Thayer: Have also heard from CAs that September 1st, which is a
little less than four months away. I’ve heard some CAs say this date is a
little aggressive, and I’ve heard Ryan say that he needs data about why
this date isn’t achievable. It’s not clear, what sort of data do you need?

Ryan Sleevi: Sent an email to the list talking about this and what sort of
data that would be useful. One example is if there’s a misunderstanding by
Google, about whether or not CAs maintain lists of sources they use for
validation. In a previous discussion, there was a comment that the earliest
this could be done is in a year, because this would impact other
development activities at the CA. This raises the question of what
activities would be jeopardized. If there’s things that prevent this, then
understanding why this would represent a large scope of work, and couldn’t
be done in the time proposed, is the sort of data Google is looking for. If
this jeopardizes something else that’s good for users, that’s very useful.
If this jeopardizes a CA being able to open up a new business opportunity,
that’s not as useful, because that’s a question of prioritization, not
necessarily impact to end users.

Trevoli Ponds-White: Don’t have any data, but September 1 does feel a
little soon. Would feel better about September 31. If it gets past
November, CAs will be concerned they can’t update because it’s the end of
the year, so likely can’t go past October. It’d be nice if it was a little
later than September 1.

Tim Hollebeek: One other thing from the last discussion was you and Doug
were going to work on a paragraph overview. What was the status on that?

Ryan Sleevi: Doug sent something over, have not yet integrated it.

## Certificate Profile

Ryan Sleevi: Haven’t had any time to work on this, so it’s not been updated
since our last call. A number of people have edit access, but haven’t
reviewed those edits.

Dimitris  Zacharopoulos: Didn’t have edit access, but tried to propose
adding a column for the source of the requirement. One thing noticed was
Ryan had a requirement that was a reference to RFC 5280, not the BRs, so
wasn’t sure about that.

Ryan Sleevi: There’s discussion on the list right now about that
requirement, both in terms of RFC 5280 and the BRs. The Browser Alignment
is trying to put this clearer into the BRs to make it clearer.

Dimitris  Zacharopoulos: Was trying to compare against existing BRs, and so
things that weren’t clearly linked to the BRs, had to pay close attention
to.

Tim Hollebeek: And that’s a feature, to make sure these requirements are
all clear about where they come from.

Tim Hollebeek: Absent feedback from folks, doesn’t seem entirely useful to
go through on this call, does that sound right?

Doug Beattie: I agree, it doesn’t sound useful going through line-by-line.
We’re starting to see this is a huge project that takes forever, based on
the time folks have had. Wondering if there’s a way to make this a
non-binding appendix, which we could get pretty close to be right, let it
age a little bit, and then maybe replace and make these binding? A swap
seems huge to get documented and approved, so wasn’t sure how to make such
a big change.

Tim Hollebeek: A possibility is we could carve time out during the F2F and
say hey, we’re really serious, we’re going to do a line-by-line review for
a few hours and go in. Or one of the future validation calls.

Doug Beattie: Or like the validation summit Wayne arranged a few years ago.
Or maybe we need to split up, with some people looking at roots, or
end-entities, or CAs. Try and divide and conquer.

Trevoli Ponds-White: With the goal being to make sure we captured
everything and make a list of future changes?

Doug Beattie: Yeah. Just write the section as you think it needs to be
written. And also track future changes, for things that may not be totally
correct or accurate, but not done this round, and just come back to.

Ryan Sleevi: The only concern I had with divide and conquer was you can end
up with four different approaches written in four different styles. Part of
the goal of trying to start this was to figure out what the outline and
structure needed to look like, so that folks could go in and deep-dive. An
example is extensions and how to represent extensions, and common
extensions, how should we handle those? I think the doc has enough to
support divide and conquer if we needed to, or we could go live by line.

Tim Hollebeek: It doesn’t seem like folks think there are glaring errors
with how you’ve done it, so we could go divide and conquer, but how do we
divide it up, without having to assign people specific sections? How do we
make progress and avoid people coming back in two weeks with no one having
time?

Ryan Sleevi: I think this is a general problem with ballots. It’s difficult
when there’s fully formed ballot language to get feedback, as we were
discussing earlier. It’s also difficult to figure out what that fully
formed language should be. I think these are largely functions of the time
people have. With complete ballots, getting it to the discussion phase
forces folk to make time, but it’s great to avoid situations like that.
Probably worth just checking back in two weeks, because we can’t force
people to have time, unless we just set aside dedicated time. Difficult to
see how divide and conquer could work on the call, or on the F2F. We could
take time that would normally be on one of these calls, cancel the call,
and let people split up into groups to divide and conquer, but not sure how
those divisions would be.

Bruce Morton: What the CSCWG did, in terms of merging the two documents, is
one person had to do a bunch of work to make a proposal, and that’s maybe
what this is. Then we had a four hour meeting to block out and really go
through the document.

Ryan Sleevi: I agree, we probably need a block of time to work on things,
but we need to figure out what we’re doing there.

Tim Hollebeek: I think we need an 80% rough draft, so then we can go
through line-by-line in detail.

Doug Beattie: Divide and conquer might not be per certificate profile, but
per object in a certificate. Maybe have somebody spend some time on what a
Subject attribute is, and go through all the profiles and figure out all
the values. And do the same for extensions. And that way you don’t have to
be shifting between different profiles, but focus on one field.

Ryan Sleevi: Not sure how that process would work. Many of our requirements
are broken down per profile, so unless you’re trying to align them, that
seems different.

Doug Beattie: I agree, what I meant was someone could go through all four
profiles, but focus on something like key usage, and make sure it’s correct
for each profile. We’ve spent a lot of time on the root, but not a lot on
the other profiles.

Ryan Sleevi: Not to be a contrarian, but we haven’t really spent a lot of
time on the root. We’ve spent a lot of time discussing what we need to do.
The process of transcribing the profile is really just about finding a
block of a few hours, which is probably hard for all of us. Where things
will need more time is what are the things we want to change, what are the
future for things. The reason a block of time is needed is to also make
sure to be mapping against the RFCs, and not just the prose we have. Divide
and conquer for EKU feels like it shouldn’t take more than 10 minutes, and
splitting that into multiple groups might make it be an even bigger time
commitment. The 80% profile seems like it just takes a few hours and could
be done by one person.

Tim Hollebeek: Prediction: No one person is going to do that amount of work
in two weeks. In two weeks, we have an hour of time blocked off. I don’t
think we can go through it as a large group, but Doug’s idea of carving it
up into subject areas seems to make sense. I’m not sure how to, but if we
could divide up, does it make sense to?

Wayne Thayer: I’m somewhat skeptical about breaking things up, because
there’s probably gonna be a few people key to the discussion. It probably
makes sense to serialize, and just pick areas of the profile to work on,
tell people to show up if they care, but don’t need to. Use these meetings
to focus on things. Right now there’s a lot of changes in the CA/B Forum,
and it’s difficult to focus on any one thing. If we think profiles are the
thing, we should just focus, pick a starting point, and spend an hour every
two weeks working through.

Ryan Sleevi: I agree. It seems to make sense to serialize, and if we want
to divide by field, across profiles, we should just do that. Some fields
will be quick and some may not be, but we can just work through.

Trevoli Ponds-White: I agree, we probably don’t have enough people to need
to split up.

Tim Hollebeek: If we were making progress on some of the easier ones, it
might show this works, or give interesting data on how it needs to be
improved.

Ryan Sleevi: One challenge seems to be folks don’t know what’s “complete”,
and worth looking at closely and deciding whether they’re happy with the
approach. We’ve made progress on the call about adding columns for things
like where a requirement comes from. However, we probably want to pick
something complex to make sure people are happy with a particular approach,
before we do a lot of work for other fields. Subject names are complex and
probably controversial, but what about cRLDistributionPoints or
authorityInformationAccess? Extensions where you have a lot of repeated
nested fields. Or certificatePolicies, where we have things like qualified
certificates and explicit text notices. We should work out how we handle
some of these complex fields, and that seems useful for the next call. And
then following that, see how people feel about the approach.

Tim Hollebeek: The question is how you break things up for that.

Ryan Sleevi: The complexity is in the extensions. Start there. If you look
at a tbsCertificate, look at where the most nested complexity is.
certificatePolicies has a bunch of nesting due to qualified certificates,
but we don’t really touch on qualified certificates in the BRs. AIA is
similarly complex. Even subject names have complexity due to how you can
have multiple AVAs (AttributeTypeAndValue) within a SET and we don’t have
clear requirements about that, or about the hierarchy of name attribute
types and their order. Subjects might not be a good first step, but some of
the other extensions seem like a good start.

Tim Hollebeek: I’m sympathetic to trying the hard stuff. But can we knock
off some of the easy stuff to show we can knock off some of the easy and
medium stuff?

Ryan Sleevi: I think we’ve done that, to some extent. I think a reason we
may not be making progress is we know the hard stuff takes time, and we
haven’t really been able to make time yet.

Tim Hollebeek: It’s good if folks want to set aside time and work on this,
but still want to figure out where to start the call in two weeks, assuming
no progress has been made. We could go through them in the order they
appear in the BRs.

Wayne Thayer: Sounds good to me.

## Any Other Business
### Redirect Codes

Corey Bonnell: Niko posted on the validation list about redirect codes, the
result of SC25. I wasn’t sure if other CAs had feedback.

Tim Hollebeek: Saw Niko and Ryan responded on the list. There is some
additional useful work there, and some of those redirect codes should
probably not be used.

Corey Bonnell: I think we agree. The RFC referenced doesn’t define one of
the redirect codes, but doesn’t seem like there’s any reason it shouldn’t
be allowed. Wasn’t sure if folks felt the same way or if there was anything
we needed to clarify the language.

Ryan Sleevi: Not sure the question. Are you asking if we should put forward
a ballot, or if other CAs think it’s currently allowed?

Corey Bonnell: I think you were the one who asked for feedback from CAs on
what redirect codes should be allowed. That seems to be the first part of
discussion, and then put together a ballot, but wasn’t sure what other
people’s thoughts were.

Ryan Sleevi: Supportive of a ballot and would be willing to endorse a
ballot that restricted to 301, 302, 307, and 308; the redirect codes that
don’t require content awareness if I’m remembering the discussion.
Concerned if the proposal is pointing to the IANA registry or allowing 300,
since one of the concerns of validation WG was about making sure it doesn’t
require looking at the content.

Corey Bonnell: Seems like the path forward is to come up with some quick
ballot text and send to the validation list and discuss from there?

Ryan Sleevi: Yeah, sounds good.

Tim Hollebeek: Yeah, we support that. Removing 300 seems good. Waiting for
engineering feedback about the other redirect codes.

Wayne Thayer: I’ll add it to the Trello board to the backlog. If someone
takes that on we can move it to being in progress.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200520/34f06f2d/attachment-0001.html>