3 ms·
Thank you! Not a bad idea to write a post about SKID because everyone misunderstands it! It does not reliably identify a key, since CAs are allowed to derive
by agwa 3y ago
Thank you!
Not a bad idea to write a post about SKID because everyone misunderstands it! It does not reliably identify a key, since CAs are allowed to derive it however they want. If you want to find other certificates using the same key, you should ignore the SKID entirely and instead search based on the hash of the SubjectPublicKeyInfo. (In fact, starting September 15, inclusion of the SKID in website certificates will be NOT RECOMMENDED.)
- InvaderFizz 3y agoSee, even myself as someone that generally understands a lot about certs got that part wrong.
- woodruffw 3y ago(I want to second the thanks for the excellent blog post!) Do you know if the dis-recommendation of SKIs also applies to AKIs? I know they’re similarly (but slightly less) flexible, so moving away from them would (seem) to be a win as well.
- agwa 3y agoFrom a policy standpoint, including AKI will still be a MUST, as will SKIs in CA certificates. Only in end-entity certificates will SKI be NOT RECOMMENDED. That said, they all suffer from the same problem - they look like they're derived from the public key, but there's no guarantee of this. Their only use is as an opaque identifier for looking up the issuer of a certificate, and only some certificate validators use them (e.g. Microsoft's); other validators (e.g. Mozilla's) ignore AKI/SKI entirely and just look up issuers by subject name, which works completely fine, suggesting that AKI/SKI are unnecessary.