RE: AKI and SKI problem with RFC 3280?

["Al Arsenault" <aarsenau@xxxxxxx>]

Okay, now I'm *truly* confused.


-----Original Message-----
From: Peter Gutmann [mailto:pgut001@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, October 22, 2003 3:26 AM
To: aarsenau@xxxxxxx; ietf-pkix@xxxxxxx; pgut001@xxxxxxxxxxxxxxxxx;
stefans@xxxxxxxxxxxxx
Cc: housley@xxxxxxxxxxxx
Subject: RE: AKI and SKI problem with RFC 3280?


"Al Arsenault" <aarsenau@xxxxxxx> 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.

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