Re: AKI and SKI problem with RFC 3280?

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

"Stefan Santesson" <stefans@xxxxxxxxxxxxx> writes:

@microsoft.com?

>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.

Yup.  I've seen CAs use bits of key hashes, monotonically increasing integers,
numeric text strings, MPEGs of cats...

>I'm not sure how most path building clients would handle a situation like
>that, but I fear that at least some would fail.

My code has included a check to ignore the sKID if it's less than 40 bits for
some time now, because anything less than that is a danger sign implying the
use of an integer sequence.

>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?

There is some reason why CAs do this, I can't remember why but I think it was
the usual ostrich algorithm ("There is no CA but us; to think otherwise is
treason punishable by limb reconstruction").  I'm not quite sure why the RFC
tells you to do this though, since the only safe response to it is to ignore
any sKIDs of that form.

Peter.