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

From: [email-masked] (Peter Gutmann)
Date: Wed, 22 Oct 2003 20:26:17 +1300

"Al Arsenault" <[email-masked]> writes:

>Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
>only comes in to play if I signed the CMS message using my CA cert, not my
>end-entity cert.
>
>Got an example where this is relevant if the sKID's of two different CA certs
>are the same?  

My CMS example from earlier used with SCEP.

In any case something like this should never be allowed to happen as a matter
of basic protocol design.  Creating a "unique" key ID and then specifically
telling people they can use non-unique IDs is just asking for trouble.

Peter.

---

From: "Al Arsenault" <[email-masked]>
Date: Wed, 22 Oct 2003 08:08:29 -0400

Okay, now I'm *truly* confused.

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]]
Sent: Wednesday, October 22, 2003 3:26 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

awa:> Um, the current spec for SCEP appears to be
http://www.ietf.org/internet-drafts/draft-nourse-scep-08.txt

awa:> From that, it appears that:

awa:>    (a) SCEP doesn't use CMS, it uses PKCS #7
awa:>    (b) SCEP doesn't support the use of sKID or aKID as an identifier
in the signerInfo, it's restricted to
	     issuerAndSerialNumber (which, oh-by-the-way, is not guaranteed to be
unique in the real world, since I can set up
		a CA of my own reusing an issuer name that's already out there :-)
awa:>    (c) this is only relevant when the certificate requester is
creating a self-signed "CA" cert for the purpose of establishing the
connection with the CA, anyway.

awa:> So, your assertion is that a bastardized hybrid of a widely-used but
non-standard protocol (SCEP) with an updated wrapping mechanism (CMS) will
cause problems for some types of signature validation software, and this is
a reason why one option permitted by PKIX is a fundamental flaw?

In any case something like this should never be allowed to happen as a
matter
of basic protocol design.  Creating a "unique" key ID and then specifically
telling people they can use non-unique IDs is just asking for trouble.

awa:> I don't have any great love for the "monotonically increasing integer
sequence" mechanism myself, particularly since we've had a number of
discussions about what "monotonically increasing" means (different sources
have different definitions; some definitions allow the repitition of numbers
as pointed out by Peter Sylvester).  All PKIs in which I've ever been
involved have either used the "low-order 60 bits of a SHA-1 hash" or the
"full SHA-1 hash". The bottom line, though, is that I think anybody who
builds cert validation software for a large, complex system with multiple
CA's, multiple extensions, etc., and who believes that "if the sKID matches,
I am guaranteed to have found the right certificate" is being somewhat
simple in his software design.

		Al Arsenault

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Oct 2003 09:21:25 -0400

>telling people they can use non-unique IDs is just asking for trouble.

Peter,

SCEP is not an IETF standard, and it sounds as if it's use of these 
extensions is not consistent with the guidance provided in 2459, and 
now in 3280. Whose fault is that?

Steve