<div dir="ltr">Let's suppose that the SKID is always computed as a SHA1 hash of the public key info. Then the value of the SKID extension will be 20 bytes, and the full extension itself (including its OID and length headers) will be 31 bytes of DER.<div><br></div><div>It's hard to get an estimate of how many SSL handshakes happen globally every day, so rather than talking in total numbers let's talk in percentages. A <a href="https://crt.sh/?asn1=8130021554">randomly-selected</a> Let's Encrypt DV cert for a ~12-character dnsName and a 2048-bit RSA public key is ~1100 bytes. The SKID extension is nearly 3% of that total. Saving 3% of the bytes -- or even 1.5% if you include the intermediate that is being sent at the same time -- of every TLS handshake is huge. Lots of companies would love to have such a straightforward way to save 3% on their core cost metrics.</div><div><br></div><div>If you assume SKIDs are a SHA256 hash instead (because no one wants to be running SHA1 code anymore), then nearly double those numbers. If you assume that chain has ECDSA public keys and signatures, nearly double them again.</div><div><br></div><div>I think that saving this large of a percentage of handshake size <i>is</i> a good reason to deviate from RFC 5280.</div><div><br></div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 5, 2022 at 7:44 AM Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-5643647853076015220">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_-5643647853076015220WordSection1">
<p class="MsoNormal">+1. We really shouldn’t deviate from 5280 unless there is a good reason to. Even if SKI has minimal use, both SHOULD and SHOULD NOT are “optional” under CAB Forum so we aren’t limiting anyone by matching the RFC language.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>> <b>
On Behalf Of </b>Tomas Gustavsson via Validation<br>
<b>Sent:</b> Monday, December 5, 2022 1:11 AM<br>
<b>To:</b> Aaron Gable <<a href="mailto:aaron@letsencrypt.org" target="_blank">aaron@letsencrypt.org</a>>; Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com" target="_blank">Paul.vanBrouwershaven@entrust.com</a>>; Lahtiharju, Pekka <<a href="mailto:pekka.lahtiharju@teliacompany.com" target="_blank">pekka.lahtiharju@teliacompany.com</a>>; CABforum3 <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL] Re: RFC 5280 conflict for SKI in subscriber certificates<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10pt;font-family:Arial,sans-serif;color:black;background:white">When suggesting changes to RFC5280, the argument against it is always that it will most certainly break the internet, due
to the amount of different software out there. We've seen issues in the past due to BRs specifying things differently than RFC5280. With that I want to say there is definitely a risk in breaking the connection with RFC5280, a risk that is not easy to see in
the short term. Going astray from RFC5280 should imho only be considered when there is a very significant advantage. Since it is only a SHOULD in rfc5280, I find it hard to see the big advantage that outweighs the risk (even if the risk is considered minor).<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif;color:black;background:white"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif;color:black;background:white">Cheers,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif;color:black;background:white">Tomas<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif;color:black;background:white"><u></u> <u></u></span></p>
</div>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="m_-5643647853076015220divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>> on behalf of Lahtiharju, Pekka via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Sent:</b> Friday, December 2, 2022 7:53 AM<br>
<b>To:</b> Aaron Gable <<a href="mailto:aaron@letsencrypt.org" target="_blank">aaron@letsencrypt.org</a>>; Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com" target="_blank">Paul.vanBrouwershaven@entrust.com</a>><br>
<b>Cc:</b> CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL] Re: RFC 5280 conflict for SKI in subscriber certificates</span>
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div style="border:1pt solid rgb(156,101,0);padding:2pt">
<p class="MsoNormal" style="line-height:12pt;background:rgb(255,235,156)"><b><span style="font-size:10pt;color:rgb(156,101,0)">CAUTION:</span></b><span style="font-size:10pt;color:black"> External Sender - Be cautious when clicking links or opening attachments. Please
email <a href="mailto:InfoSec@keyfactor.com" target="_blank">InfoSec@keyfactor.com</a> with any questions.<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="m_-5643647853076015220xmsonormal">CA can use SKI for internal purposes to help finding their own certificates with the same public key. For example, the new Key Compromise revocation reason code specification requires CA to revoke all certificates using the same key. Our
own certificates use always the same algorithm for SKI so we can be sure that search result is correct. We haven’t used it to search external certificates.
<u></u><u></u></p>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
<p class="m_-5643647853076015220xmsonormal">Also the CA software we are using currently always add SKI to all certificates; there is no option to not use it.<u></u><u></u></p>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
<p class="m_-5643647853076015220xmsonormal">Pekka<u></u><u></u></p>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="m_-5643647853076015220xmsonormal"><b>From:</b> Aaron Gable <<a href="mailto:aaron@letsencrypt.org" target="_blank">aaron@letsencrypt.org</a>>
<br>
<b>Sent:</b> torstai 1. joulukuuta 2022 20.42<br>
<b>To:</b> Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com" target="_blank">Paul.vanBrouwershaven@entrust.com</a>><br>
<b>Cc:</b> Hubert Chao <<a href="mailto:hchao@google.com" target="_blank">hchao@google.com</a>>; Lahtiharju, Pekka <<a href="mailto:pekka.lahtiharju@teliacompany.com" target="_blank">pekka.lahtiharju@teliacompany.com</a>>; CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>>;
Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>><br>
<b>Subject:</b> Re: [EXTERNAL] Re: [cabf_validation] RFC 5280 conflict for SKI in subscriber certificates<u></u><u></u></p>
</div>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
<div>
<p class="m_-5643647853076015220xmsonormal">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.<u></u><u></u></p>
<div>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal">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 :)<u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal">Aaron<u></u><u></u></p>
</div>
</div>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
<div>
<div>
<p class="m_-5643647853076015220xmsonormal">On Thu, Dec 1, 2022 at 7:18 AM Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com" target="_blank">Paul.vanBrouwershaven@entrust.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black">The SKI is useful to quickly search for certificates with the same key.</span><u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black">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?</span><u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black">Are we sure that this would not cause any client incompatibility issues? Almost<span style="background:white"> 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.</span></span><u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black">Paul</span><u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal" style="background:white"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="m_-5643647853076015220x_m_-8904594178938362390divRplyFwdMsg">
<p class="m_-5643647853076015220xmsonormal"><b><span style="color:black">From:</span></b><span style="color:black"> Hubert Chao <<a href="mailto:hchao@google.com" target="_blank">hchao@google.com</a>><br>
<b>Sent:</b> Thursday, December 1, 2022 15:59<br>
<b>To:</b> Lahtiharju, Pekka <<a href="mailto:pekka.lahtiharju@teliacompany.com" target="_blank">pekka.lahtiharju@teliacompany.com</a>>; CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Cc:</b> Aaron Gable <<a href="mailto:aaron@letsencrypt.org" target="_blank">aaron@letsencrypt.org</a>>; Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com" target="_blank">Paul.vanBrouwershaven@entrust.com</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [cabf_validation] RFC 5280 conflict for SKI in subscriber certificates</span>
<u></u><u></u></p>
<div>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
</div>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<u></u><u></u></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<div>
<div>
<p class="m_-5643647853076015220xmsonormal">On Thu, Dec 1, 2022 at 5:21 AM Lahtiharju, Pekka via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<p>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.<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal">Could you list out the use cases where this extension is useful for a TLS certificate? The discussion that Corey linked to (<a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flists.cabforum.org%2Fpipermail%2Fvalidation%2F2021-July%2F001672.html__%3B!!FJ-Y8qCqXTj2!bhb6QGSEpqEOi6JyHDzixLHA_ziEpOs6UQYkMiffRA4PH_9fFgyIiZRW3epCZqq0_V5K5pDehK6XTaH3PNBz1ibt%24&data=05%7C01%7Ctomas.gustavsson%40primekey.com%7Ca77bbc1c0b7840599a3e08dad431ea26%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638055608160945478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LMcp1hZgr1RctTVx2LAf16ewcktRHuAP9fyF2irydpI%3D&reserved=0" target="_blank">https://lists.cabforum.org/pipermail/validation/2021-July/001672.html</a>)
specifically says "... a TLS certificate [SKI] should not be needed ... ".<u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal"> <u></u><u></u></p>
</div>
<div>
<p class="m_-5643647853076015220xmsonormal">/hubert <u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="m_-5643647853076015220xmsonormal"><i>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. <u>Please notify Entrust immediately</u> and delete the message from your system.</i>
<u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:9pt"><br>
<i>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.
<br>
<br>
Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s
<a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.teliacompany.com%2Fen%2Fabout-the-company%2Fprivacy%2F&data=05%7C01%7Ctomas.gustavsson%40primekey.com%7Ca77bbc1c0b7840599a3e08dad431ea26%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638055608160945478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b%2BiqCDqfMnfryWWqRLubBULI4Vv5SRTSvuWTm4%2F0Xzw%3D&reserved=0" target="_blank">
Privacy Policy</a>.</i> <br>
<br>
<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div></blockquote></div>