1 / 10

OCSP Hash Algorithm Independence

In their analysis presented at IETF 63, Bellovin and Rescorla investigated OCSP's hash algorithm independence and the ease of transitioning to new hash functions. They found significant limitations across several protocols, highlighting issues with how hash functions are specified in OCSP requests and responses. Their proposed solutions include defining extensible options for acceptable hash functions and signature algorithms and enhancing responder capabilities visibility. A thorough review of PKIX protocols, alongside community involvement, is crucial for future improvements.

minna
Télécharger la présentation

OCSP Hash Algorithm Independence

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OCSP Hash Algorithm Independence Russ Housley 2 November 2005

  2. Bellovin / Rescorla Analysis • Bellovin and Rescorla gave a presentation at the IETF 63 Hash BOF • Analysis into IETF security protocols • Hash algorithm independence • Ease of transition to new hash functions • Many protocols were found wanting • They did not look at OCSP, so I did …

  3. Request – Independence Okay Two parts make use of a hash function: Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, issuerKeyHash OCTET STRING, serialNumber CertificateSerialNumber }

  4. Request – Transition Concerns • What hash function / signature algorithm is the OCSP Responder permitted to use? • If Request is signed, could expect the same on to be used by the OCSP Responder • If Request is not signed, could expect the same hash function to be used, but there is no hint about the signature function • Better if the Request listed the acceptable hash functions and signature algorithms

  5. What about the Responder? • How does the requestor know which hash functions and signature algorithms are supported by the OCSP Responder? • Three options: • Add optional query / response • Requestor can ask, and then cache the answer • OCSP Responder Certificate • Similar to SMIMECapabilities extension • Assume Requestor configuration • Fine for some deployments, but not others

  6. Basic OCSP Response (1 of 2) Two parts look fine in their use of a hash function: BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } SingleResponse ::= SEQUENCE { certID CertID, ...

  7. Basic OCSP Response (2 of 2) One place where only SHA-1 can be used: ResponderID ::= CHOICE { byName [1] Name, byKey [2] KeyHash } KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key -- (excluding the tag and length fields)

  8. Proposed Way Forward (1 of 2) • Define a non-critical requestExtension that indicates the hash functions and signature algorithms that are acceptable • Define a version 2 of the OCSP Basic Response that includes something like: ResponderKeyHash ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, responderKeyHash OCTET STRING }

  9. Proposed Way Forward (2 of 2) • Select the preferred mechanism for the Requestor to discover the Responder’s capabilities, and include it in the specification • All three choices may have uses: • Add optional query / response • Requestor can ask, and then cache the answer • OCSP Responder Certificate • Similar to SMIMECapabilities extension • Assume Requestor configuration • Fine for some deployments, but not others

  10. Conclusion • Need to perform Bellovin / Rescorla analysis on all of the PKIX protocols • Volunteers are needed to look at others …

More Related