Subject: OCSPv2: 02: certHash is not unique

From: "Manger, James H" <[email-masked]>
Date: Mon, 26 Mar 2001 16:14:50 +1000

Comment on draft-ietf-pkix-ocspv2-02.txt

In section 3.1.2 Certificate Identification, the ReqCert type includes a
certHash field as one option for a client to identify a certificate.  The
syntax for the certHash field is an OCTET STRING.

There is no text describing the certHash field.  I guess it holds a hash of
the certificate.  I guess the hash is calculated over the DER-encoding of
the complete certificate.  There seems to be no indication of the hash
algorithm - perhaps it is always SHA-1.

I guess a certHash value is supposed to match the certificate "fingerprint"
or "thumbprint" that the browsers display.  A browsers relies on a
thumbprint unambiguously identifying a single certificate.  OCSPv2, on the
other hand, relies on a certificate having a unique certHash value.  These
properties - unambiguity and uniqueness - are quite different.  It is
reasonable to assume a certificate thumbprint is unambiguous, but it is
dangerous to assume it is unique for the certificate.

There are a number of ways to alter the encoding of the unsigned portion of
a certificate (signatureAlgorithm field, signatureValue field and outer most
tags).  Such modification don't alter the signed portion so the signature
remains valid, but they do change the thumbprint.  An attacker can modify
the bytes (hence thumbprint) without modifying the semantics of a
certificate.

For instance, consider omitting the NULL signature parameters associated
with sha1WithRSAEncryption in the signatureAlgorithm field.  It is not
unreasonable for a system to still accept such a certificate (particularly
with the "be strict with what you send but lenient with what you receive"
philosophy).  Yet the bytes do change so the thumbprint also changes.

An OCSPv2 responder may have one thumbprint of a certificate in its table of
revoked certificates, but would return "good" if a different thumbprint for
the same certificate appeared in the certHash field.

A better thumbprint (that is unique for a certificate) is a hash over only
the signed portion of the certificate (i.e. the same hash that goes into the
signature).

SOLUTION:  Delete the certHash field from the ReqCert type.

---

From: [email-masked] (Terry Hayes)
Date: Mon, 26 Mar 2001 11:08:47 -0800

James correctly points out some issues with the current definition of 
the proposed certHash method of identifying a certificate in an OCSP 
request.  I'd like to address several points in the message.

First, the draft does not indicate what digest algorithm should be used 
to calculate the hash.  This appears to be correct.  The current 
definition needs to be changed to include an AlgorithmInfo value that 
includes this information.

Second, he claims that the security of this method is suspect.  He has 
correctly pointed out a potential flaw in the security, however normal 
processing of certificates and signatures on certificates will prevent 
this from occurring.   James asserts that we should be "be strict with  
what you send but lenient with what you receive", but this general rule 
does not apply in situations where the security would be compromised.  
In this particular case two checks should be applied that will prevent 
this situation.  The primary check is that the signature algorithm in 
the "outer" portion of the certificate should match exactly the value in 
the "inner" (to-be-signed) portion.  A secondary solution is to ensure 
that the signatureAlgorithm field is exactly as defined for the 
algorithm used (DER-encoding rules are followed).

While the security is maintained given the correct procedures, it is 
easy to see how an implementation would get it wrong.  The need for 
these checks should certainly be mentioned in a security note in the draft.

Third, the certHash field is difficult to use in some deployments.  
Amberish points out that a certHash is not useful to a responder that is 
acting as a proxy for OCSP (or DPV).  In addition, even service that is 
responding for a single CA may not have certHash data available if it 
relies on CRLs for its revocation information.

Overall, I don't think the utility of this particular method of 
identification overcomes the potential problems and limitations.  I 
would be in favor of deleting it from the draft.

Terry Hayes

Manger, James H wrote:

> In section 3.1.2 Certificate Identification, the ReqCert type includes 
> a certHash field as one option for a client to identify a 
> certificate.  The syntax for the certHash field is an OCTET STRING.
> 
> There is no text describing the certHash field.  I guess it holds a 
> hash of the certificate.  I guess the hash is calculated over the 
> DER-encoding of the complete certificate.  There seems to be no 
> indication of the hash algorithm - perhaps it is always SHA-1.
> 
> I guess a certHash value is supposed to match the certificate 
> "fingerprint" or "thumbprint" that the browsers display.  A browsers 
> relies on a thumbprint unambiguously identifying a single 
> certificate.  OCSPv2, on the other hand, relies on a 
> certificate having a unique certHash value.  These properties - 
> unambiguity and uniqueness - are quite different.  It is reasonable to 
> assume a certificate thumbprint is unambiguous, but it is dangerous to 
> assume it is unique for the certificate.
> 
> There are a number of ways to alter the encoding of the unsigned 
> portion of a certificate (signatureAlgorithm field, signatureValue 
> field and outer most tags).  Such modification don't alter the signed 
> portion so the signature remains valid, but they do change the 
> thumbprint.  An attacker can modify the bytes (hence thumbprint) 
> without modifying the semantics of a certificate.
> 
> For instance, consider omitting the NULL signature parameters 
> associated with sha1WithRSAEncryption in the signatureAlgorithm 
> field.  It is not unreasonable for a system to still accept such a 
> certificate (particularly with the "be strict with what you send but 
> lenient with what you receive" philosophy).  Yet the bytes do change 
> so the thumbprint also changes.
> 
> An OCSPv2 responder may have one thumbprint of a certificate in its 
> table of revoked certificates, but would return "good" if a different 
> thumbprint for the same certificate appeared in the certHash field.
> 
> A better thumbprint (that is unique for a certificate) is a hash over 
> only the signed portion of the certificate (i.e. the same hash that 
> goes into the signature).
>

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 26 Mar 2001 16:51:23 -0800

James,

A good catch.  Thanks for taking the time to read the OCSPv2-02.

I was convinced to include certHash among the ReqCert CHOICEs based on a
projection that some PKI-using environments may find this form of
certificate identification more useful to their needs than others,
particularly those that are bandwidth-constrained.

You propose that a hash over the signed portion of the certificate (i.e. the
same hash that goes into the signature) would eliminate the risk you've
identified.  I'll take any opportunity I can to simplify the protocol;
deleting certHash as a ReqCert option certainly addresses that design
objective.  At this point though I'd prefer to maintain certHash a option
but composed in the manner you describe.

This would at a minimum separate out the security of this mechanism from the
question of whether or not this mechanism, even though secure in its
specification, provides sufficient value to warrant the additional
complexity in the protocol.

Mike