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

Tue Dec 6 17:27:29 UTC 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> 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> on behalf of Ben
> Wilson via Validation <validation at cabforum.org>
> *Sent:* Friday, December 2, 2022 22:58
> *To:* CA/Browser Forum Validation SC List <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/8ddf792a/attachment.html>