[cabf_validation] [EXTERNAL] Re: RFC 5280 conflict for SKI in subscriber certificates

[Aaron Gable]

If you're searching for certificates with the same key, the SKID can easily
lead you astray -- there's no requirement that two different CAs use the
same derivation function to compute the SKID from the Public Key. The SKID
is useful in CA certs because it is required to byte-for-byte match the
AKID in issued certs. I don't believe the SKID in end-entity certs serves
any purpose in the modern webpki.

I'd love to hear more from Corey and/or Ryan Sleevi on the original
motivation for this from July 2021, in case I'm missing something, but
obviously I'm convinced already :)

Aaron

On Thu, Dec 1, 2022 at 7:18 AM Paul van Brouwershaven <
Paul.vanBrouwershaven at entrust.com> wrote:

> The SKI is useful to quickly search for certificates with the same key.
>
> Is saving a few bytes a sufficient reason to 'deviate' from RFC 5280,
> where we try to get everyone to focus on RFC 5280 adherence at the same
> time?
>
> Are we sure that this would not cause any client incompatibility issues?
> Almost all certificates include the SKI today and while this might be
> fine for the major browsers, we also know that there are other
> clients/libraries that interact with web websites.
>
> Paul
>
> ------------------------------
> *From:* Hubert Chao <hchao at google.com>
> *Sent:* Thursday, December 1, 2022 15:59
> *To:* Lahtiharju, Pekka <pekka.lahtiharju at teliacompany.com>; CA/Browser
> Forum Validation SC List <validation at cabforum.org>
> *Cc:* Aaron Gable <aaron at letsencrypt.org>; Paul van Brouwershaven <
> Paul.vanBrouwershaven at entrust.com>
> *Subject:* [EXTERNAL] Re: [cabf_validation] RFC 5280 conflict for SKI in
> subscriber certificates
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
> On Thu, Dec 1, 2022 at 5:21 AM Lahtiharju, Pekka via Validation <
> validation at cabforum.org> wrote:
>
> I support Paul’s idea to change this to SHOULD. Why should we create new
> recommendations against RFC when this extension is useful in several use
> cases and almost everybody is using it now.
>
>
> Could you list out the use cases where this extension is useful for a TLS
> certificate? The discussion that Corey linked to (
> https://lists.cabforum.org/pipermail/validation/2021-July/001672.html
> <https://urldefense.com/v3/__https://lists.cabforum.org/pipermail/validation/2021-July/001672.html__;!!FJ-Y8qCqXTj2!bhb6QGSEpqEOi6JyHDzixLHA_ziEpOs6UQYkMiffRA4PH_9fFgyIiZRW3epCZqq0_V5K5pDehK6XTaH3PNBz1ibt$>)
> specifically says "... a TLS certificate [SKI] should not be needed ... ".
>
> /hubert
> *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/20221201/a1fc4135/attachment-0001.html>