Re: AKI and SKI problem with RFC 3280?

[Stephen Kent <kent@xxxxxxx>]

Title: Re: AKI and SKI problem with RFC 3280?

At 11:12 +0100 10/20/03, Stefan Santesson wrote:

>  
> I have
> come a cross a potential problem with RFC 3280 when working on the new
> ETSI Certificate profile standard for identity
> certs.
>  
> RFC
> 3280 states:
>  
> 4.2.1.1
>  
>    The value of the keyIdentifier field
> SHOULD be derived from the
>    public key used to verify the
> certificate's signature or a
> method
>    that generates unique values.  Two common methods for generating
> key
>    identifiers from the public
> key, and one common method for
> generating
>    unique values, are described in section
> 4.2.1.2
>  
> 4.2.1.2
>    One common
> method for generating unique values is a
> monotonically
>    increasing sequence of
> integers.
>  
>  
> This means that a CA, following the recommendation can
> assign key identifier values of e.g. 1, 2, 3, 4, 5, 6,...,
> n
>  
> If many different CA:s would follow the
> "monotonically increasing sequence of
> integers" procedure, multiple unrelated
> certificates would end up having the same SKI and/or AKI values
> relating to completely different public keys.
>  
> I'm not sure how most path building clients would
> handle a situation like that, but I fear that at least some would
> fail.
>  
> Isn't the point that AKI:s and SKI:s should use a
> generation algorithm that assigns them a globally unique value with
> high probability and therefore SHOULD be derived from the public key
> and NOT use a "monotonically increasing
> sequence of integers". At least not
> starting from a small integer?
>  
> /Stefan

For path building purposes, there is no need for uniqueness in these values.  We have stated several times that path building is NOT supposed to use these values to locate certs, but rather to disambiguate among certs that have the right Subject name (assuming a bottom's up path building).

However, when the SKI appears in an EE cert, and that EE cert is used in S/MIME, then we are assuming uniqueness, because the receiver uses the SKI to locate the right token for that receiver.  This support for S/MIME is why we put in the SKI requirement for EE certs, where it otherwise would not be needed (re path building).

Steve

P.S.  Peter, your example talked about signature verification, but I don't think that's right, because the signature info is not per recipient, it is per originator, and thus would not encounter this problem.