[cabf_validation] RFC 5280 conflict for SKI in subscriber certificates

[Lahtiharju, Pekka]

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.

Pekka
Telia Company

From: Validation <validation-bounces at cabforum.org> On Behalf Of Aaron Gable via Validation
Sent: torstai 1. joulukuuta 2022 3.11
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>; CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: Re: [cabf_validation] RFC 5280 conflict for SKI in subscriber certificates

"SHOULD" means<https://datatracker.ietf.org/doc/html/rfc2119#section-3> that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.". In the profiles draft, the subjectKeyIdentifier is profiled as a MUST for all CA certificates, and only as NOT RECOMMENDED for end-entity certificates.

In my opinion, the better way to resolve this discrepancy between RFC 5280 and the BRs is to document in Section 7.1.2.11.4 why this field is not useful for end-entity certs: namely, that no other certificate will ever contain the same value in its Authority Key Identifier extension, so it serves little-to-no purpose and simply increases the size of the certificate with usually-redundant (i.e. derived from the public key by a simple hash function) data.

Aaron

On Wed, Nov 30, 2022 at 12:36 PM Paul van Brouwershaven via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:
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:
   For end entity certificates, the subject key identifier extension
   provides a means for identifying certificates containing the
   particular public key used in an application.  Where an end entity
   has obtained multiple certificates, especially from multiple CAs, the
   subject key identifier provides a means to quickly identify the set
   of certificates containing a particular public key.  To assist
   applications in identifying the appropriate end entity certificate,
   this extension SHOULD be included in all end entity certificates.

Looking at the data from Censys we also see that almost all end-entity certificates include the SKI:
(tags.raw: "precert" AND tags.raw: "trusted") AND NOT parsed.extensions.subject_key_id: * - Censys<https://search.censys.io/certificates?q=%28tags.raw%3A+%22precert%22+AND+tags.raw%3A+%22trusted%22%29+AND+NOT+parsed.extensions.subject_key_id%3A+%2A>
Can we align the profile with RFC 5280 and change the inclusion of the SKI to a SHOULD instead of the current NOT RECOMMENDED?
Paul

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.
_______________________________________________
Validation mailing list
Validation at cabforum.org<mailto:Validation at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/validation

This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.

Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy<https://www.teliacompany.com/en/about-the-company/privacy/>.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221201/e47f8f83/attachment.html>