Setting subjectKeyIdentifiers and authorityKeyIdentifiers - Re: Solved! - Re: Setting Issuer Alternative Name

Robert Moskowitz rgm at htt-consult.com
Mon May 15 12:41:57 UTC 2023


I will say that I tried reading the docs.  But they assume a certain 
approach, at least in my reading, and I am, undoubtedly stretching things.

Part of my problem is I read 5280 first and then tried mapping my goals 
into it and openssl docs.  Thus a bit of hunting and pecking at things.

After I get this done, I will be more attentive.  Though it may well be 
another 4 years (last I worked hard with openssl!).

In this case, I just did not get the linkage of the Authority Key 
Identifiers and the Subject Key Identifiers of the Authority's cert.  
And really no excuse for the mental block.  What an "oy vay' moment...

Sigh.

Now I am realizing I am being a little too loose in keyusage and 
extendedkeyusage.  So I am plowing through the docs to get those right.  
Or at least as right as I can get then.

But I do think I am on the home stretch, and I can get this written up 
this week.

Bob

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


More information about the openssl-users mailing list