[cabf_validation] Draft Minutes of Discussions on December 1, 2022

[Ben Wilson]

All,

Here are draft minutes from my notes for the Validation subcommittee
meeting held Dec. 1, 2022.

Ben


*Meeting of December 1, 2022*

*Antitrust Statement:*  Corey Bonnell read the Antitrust Statement

*Attendance:*  Ben Wilson, Thomas Zermeno, Martijn Katerbarg, Aneta
Wojtczak, Paul van Brouwershaven, Wayne Thayer, Pekka Lahtiharju, Chris
Clements, Dimitris Zacharopoulos, Johnny Reading, Corey Rasmussen, Tim
Hollebeek, Clint Wilson, Bruce Morton, Janet Hines, Corey Bonnell, Tyler
Myers, Michelle Coon, Rebecca Kelley, Andrea Holland, Rollin Yu, Aaron
Poulsen, Michael Slaughter, Stephen Davidson, Tobias Josefowitz, Nargis
Mannan, Joe Ramm, Trevoli Ponds-White

*Minutes:  *Minutes of previous meeting Nov. 17th were recently distributed
on the management list.  Minutes of the Validation sub-group from the F2F
meeting should be approved within this sub-group. They will be approved
during the next meeting of this sub-group.

*Review of Agenda Topics*

1-      Certificate Profiles ballot

a.       Subject Key Identifiers

b.       CPS qualifiers

2-      Continued discussion of “Applicant” and “Applicant Representative”,
resuming in BR section 9.6.3

*Certificate Profiles Ballot*

Corey Bonnell reviewed PR #406 in GitHub
<https://github.com/cabforum/servercert/pull/406>.  It brings the profiles
ballot up to date with ballots approved from the last couple of years.  Changes
are extensive.  There were no objections to merging the PR into the
Profiles branch on GitHub. Corey will merge it.

*Subject Key Identifiers (SKIs)*

Paul Van Brouwershaven has introduced the topic of SKIs by email – “Section
7.1.2.7.6 (Subscriber Certificate Extensions) of the new certificate
profiles state that the inclusion of the subjectKeyIdentifier is NOT
RECOMMENDED, this contradicts section 4.2.1.2 (Subject Key Identifier) of
RFC 5280 that states that entity certificates SHOULD include the SKI”.
https://lists.cabforum.org/pipermail/validation/2022-November/001832.html

RFC 5280 says that end entity certificates SHOULD include the SKI, whereas
the currently drafted profiles ballot says it is not recommended - because
it is not particularly relevant and presents additional bytes in the
certificate, and it contradicts RFC 5280.

The rationale behind the “SHOULD” apparently was that it could help to
quickly identify those certificates that are using the same key.  However,
in RFC 5280 there are two methods to calculate the SKI. So there may be no
guarantee.  Without the SKI, you would need to separately calculate the
SKI. Some applications might use the SKI for some purpose.  We should stay
as close to RFC 5280 as possible.  There isn’t a good enough reason to
deviate from RFC 5280.

Tim H. – We should think long term about having one method to calculate the
SKI.  We should deviate from RFC 5280.

Dimitris – supports Paul’s position, although we use the SKI in crt.sh,
Censys, and other logs.

Paul – I prefer to keep in line with RFC 5280 if we can. If we weaken it to
a “MAY,” then at least we’re not saying “SHOULD NOT”.

Dimitris – unless there are strong reasons to diverge, then we should stick
with RFC 5280.

Tim – I have strong feelings that the “SHOULD” in RFC5280 is antiquated and
that it would be a step backward.

Corey B. - Across the ecosystem, SKI cannot be used as the identifier.

A straw poll was conducted. Most favored making it a "MAY" and diverging
from RFC 5280’s “SHOULD”.

*CPS Qualifiers *

Paul – it is much easier to find the relevant documentation when there is a
URL for the CPS in the certificate. This is the way to find the relevant
CPS associated with the certificate. Details in the CPS matter. It makes it
easier for relying parties.

Tim – unless we’re mandating it, it is not helpful across the ecosystem.

Clint – For most CAs, the CPS pointer just goes to the legal repository and
in the certificate, it provides no value.  It is a pointer to nothing and
is not helpful. There is way too much complexity in CA repositories.  Making
it “not recommended” is the correct approach.

Ben – we just want to point people in the right direction. If I want to
look at the CPS for a certificate, then do I just go to a large
organization’s website?  Will I be able to find the CPS that way? If I have
to use a search engine, will I find the repository?

Dimitris – it may be difficult to find, unless I have the CPS URI – then I
can just go there.  Researchers use this information.

Paul – if the link isn’t working, it should be considered a mis-issuance.

Tim – if the website is down, the URL is still correct.

Corey – if the CA issues it with a URL that it cannot control, that might
be mis-issuance.

Tim – that would be misissuance.

Trev – researchers will still be able to navigate to this information and
determine the applicable CP and CPS.

Tim – researchers have difficulty finding CPSes.

Clint – if someone goes to the legal repository, they still must figure out
which CPS applies to a given certificate.  Relying parties will have
difficulty navigating the legal repositories.

Paul – it helps users identify useful information

Bruce – we need to provide a way to tell relying parties about our policies
and practices

Paul – it is for the users who are sophisticated enough to find it

Tim – do we have to pay an internet tax in bytes for these URLs in
certificates?

Paul – we have something today that works, at least for those users who are
aware of it.

Tim – let’s increase use and reliance on the CCADB for identifying CPSes.

Wayne – We are debating something not that relevant to getting the profiles
ballot out.  Let’s move this forward.  Why can’t we leave as a “MAY”?  Has
a compromise been suggested with allowing it in the intermediate CA?

Paul – doing it in the ICA will at least provide people with some way to
locate a CA’s document repository.  Paul will work on a pull request.

*Meeting adjourned.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221202/0b66751d/attachment.html>