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

From: [email-masked] (Peter Gutmann)
Date: Tue, 21 Oct 2003 19:02:48 +1300

"Stefan Santesson" <[email-masked]> 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.

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 21 Oct 2003 08:38:43 -0400

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Gutmann
Sent: Tuesday, October 21, 2003 2:03 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?

@microsoft.com?

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

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

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Oct 2003 09:16:24 -0400

>tells you to do this though, since the only safe response to it is to ignore

The only CA that I know about that did this has changed to a hash-based 
alternative.

Russ

---

From: "Peter Hesse" <[email-masked]>
Date: Tue, 21 Oct 2003 09:45:17 -0400

"Peter Gutmann" <[email-masked]> writes:

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

The RFC 3280 certification path validation process does not include a
check of the sKID and/or aKID; if they don't match, there is nothing
wrong with the path.  Path building implementations should never rely on
them being correct.  They may be useful if they are present and correct,
but as was said, may lead building algorithms astray if they are present
and incorrect.  Therefore implementations should use them if they are
helpful, but not rely on their existence or fail if they are incorrect.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius