RE: AKI and SKI problem with RFC 3280?

["Al Arsenault" <aarsenau@xxxxxxx>]

Okay, I'll bite...

Why does an AKI/SKI have to be globally unique?

It strikes me that the AKI/SKI extensions are simply "search aids".  That
is, they merely help the application (RP) determine which of a set of
possible certificates to use is the correct one. While it would be kind of
cool if an SKI/AKI would be globally unique (it would make searching a
repository a little easier/quicker IN SOME CASES), it doesn't strike me as a
huge deal.

Even using the "monotonically increasing integer sequence" scheme, what we'd
have is:

	Cert A and Cert B have the same AKI value
	Cert A is issued by CA Z, and has serial number N
	Cert B is issued by CA Y, and has serial number M

	(Note that the CA values would be different, because a single CA can't
issue the same AKI/SKI value to multiple certs.  The serial numbers could
coincidentally be the same; that's a random chance.)

	So the path validation software SHOULD say:  "gee, I fetched a cert from
the repository by matching on SKI - I didn't bother searching on issuer
name/serial, or subject name, or...  So now I've got two matches.  Which one
should I use?  Maybe I should actually try looking at one of the other
fields to get a clue, or maybe I'll just take a shot and die a horrible
screaming death if I guess wrong?"

	I'm foggy on the details, but it strikes me that the "monotonically
increasing integer" scheme was actually in use by somebody, and nobody
believed it was a real problem, given the use of the extensions, so we said,
in essence, "heck, why not?" How has that changed?

				Al Arsenault


-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Peter Gutmann
Sent: Tuesday, October 21, 2003 2:03 AM
To: ietf-pkix@xxxxxxx; stefans@xxxxxxxxxxxxx
Cc: housley@xxxxxxxxxxxx
Subject: Re: AKI and SKI problem with RFC 3280?



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