Subject: keyIdentifiers

From: [email-masked] (Peter Gutmann)
Date: Tue, 3 Nov 1998 21:27:19 (NZDT)

Someone has just pointed out to me that the newer PKIX drafts have changed the 
keyIdentifier derivation to:
 
>      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
>      value of the BIT STRING subjectPublicKey (excluding the tag,
>      length, and number of unused bits).
 
Since this excludes the algorithm type and parameters, it can lead to 
identifier clashes in cases where the subjectPublicKey consists of just a 
single integer (which is the case for a number of algorithm types).  This 
means that someone could construct a key for a different algorithm which would 
appear identical using the current PKIX interpretation of the keyIdentifier, 
but distinct with other interpretations.  There are various denial-of-service 
attacks possible with this (chaining works with a non-PKIX implementation but 
not a PKIX-compliant one, assuming you're chaining off the keyIdentifier which 
noone actually seems to do at the moment).
 
Trawling through my collection of profiles I've found that:
 
  X.509v3 allows you to use both types of identifier, but other standards and 
  profiles recommend against this.  Various profiles have at various times 
  required the use of the SHA-1 hash of the public key (whatever that 
  constitutes), the SHA-1 hash of the subjectPublicKeyInfo data (for some 
  reason this has to be done *without* the tag and length at the start), the 
  SHA-1 hash of the subjectPublicKey (again without the tag, length, and 
  unused bits portion of the BIT STRING, which leaves just the raw public key 
  data but omits the algorithm identifier and parameters so that two keys for 
  different algorithms with different parameters which happen to share the 
  same public key field end up with the same hash), a 60-bit hash of the 
  subjectPublicKeyInfo (presumably with the tag and length), a 64-bit hash of 
  the subjectPublicKey (again with tag and length) with the first four bits 
  set to 0100 to indicate the use of SHA-1, and some sort of unique value such 
  as a monotonically increasing sequence.  Several newer profiles have pretty 
  much given up on this and simply specify "a unique value".
 
Given the wide selection of choices, it might be better to just include some 
general guidelines on how to generate the keyIdentifier, including a note that 
the input to the hash should include all the parameters for the key (including 
algorithm type and whatnot), and to warn implementors not to expect any 
particular format for the keyIdentifier.  
 
In addition, moving from a MUST to a MAY also seems to be a good idea, since 
(a) there's no consensus on what to put in there so you'll see all sorts of 
odd stuff, and (b) most implementations either ignore this value entirely or 
function just as well without it.  I don't really see why this has to be a 
MUST anyway, a MAY makes much more sense since it may be required for 
disambiguation in some cases but certainly isn't needed (or used) by virtually 
everything which is currently out there - it's just more useless baggage to 
cart around in a cert.
 
Peter.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 03 Nov 1998 07:31:41 -0500

>particular format for the keyIdentifier.  

I am not able to comment on this part of your observations, but...
 
>everything which is currently out there - it's just more useless baggage to 
I have seen two reasons for keyIdentifiers.

The first is by Chichani as a powerful way to build a cert chain.  Now this
is definitely a MAY and not a MUST, it would seem.

The second was brought to my attention by Myers as a clean way to handle
key renewal.  Since little of your field usage has dealt with renewals, we
have not seen this one yet.  But with the emergence of silicon based life
forms (eg IPsec devices), this will become more real in a year.

We need informational RFCs on the use of keyIdentifier for the PKIX
consuming market, ie S/MIME, TLS, and IPsec for starters.  This came out
load and clear last week at the IPsec workshop, where we were nailing down
which cert objects were important to implementors.

I fully intend to include keyIndentifiers (both subject and issuer) in the
ANX PKI and recommend other PKI builders to also push for clearification on
these objects.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: "Simonetti David" <[email-masked]>
Date: Tue, 03 Nov 1998 09:39:25 -0500

Peter,

The text you pasted from the profile is one of two recommended methods
for generating a key identifier.  However, neither is required.  I think
the current text mostly accomodates your suggestions.

Dave S.

-- 
David Simonetti, Booz·Allen & Hamilton Inc.

---

From: Marc Branchaud <[email-masked]>
Date: Tue, 03 Nov 1998 17:29:34 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

"Simonetti David" <[email-masked]> scrawled:
> =

> =

> for generating a key identifier.  However, neither is required.  I thin=
k
> =

Further to this, doesn't end-entity software treat a key identifier as a =

black blob?  In other words, it's up to the CA to include these things in=
 =

its certs, and if they're there then the end-entity app just grabs the =

value and looks for a match in other certs.  That app has no business =

conjuring up a key ID from the public key in a cert and trying to match i=
t =

to other conjured-up key IDs -- it would be better off just matching up =

the keys directly anyway.

If the CA wants its PKI to use key IDs, it'll put them in its certs and
that'll be that.  The PKIX recommendations for key ID derivation are for =

CAs to follow, as in they choose one method and stick to it.  End-entity =

apps need not concern themselves with such arcane matters.

		Marc

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 03 Nov 1998 14:34:25 -0500

At 05:29 PM 11/3/98 +0000, Marc Branchaud wrote:

Not according to a presentation Chicani gave to the federal PKI TWG back in
the spring.  He was quite clear that it was an APP issue to use
keyIdentifiers to build a cert chain.

Then last week Mike Myers was pointing out how an app can use keyIdentifer
for simpler processing for renewals.  Mike could better discuss this then
me remember it.

>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNj89flrdFXNdDxPlAQGbhAL9Gk0lN063hZodHTvdGi3A8l1ijyANrJp/
>POHaCLC8qfB41awFY4lPx8bwlSecnMbgu6HRc3RLIRlkNQ2sjPsNLL39x8kE2+lz
>oQ+60LGoKxuBjyeCHxi1SSB7tbNXot6K
>=yK7A
>-----END PGP SIGNATURE-----

Robert Moskowitz
ICSA

---

From: Marc Branchaud <[email-masked]>
Date: Tue, 03 Nov 1998 19:58:39 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

> keyIdentifiers to build a cert chain.

Sure, but the app doesn't have to construct any key identifiers, just use 
the ones that are already in the certs.

> for simpler processing for renewals.  Mike could better discuss this then

That's a different, and new, usage for key identifiers which I haven't 
heard of before.

My point is that s'far as chain construction goes, apps don't need to know
how to create key identifiers.  If key IDs are to be used for other
purposes, then some standard method of construction is probably a good
idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
identifiers, not apps.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 03 Nov 1998 15:48:47 -0500

>the ones that are already in the certs.

My understanding also.  Your earlier message came through poorly formatted
and I did not read it carefully.  the CA creates the hash, and the app just
uses it.

I think another usage of the hash (if I remember right) is the index for
attribute certs.

Robert Moskowitz
ICSA