Subject: Computation of issuerKeyHash in OCSP

From: [email-masked]
Date: Mon, 12 Mar 2001 10:55:17 +0000

All,

I'd be grateful for clarification of the following point, regarding the
computation of the issuerKeyHash term in the CertID information used in
OCSP (v1).

The OCSP spec states:

'issuerKeyHash is the hash of the Issuer's public key. The hash shall be
calculated over the value (excluding tag and length) of the subject public
key field in the issuer's certificate.'

Note that subjectPublicKey is defined as having ASN1 type BIT STRING.  Can
someone specify whether the *entire* 'value' part of this encoded bit
string should be used, including the 'number of unused bits' octet, or
whether the 'number of unused bits' octet should be excluded, and only the
remaining value octets should be used.

Many thanks in advance,

Jonathan Tuliani
www.Symbian.com

**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [email-masked] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 12 Mar 2001 07:33:32 -0800

Hi Jonathan,
    Yes, it is the hash of the entire BIT STRING, including the
'number of unused bits' octet (but excluding the tag for BIT STRING
and length).

This has been clarified in the draft of what will go forward as
a candidate for Draft Standard.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 2:55 AM
> To: [email-masked]
> Subject: Computation of issuerKeyHash in OCSP
> 
> 
> All,
> 
> Symbian Ltd is a company registered in England and Wales with 
> registered number 01796587 and registered office at 19 
> Harcourt Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee 
> and may contain privileged and/or confidential information. 
> If you are not the named addressee you should not 
> disseminate, copy or take any action in reliance on it. If 
> you have received this message in error please notify 
> [email-masked] and delete the message and any 
> attachments accompanying it immediately. Symbian does not 
> accept liability for any corruption, interception, amendment, 
> tampering or viruses occuring to this message in transit or 
> for any message sent by its employees which is not in 
> compliance with Symbian corporate policy.

---

From: [email-masked]
Date: Mon, 12 Mar 2001 18:58:53 +0000

All,

From Ambarish we have:

Yes, it is the hash of the entire BIT STRING, including the 'number of
unused bits' octet (but excluding the tag for BIT STRING and length).

And from Peter we have:

The weird hashing is a perpetual source of trouble for implementors (I
eventually found it out by trial and error), what you need to do is take
the BIT STRING part of the subjectPublicKeyInfo, strip off the BIT STRING
tag and the length and the unused-bits value, and hash what's left.

It's seems that different views on my original question have been taken by
different people.  I understand that the revised specs iron all this out,
but in the meantime, what do people actually do in practice?

Jonathan Tuliani
www.Symbian.com

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 13 Mar 2001 11:10:12 (NZDT)

"Michael Myers" <[email-masked]> writes:

>So only in the case of CertID is issuerKeyHash calculation required.  The
>issuerSerial options imports IssuerandSerialNumber syntax from CMS.  Do these
>actions address the points you raised?

Absolutely, that's why in my original reply I expressed the hope that people
would move to v2 ID's with all haste.

Peter.

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 12 Mar 2001 14:15:21 -0800

Hi Jonathan,
    I have done interop testing of the OCSP responder with
Netscape, CertCo, Xeti (now part of Critical Path), Computer
Associates and a bunch of other folks. I would be very surprised
if anybody was stripping out the byte that represented the
number of unused bits.

With regards to the OCSPv2 identifiers, I still haven't seen or
heard of any implementations....

Hope this helps,
Regards,
Ambarish

> Sent: Monday, March 12, 2001 10:59 AM
> To: [email-masked]
> Subject: RE: Computation of issuerKeyHash in OCSP
> 
> 
> 
> All,
> 
> From Ambarish we have:
>

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 12 Mar 2001 17:48:32 -0800

Peter, Steve, (and many other people),
    I am sorry, I screwed up.

    We are hashing the bit string *without* the number of
unused bits. This is what we have been using in all the interop
testing that we have done up to now.

I apologize for my mistake.

Regards,
Ambarish

> From: Dr S N Henson [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 3:40 PM
> To: [email-masked]
> Subject: Re: Computation of issuerKeyHash in OCSP
> 
> 
> Peter Gutmann wrote:
> > 
> > Ambarish Malpani <[email-masked]> writes:
> > 
> Netscape, CertCo, Xeti
> > >(now part of Critical Path), Computer Associates and a 
> bunch of other folks. I
> > >would be very surprised if anybody was stripping out the 
> byte that represented
> > >the number of unused bits.
> > 
> > That would explain why my previously-working code was 
> getting a status of
> > "unknown" all of a sudden... dammit, make one little update 
> to your code
> > without thinking and... :-).
> > 
> 
> I was stripping the number of unused bits out too: well with
> OpenSSL/SSLeay that's the more natural thing to do(*). It is 
> also one of
> the recommended mechanisms in RFC2459 (4.2.1.2) and I didn't 
> notice the
> difference.
> 
> AFAICS using the number of unused bits will just mean that a '0' is
> prepended to the data hashed for any valid encoding.
> 
> I was getting valid responses from the responders I'd tried which
> suggests that either they are ignoring the issuerKeyHash or they are
> also ignoring the number of unused bits.
> 
> (*) In case anyone is curious... the OpenSSL/SSLeay structure 
> for a BIT
> STRING consists of a buffer, a length value and some flags. The buffer
> is the BIT STRING *without* the number of unused bits. The 
> actual number
> of unused bits is stored in part of the flags field.
> 
> Steve.
> -- 
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [email-masked] 
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [email-masked] PGP key: via homepage.
>

---

From: Ari Kermaier <[email-masked]>
Date: Tue, 13 Mar 2001 14:13:53 -0500

We did interop vs. Valicert OCSP responder using the hash of the bytes of 
the DER encoding of the publicKey, and had no trouble. (This should be 
identical to the BIT STRING value from the subjectPublicKeyInfo minus 
header and unused bits, and is considerably simpler to think about.)

Ari Kermaier
Phaos Technology