Subject: RE: On key identifier

From: Darren Harter <[email-masked]>
Date: Tue, 11 May 1999 11:04:20 +0100

You are correct that the SHA-1 should be done on the DER encoding of the DSA public key, but unfortunately the example encoding in RFC 2459 is not correct.

If the public key is AA98EA.... then the DER encoding of this value begins with 02818100 not 028180 as stated in the examples section of RFC 2459.  RFC 2459 is in error.

You are performing the correct calculation but comparing your result against incorrect data.

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
+44 (0) 1452 371383
Email: mailto:[email-masked]

-----Original Message-----
From:	Xiong Shao Jun [SMTP:[email-masked]]
Sent:	Tuesday, May 11, 1999 10:43 AM
To:	Darren Harter
Cc:	[email-masked]
Subject:	Re: On key identifier

I think 028180aa98--- is the DER encoded DSA public key. So SHA-1 should be done on
this part. My result was just operated with such calculation.

Best regards,
Xiong Shaojun

Darren Harter wrote:

> Just as a slight aside....
>
> If the public key in this certificate is the POSITIVE integer value 0xAA98EA...... then the DER encoding of it is incorrect as shown in the example.  Integers are encoded as 2's-complement numbers, and the encoding as shown contains a negative number who's 2's-compliment encoding is 0xAA98EA.....
>
> The encoding for any positive integer who's highest bit is set must start with a zero octet.  The correct integer encoding for the public shown would be as follows:
>
> 02 81 81 00 aa 98 ea 13 94 a2 db f1 5b 7f ....
>
> Likewise any negative number with a highest bit clear would start with a 0xFF octet.
>
> This problem affects many of the integer encodings in the example certificates in RFC 2459.
>
> Is it possible that the key identifier in the example has been calculated over the correct integer encoding rather than the one shown?
>
> Regards,
>
> Darren
>
>                            : 55 1d 0e
> 0615 04 16           22: . . . . . OCTET STRING
>                               : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95
> aa d5 ff
>                               : 1c 21 e4 22 75 d6
>
> So, what causes the problem?

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 16 May 1999 11:43:57 (NZST)

>Hi, folks. I'm working on a PKIX project. A few days ago, when I run a test on
>key identifier, I encounter a problem. In rfc 2459 section 4.2.1.2, as to key
>identifier, it says:
>
>(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).

That's only the PKIX recommendation, in practice people are putting pretty much
anything in there, ranging from a single byte up to the full SHA-1 (or at least
some 20-byte value) hash of some part of the key or something else.

>I get sample data from rfc2459, Example D.1, which is a CA certificate, and I
>think I should do SHA-1 on the DER-encoded subjectPublicKey, according to the
>above paragraph, but I got a different result. My SHA-1 result is:
>a1d443c9243cfa0587f8a99898ddefc4e7359888

This would only matter if the key ID's were implicit (in which case you'd have
to ensure that the value you calculate corresponds exactly to the value someone
else would calculate).  Since they're explicit, it doesn't really matter if you
don't get it exactly right, as long as it's unique for each key.

Peter.