Document update - what has happened since GGF11 OCSP Requirements Document update - what has happened since GGF11

Refreshener OCSP = Online Certificate Status Protocol (RFC2560) “Removes” burden of wide-area CRL distribution and update Clients still have to do path validation! Clients still have to know about all CAs! Reasonably lightweight request/response protocol carried over HTTP(S)

Trust model alternatives supported by the RFC CA signs responses Authorized Responder Dedicated OCSP signing key certified by issuing CA Trusted Responder Explicit, configured trust We propose to use a combination of #2 and #3, for a variety of reasons

Our OCSP service architecture site/organization boundary CA CRL cache CA OCSP client CA Trusted Responder OCSP client Trusted Responder Authorized Responder Authorized Responder

Revocation status of OCSP responder? Don’t OCSP-no-check extension Shortlived certificates Can be applied to any frequently validated certificate!

CA requirements SHOULD include service locator of authorized responder(s) in all issued certificates SHOULD certify authorized responders with ocsp-nocheck and OCSPSigning extensions SHOULD make sure authorized responders are updated immediately after e.g. CRL update.

Client Requirements Network connectivity Response caching Nonce Duh... but a strong motivation for trusted responder at site/org perimeter Response caching SHOULD If used, MUST be possible to limit Nonce SHOULD NOT

Trusted Responder architecture (NON-normative) Other Responder CRL cache (Re-)sign external responses? OCSP cache OCSP Responder OCSP client Responder interface request

Server requirements Signature key protection RECOMMEND use of HW SHOULD support for handling multiple signature certificates One per CA (Authorized responder) Transponder mode Do not resign responses, just forward them Preserves Authorized responder signature

Handling errors and “Unknown” responses Not covered by RFC Our suggestion: Interpret Unknown or error as “try next revocation source” If no next, treat it as Revoked with permission onHold ... unless otherwise configured (avoid DoS)

Responder(s) location discovery Via Service Locator (AIA extension) MUST Via Local configuration SHOULD be able to handle per-issuer granularity and provide a default Local configuration has precedence

Revocation sources MUST be able to handle both locally cached CRLs and querying OCSP responders Configurable which one to prefer over the other Different deployment scenarios

Next steps Open issues

Hierarchies CA Sub CA Result: Good Signature: ... CertChain: R1: CA Responder Sub CA R2: SCA Responder Result: Good Signature: ... CertChain: Subject=R2 Issuer=SCA ocsp-nocheck Subject=SCA Issuer=CA AIA={R1} OCSP client Trusted Responder Subject=John Issuer=SCA AIA={R2} Issuer=SCA Serial#=1234 AIA={R2}

When should a trusted responder resign an OCSP response? Always Only if response is from non-authorized responder Never

HTTP or HTTPS? Responses are signed Error messages are not Suggestion: HTTP