Presentation is loading. Please wait.

Presentation is loading. Please wait.

Document update - what has happened since GGF11

Similar presentations


Presentation on theme: "Document update - what has happened since GGF11"— Presentation transcript:

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

2 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)

3 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

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

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

6 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.

7 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

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

9 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

10 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)

11 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

12 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

13 Next steps Open issues

14 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}

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

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


Download ppt "Document update - what has happened since GGF11"

Similar presentations


Ads by Google