Subject: Hash algorithm agility as prerequisite for progression to draft standard

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 7 Apr 2006 10:25:15 +0100

As my first official act as WG chair I would like the general opinion of
this working group about to what extent we should to solve hash
algorithm agility before we progress documents from proposed to draft.

This question needs to be addressed in general but it is of particular
relevance for OCSP, RFC 2560 where we on one hand do have hash algorithm
agility issues to address but on one hand have a growing adoption by
multiple independent implementations that form a reasonable base for
compliance testing.

Stefan Santesson

Program Manager, Standards Liaison

Windows Security

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 7 Apr 2006 08:58:57 -0800

Well, our work certainly won't be done until we address the issue.  I would
however like to minimize the impact on extant implementations and
compliance/interoperability testing that has been done to date.  To that
end, I will start another thread on this subject specific to OCSP.

Mike
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Stefan Santesson
  Sent: Friday, April 07, 2006 1:25 AM
  To: [email-masked]
  Subject: Hash algorithm agility as prerequisite for progression to draft
standard

  As my first official act as WG chair I would like the general opinion of
this working group about to what extent we should to solve hash algorithm
agility before we progress documents from proposed to draft.

  Stefan Santesson

  Windows Security

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 7 Apr 2006 11:56:13 -0800

All,

Apologies in advance for the length of this post, but this issue is a bit
complicated.  It is further complicated by OCSP's ever-increasing installed
base and corresponding interoperability/compliance testing.  I will first
establish some context for those not familiar with the protocol's syntax.
Then I will discuss the meat of the matter and offer some proposals for WG
consensus.

As Russ noted in Vancouver, hash algorithm agility is relevant to OCSP as
follows (in my own abbreviated syntax):

(1)  Optional signature in request
----------------------------------
OCSPRequest
   optionalSignature
      signatureAlgorithm
      signature

(2) Identification of target certificate in request
---------------------------------------------------
OCSPRequest
   tbsRequest
      requestList
         reqCert  (i.e. CertID)
            hashAlgorithm
            issuerNameHash
            issuerKeyHash
            serialNumber

(3) Signature on a definitive response
--------------------------------------
BasicOCSPResponse
   tbsResponseData
   signatureAlgorithm
   signature

(4) Identification of target certificate in response
----------------------------------------------------
SingleReponse
   reqCert  (i.e. CertID)
      hashAlgorithm
      issuerNameHash
      issuerKeyHash
      serialNumber

(5) Identification of responder
-------------------------------
ResponderID
   byKey
      keyHash  -- SHA-1 identified as algorithm to be used

DISCUSSION
----------
(A).  With respect to (1) and (2) above, Russ noted in Vancouver that while
it is self-evident these structures can accommodate new hash algorithms,
there is no way for a requestor to know beforehand which among potentially
several candidate algorithms will be implemented at the responder.  In
Dallas we discussed reliance on the content of a Responder's certificate,
which a requestor must eventually possess in order to validate the signature
on a definitive response.  The key word here is "eventually".  As Tim noted
in Dallas, certain deployments of OCSP may be operated in a manner whereby
the requestor is not in possession of the responder's certificate when the
request is transmitted.

(B).  In (3) and (4), Russ asserted that these "two parts look fine in their
use of a hash function."  I concur.  There is of course the risk that the
hash algorithm used by the responder in these two instances would not be
found acceptable to the requestor.  But one must presume that having gotten
past the responder capability discovery issues inherent in (A), the
subsequent response would utilize the hash algorithm specified and used in
the request.

(C).  Item (5) is problematic in that the text of RFC2560 locks in SHA-1.
Its not declared normatively in a SHALL or MUST sense, but simply as an
ASN.1 comment.  Nonetheless, that's the guidance as written.  This clearly
needs to be fixed.

(D).  Finally, there's the issue of advancing RFC2560 from Proposed to
Draft.  2560 has been at Proposed since 1999.  Since then, numerous
independent implementations have come to exist and
interoperability/compliance testing has been performed.  Thus the time has
come to consider promoting 2560 to Draft.  Towards that end, I am in the
process of accumulating existing test data for production of an
Implementation Report in support of that promotion.  These tests were
performed against 2560 as written.  Promotion to Draft requires
demonstration that at least two independent implementations comply with all
MUSTs and, further, interoperate against those requirements.  It would be
most unfortunate if our resolution of OCSP hash agility were to invalidate
those efforts.

PROPOSALS
---------
(I).  Define an OCSP response extension that conveys to requestor: 1) the
request failed due to hash algorithm conflict; and 2) identifies the list of
responder-acceptable hash algorithms in support of a retry.  Requestors
SHOULD retain these results for future use when querying the subject
responder.  Thus the protocol is self-correcting with respect to hash
agility.  Because support of extensions is not MUST-level normative,
existing 2560 implementations and testing remain valid with respect to
2560's promotion to Draft.

(II).  Regarding discussion (C) above: 1) delete the ASN.1 comments
specifying SHA-1; and 2) add text advising that the hash algorithm
identified in CertID data item of the corresponding request MAY be
considered a hint on which hash to use to compute the value of keyHash.

Again, apologies for the length of this post.  I look forward to your
comments or consensus.

Mike