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

Tue Dec 6 17:50:11 UTC 2022

That would be fine in context with the rest of the minutes.

Thanks,

Paul

________________________________
From: Ben Wilson <bwilson at mozilla.com>
Sent: Tuesday, December 6, 2022 6:27:29 PM
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>
Cc: CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: Re: [EXTERNAL] [cabf_validation] Draft Minutes of Discussions on December 1, 2022

Would there be any objection if the minutes stated, "A straw poll was conducted on whether the language should say "SHOULD NOT" or "MAY".  Most favored making it a "MAY"." ?
Thanks,
Ben

On Tue, Dec 6, 2022 at 7:45 AM Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com<mailto:Paul.vanBrouwershaven at entrust.com>> wrote:
> A straw poll was conducted. Most favored making it a "MAY" and diverging from RFC 5280’s “SHOULD”.
The poll was asking SHOULD NOT <> MAY, so we did not ask if people agree to diverge from RFC 5280 or not, the only option in this poll was to diverge from the standard.

Can we clarify this in the minutes?

________________________________
From: Validation <validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org>> on behalf of Ben Wilson via Validation <validation at cabforum.org<mailto:validation at cabforum.org>>
Sent: Friday, December 2, 2022 22:58
To: CA/Browser Forum Validation SC List <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: [EXTERNAL] [cabf_validation] Draft Minutes of Discussions on December 1, 2022

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________

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://urldefense.com/v3/__https://github.com/cabforum/servercert/pull/406__;!!FJ-Y8qCqXTj2!fNBUI2O2BopvZap8XVLC4GIIG2sFUW7ZwKcJUaY0dGohU1X6E4B_QDMo962Bnr-B9toy1toz3E7nqYswwaCbKLw8Aum41J5x$>.  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<https://urldefense.com/v3/__https://lists.cabforum.org/pipermail/validation/2022-November/001832.html__;!!FJ-Y8qCqXTj2!fNBUI2O2BopvZap8XVLC4GIIG2sFUW7ZwKcJUaY0dGohU1X6E4B_QDMo962Bnr-B9toy1toz3E7nqYswwaCbKLw8Ao-rWkuz$>

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.

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221206/da802257/attachment-0001.html>