Future Directions for OCSP

1
Future Directions for OCSP

• Ambarish Malpani
• ValiCert Inc.
• 49th IETF San Diego

2
OCSP is Successful

• Very Successful Protocol
• At least 11 separate server implementations
• Many, many client implementations
• At least 3 large profiles based around it
• All this just 18 months after becoming an RFC!
• If it has worked so well, why do we think it is
  so broken that we need a v2?

3
Criticisms of CertID in OCSPv1

• Client needs to get the CAs public key before
  making the query
• Server needs to index CAs by the hash of their
  DN/public key, rather than the full DN

4
Why It is Important to Include hash(CAPublicKey)
in CertID

• If you are not including the entire certificate
  in the request, a server has no way of verifying
  that the CA a client refers to (via the DN) is
  the same as the CA it knows of. There is no way
  to guarantee globally unique DNs for CAs.
• The cost of adding the hash of the CAs public
  key is very, very small (OCSP does require you to
  have it)

5
Whats new with OCSPv2

• There are 5 ways of identifying certs
• CertID
• Hash(Cert)
• Cert
• IssuerSerial
• URL to Cert (or rather GeneralName)

6
Whats new with OCSPv2 (cont)

• There are 7 statuses
• Good
• Revoked
• Unknown
• Valid
• Invalid
• Suspended
• Expired
• Valid, Invalid and Expired should not be used

7
Conclusions

• OCSP is not broken lets not try to fix it!
• Adding 5 methods of identifying a certificate
  isnt adding to the security, simplicity or
  interoperability of the protocol.
• While CertID is not ideal, is isnt broken either
  why change it?
• Adding return states that cant be used by the
  protocol doesnt make sense (invalid, valid,
  expired)