[cabf_validation] Minutes of the August 29, 2019 Validation Subcommittee Call

[Wayne Thayer]

Attendees: Tim Hollebeek, Tim Shirley, Ryan Sleevi, Dean Coclin, Shelley
Brewer, Arno Fiedler, Bruce Morton, Li-Chun Chen, Daniela Hood, Joanna Fox,
Janet Hines

1. LEI Ballot
Tim: Ryan had a bunch of comments.
Ryan: worth it to rehash here. There is definitional stuff that’s not
essential.
Ryan: Two main issues: If you have an organization, how do you determine
the org is associated with the LEI? Second, do we have a clear value
proposition? There is enough info in existing certs for a relying party to
map it to an LEI.
Tim: Start with second question. We can get the GLEIF people to share their
motivations.
Ryan: They want user to be able to click on LEI in certificate UI and
access the information they maintain. But that’s not what we’re discussing
- that would be a URL.
Tim; Browser UI considerations are completely out of scope of the Forum.
Certs already contain a lot of info the browsers don’t display in their
UIs. Better to focus on ability of CAs to validate info put in a
certificate.
Ryan: Is adding more info to a cert good or bad? More info can reduce
agility. Second, there isn’t additional work from the CA. You can use the
info in the certificate to find a unique mapping to an LEI. So is the extra
info in the certificate useful?
Tim: without LEI in the relying parties must properly perform the matching,
and there is nuance to it. I would like to let the GLEIF folks explain why
it’s valuable rather than relying on second hand characterizations of their
motivations.
Ryan: agree that we want to hear from GLEIF. However, in all the scenarios
that have been presented, the relying party is going to go look up the
organization in their database. That’s not much different than using the
existing info to perform the lookup.
Ryan: the concern is that there is a cost in terms of agility, without a
clearly defined benefit. I’d like to know how the GLEIF folks envision this
information being used by actual relying parties.
Tim: Direct match again identity is one example. Let’s get the GLEIF folks
into the discussion. I’ll ping them, perhaps get them on the next call.
Dean: Stephan Wolf would be an invited guest to the Validation WG.
Ryan: They can also respond on the questions list or on GitHub.

2. Method 6 Ballot
Doug isn’t on the call. No discussion.

3. Certificate Lifetime Ballot
Ryan: The reasons that DigiCert provided for certain dates that are
difficult are incredibly valuable. If others have data on good things that
will be impacted by the timing of this ballot, now is the time to bring
them up.
Tim: If this is really part of a multi-stage process, it would be good to
start discussing later stage timing now so that people can start planning
and justifying now.
Ryan: I totally agree. Gerv shared the desire to further reduce 2 years
ago. I want to get to a point where we can further reduce, but I don’t have
a timeline. I want to get the current lifetime down to address the pain
felt from recent incidents. I also see major challenges to further
reductions. I see further reductions of lifetimes as a longer term goal.
Reducing data reuse is another thing. We can and should reduce domain
validation intervals further in the future. The reduction to 1-year does
not require automation or some of the bigger changes that shorter lifetimes
will require.
Tim: One thing I’ve been confused about - you often speak of challenges to
CAs, but it’s the subscribers who have the problems.
Ryan: I’m talking about 2 things. More frequent OV/EV org validation is an
issue for many CAs. Challenges to subscribers are more about reductions
below one year. Subscribers that are challenged by replacing a cert once a
year are also a problem for ecosystem agility. I’m not sympathetic to that.
SHA-1 deprecation, serial number entropy, underscore issues show the need
for subscribers to be able to make changes.
Tim: thank you. Any other comments?

4. Any Other Business
No other business.

Call ended.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190829/ab242f59/attachment-0001.html>