Subject: Re: [Spasm] RFC 6960 CertID hash algorithm mismatches

From: Matt Cooper <[email-masked]>
Date: Tue, 20 Dec 2016 15:24:02 +0000

I see interoperability, caching, and precomputation problems stemming from allowing CertID ->hashAlgorithm to be variable. Increasing the hash size bloats the responses with no tangible security benefit so I see no compelling reason for anything other than SHA1 to be permitted.

Does anyone has an opposing view?

-Matt

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Monday, November 21, 2016 4:27 PM
To: SPASM <[email-masked]>
Subject: [Spasm] RFC 6960 CertID hash algorithm mismatches

RFC 6960 (and RFC 2560 before it) includes a hash algorithm field in the CertID structure, as shown below.

CertID ::= SEQUENCE {
  hashAlgorithm           AlgorithmIdentifier,
  issuerNameHash          OCTET STRING, -- Hash of issuer's DN
  issuerKeyHash           OCTET STRING, -- Hash of issuer's public key
  serialNumber            CertificateSerialNumber }

However, neither includes any text that compels the responder to use the same hash algorithm in the response as the requestor used in the request.
This seems like an oversight. If this is not required, OCSP clients would potentially need to calculate multiple sets of hash values in order to find the status in response.

RFC5019 requires clients to use SHA1, but it also requires nothing in terms of requiring responses match the CertID value and places no similar
SHA1 requirement on the responder. Simply requiring responders to also use
SHA1 seems like the easiest fix.

Is this something LAMPS could address with an errata?

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Dec 2016 16:01:50 +0000

> I see interoperability, caching, and precomputation problems stemming from
> allowing CertID ->hashAlgorithm to be variable. Increasing the hash size
> bloats the responses with no tangible security benefit so I see no compelling
> reason for anything other than SHA1 to be permitted.
> 

Yes.

If the size of the OID is an issue, let's turn it into a one-byte IANA registry.

Requiring on SHA1 seems like a bad idea, especially in view of the fact that SHA1 certs are vanishing from the WebPKI.   Not being able to change algorithms without a complete restructuring *is* a bad idea.

---

From: Russ Housley <[email-masked]>
Date: Tue, 20 Dec 2016 12:14:11 -0500

> Requiring on SHA1 seems like a bad idea, especially in view of the fact that SHA1 certs are vanishing from the WebPKI.   Not being able to change algorithms without a complete restructuring *is* a…

Rich:

It is not the size of the OID, is is the size of the hash value.

The CertID structure is:

CertID ::= SEQUENCE {

So, each of the OCTET STRING values is the size of the hash.  The idea is to simply identify the certificate.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Dec 2016 17:20:27 +0000

> It is not the size of the OID, is is the size of the hash value.

I understand.  I was just trying to remove any objection.

We already see SHA2 being used "in the wild"

---

From: Rob Stradling <[email-masked]>
Date: Tue, 20 Dec 2016 22:28:54 +0000

> I see interoperability, caching, and precomputation problems stemming from allowing CertID ->hashAlgorithm to be variable. Increasing the hash size bloats the responses with no tangible security be…

+1.  Precomputation is already enough of a problem for CAs that use it 
and have high volumes of active certs.  I am definitely not in favour of 
multiplying that workload by the number of conceivable hash algorithms!

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.