Subject: RE: keyIdentifiers

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 Nov 1998 17:45:18 -0500

I agree with Steve for the most part.

Please note that with all due respect to X.509, even if the key
identifiers were not unique to a single subject or authority, it does
not cause any security or interoperability problem.

Please further note that use of the DN, serial number tuple for
authority key identifier is a bad idea.  It does not help with path
discovery for two reasons: 1 The syntax of subject key identifier does
not accommodate it; this becomes an issue since authority of a given
certificate is the subject of the previous certificate in a trust chain.
2.  If an authority is certified by multiple authorities, which tuple
should it put in the authKeyID field of the certificates it signs.
Putting one does not help discovering (actual it inhibits) paths going
through other authorities.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Wednesday, November 04, 1998 8:41 PM
> To:	Simonetti David
> Cc:	Kevin Kingdon; [email-masked]'
> Subject:	Re: keyIdentifiers
> 
> Folks,
> 
> Sorry I didn't jump in earlier, but I've been out of town and out of
> touch
> for a while.
> 
> Key identifiers were motivated as a hueristic to solve the problem of
> which
> of several certs (presumably with different keys) belonging to a CA
> should
> be used to validate a cert that was signed by that CA.  This means
> that the
> IDs need only be unique relative to the CA in question, since the
> scope of
> the "search" was just the set of certs associated with that CA. Note
> that
> CA name and serial number also are an acceptable alternative for this
> purpose.
> 
> Some have suggested using these IDs are a "key" for database searches
> for
> cert chain construction, etc., but this is not within the scope of the
> extension, and thus I would advise against design decisions based on
> presumed global uniqueness, even though the odds are in your favor for
> many
> values of "global" ;-).  S/MIME does rely on the likely global
> uniqueness
> of this value, if I recall correctly, using it as a tag for
> per-recipient
> tokens.  This is a carryover from the MSP design, where we had a key
> material ID that was guaranteed to be unique and which could be used
> for
> this purpose.
> 
> Steve