Subject: RE: On key identifier

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

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

------------------------------------------------------------------------
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 3:52 AM
To:	[email-masked]
Subject:	On key identifier

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).

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

Below is data from rfc2459:
subjectPublicKey:
0452 03 81 84     132: . . . BIT STRING  (0 unused bits)
                               : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f
98 2f 78
                               : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da
3b 4b 13
                               : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2
6b 5c 77
                               : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb
25 bc 91
                               : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e
60 13 ca
                               : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc
71 de cf
                               : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d
d0 7b ba
                               : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83
25 4f 14
                               : aa 71 e1

0608 30 1d           29: . SEQUENCE
0610 06 03             3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
                              : 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: "Xiong Shao Jun" <[email-masked]>
Date: Tue, 11 May 1999 17:42:52 +0800

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