<html><head></head><body><div>Argh, so you were not really after Issuer Alternative Names (which, like SANs, are about entity names),<br>but after Authority Key Identifiers (which, like SKIDs, are about IDs for key material)!</div><div>That's an entirely different thing.</div><div><br></div><div>As a general note,</div><div>it would have been helpful to have a look at the OpenSSL documentation on how to set them up<br>before experimenting in trial-and-error mode and asking on a large mailing list like this.<br>With OpenSSL 3.0 the documentation on certificate handling has been improved significantly,<br>and some more improvements are in the pipeline for version 3.2.<br>So (at least meanwhile) it's worth consulting the man pages first.</div><div><br></div><div>Concerning the particular topic SKIDs and AKIDs, I had recently written to this mailing list <br><span style="font-size: 14.666667px;">on Thu, 2023-04-27 at 05:22 +0200:<br><br></span></div><div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Another advantage of using the OpenSSL 3.0+ apps is that they automatically add any needed/recommended <br>subject key identifier (SKID) and authority key identifier (AKID) extensions (while they are not needed for self-signed end-entity certs),<br>without the need to use extension configuration files or <span style="font-size: 14.666667px;">CLI parameters such as<font face="Courier New, Courier, monospace"> </font></span><font face="Courier New, Courier, monospace">-addext 'authorityKeyIdentifier = keyid:always'</font></div></blockquote><br></div><div><span></span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>David</div><div><br></div><div>On Sun, 2023-05-14 at 19:52 -0400, Robert Moskowitz wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>i asked a question about the whole aKID and sKID piece on the pkix list <br></div><div>and Peter Gutmann said something that I had lost track of in the weeds...<br></div><div><br></div><div>The content of keyid used in:<br></div><div><br></div><div>authorityKeyIdentifier = keyid<br></div><div><br></div><div>Is the sKID from the signing cert. argh.<br></div><div><br></div><div>So going back to the hack that Viktor had given me to have control over <br></div><div>the Validity dates in my self-signed cert,,,,<br></div><div><br></div><div>I realized that was where the aKID was really coming from, and that cert <br></div><div>was generated before I worked out controlling sKID in the conf:<br></div><div><br></div><div>subjectKeyIdentifier = $ENV::DET<br></div><div><br></div><div>So go all the way back to start.<br></div><div><br></div><div>and Now I have my certs with the sKID and aKID I was trying to get.<br></div><div><br></div><div>Well there is 2+ days of struggle and distracting all of you from other <br></div><div>tasks!<br></div><div><br></div><div>Thank you Viktor for you time.<br></div><div><br></div><div>I can't directly control what is in aKID, as it is pulling aKID from the <br></div><div>signing cert. Fix that and..<br></div><div><br></div><div>Bob<br></div><div><br></div><div>On 5/14/23 15:28, Robert Moskowitz wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div><br></div><div>On 5/14/23 14:00, Viktor Dukhovni wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Sun, May 14, 2023 at 12:44:48PM -0400, Robert Moskowitz wrote:<br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>I looked at that manpage and tried:<br></div><div><br></div><div>authorityKeyIdentifier =<br></div><div>otherName:1.3.27.16.2.1.1;BITSTR:20010030000000052aeb9adc1ce8b1ec<br></div></blockquote><div><a href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1">https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1</a><br></div><div><br></div><div> AuthorityKeyIdentifier ::= SEQUENCE {<br></div><div> keyIdentifier [0] KeyIdentifier OPTIONAL,<br></div><div> authorityCertIssuer [1] GeneralNames OPTIONAL,<br></div><div> authorityCertSerialNumber [2] CertificateSerialNumber <br></div><div>OPTIONAL }<br></div><div><br></div><div>You're trying to set the AKID to just the GeneralName, but it has to be<br></div><div>a tagged sequence,<br></div></blockquote><div><br></div><div>I did spend some time digging to get what a "tagged sequence" is let <br></div><div>alone represent it but can't find it in 5280<br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div> and note that "authorityCertIssuer" is the name of<br></div><div>the "grandparent" of the certificate in which the AKID appears, along<br></div><div>with the authorityCertIssuer you'd need to provide the serial number<br></div><div>of the parent certificate.<br></div></blockquote><div><br></div><div>The two together seems only mandated in sec A.2.<br></div><div><br></div><div>I am not finding any discussion on authorityCertIssuer being that of <br></div><div>the "grandparent", can you point me to that?<br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>But as I mentioned before, I don't expect that support for names other<br></div><div>than directory names in the AKID extension is particularly common.<br></div></blockquote><div><br></div><div>Well I could put:<br></div><div><br></div><div>e.d.c.a.b.0.b.e.0.6.8.2.e.0.b.9.5.0.8.f.f.3.e.f.f.3.0.0.1.0.0.2.ip6.arpa.<br></div><div><br></div><div>? It will exist (we are for now doing this under driptesting.org as it <br></div><div>will be a bit of process to get 3.0.0.1.0.0.2.ip6.arpa. delegated).<br></div><div><br></div><div>But that is 73 bytes to show a 16 byte value.<br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>You're better off with just "keyIdentifier", liking the child cert<br></div><div>to the key if of the parent cert.<br></div></blockquote><div><br></div><div>I assume you mean:<br></div><div><br></div><div>authorityKeyIdentifier = keyid<br></div><div><br></div><div>and I can't see how to set keyid to 20010030000000052aeb9adc1ce8b1ec<br></div><div><br></div><div>I can control subjectKeyIdentifier like:<br></div><div><br></div><div>subjectKeyIdentifier = 20010030000000052aeb9adc1ce8b1ec<br></div><div><br></div><div> X509v3 Subject Key Identifier:<br></div><div> 20:01:00:30:00:00:00:05:2A:EB:9A:DC:1C:E8:B1:EC<br></div><div><br></div><div>Which is defined as:<br></div><div><br></div><div>SubjectKeyIdentifier ::= KeyIdentifier<br></div><div><br></div><div><br></div><div>I tried<br></div><div><br></div><div>authorityKeyIdentifier = keyid=20010030000000052aeb9adc1ce8b1ec<br></div><div><br></div><div>And get an error<br></div><div><br></div><div>authorityKeyIdentifier = keyid:20010030000000052aeb9adc1ce8b1ec<br></div><div><br></div><div>Just uses the keyid as is:<br></div><div><br></div><div> X509v3 Authority Key Identifier:<br></div><div>0F:4E:5E:54:C2:4F:80:9E:E5:79:CD:B4:14:9B:BF:EB:A8:57:CB:CA<br></div><div><br></div><div><br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>Perhaps I should not have mentioned issuer SANs, you probably have no<br></div><div>use for them. Do use the appropriate data type in the EE SAN.<br></div><div><br></div></blockquote><div><br></div></blockquote><div><br></div></blockquote></body></html>