Assuring e-Trust always 1 Status of the Validation and Authentication service for TACAR and Grids.

Assuring e-Trust always 2 Summary  OCSP Requirements for Grids  CertiVeR’s features –OCSP Client –OCSP Service  Future  Questions

Assuring e-Trust always 3 OCSP Requirements for TACAR  Centralized OCSP service for all the hierarchies  Centralized root certificate management  The service should be able to sign the response for each CA with an authorized certificate (Authorized responder mode)

Assuring e-Trust always 4 OCSP Validation for Grids  Grids special requirements for OCSP services: discoverable, fault tolerant, low latency, CA interoperability, etc.  GGF´s CAOPS-WG has been working in the document “OCSP Requirements for Grids”.  Such document provides information on: –OCSP Client Requirements, –OCSP Responder Requirements, –CA/Certificate Issuer Requirements and –OCSP Service Architecture.

Assuring e-Trust always 5 Client current status

Assuring e-Trust always 6 OCSP Client requirements for Grids A. Revocation source requirements: 1.Several sources (OCSP, CRL, AIA) and query order. B. Fault-tolerant requirements: 1.Multiple service invocation. 2.Caching of OCSP Responses. C. Security requirements: 1.Nonce usage. 2.OCSP Request signing. 3.Adoption of http and https. D. Error handling (i.e. Try Later, Respond with final status, etc.) E. OCSP Extension handling. F. “Unknown” status code handling for Proxy and Non-Proxy Certificates.

Assuring e-Trust always 7 GridOCSP Client API - features  Open source code for Globus TK 4 about to be released.  Implements a XML-based OCSP Policy that supports:  The policy file used by our client allows for the definition of per- Issuer rules or a default behavior for each feature.  Each VO could place such file on a specific URI for all its clients A.1 Several revocation sourcesOCSP only, others 4Q 05 A.2 Adoption of http and httpsYes B.1 Multiple service invocationYes B.2 Caching of OCSP Responses4Q 05 C.1 Nonce usageYes C.2 OCSP Request signingYes D Error handlingYes E Extension handlingYes F User proxy certificate handlingYes

Assuring e-Trust always 8 GridOCSP Client – policy definition e.g. (I)

Assuring e-Trust always 9 GridOCSP Client – policy definition e.g. (II)

Assuring e-Trust always 10 Server Current Status

Assuring e-Trust always 11 OCSP Responder requirements for Grids A. Performance: 1.Scalability: To cover for growth in terms of Client requests. Revocation sources. 2.Use of cryptographic hardware. B. Flexibility: 1.Revocation source requirements. 2.Support different operation modes: 1.Transponder mode. 2.Trusted Responder mode. 3.Authorized Responder mode. 3.Coverage of proxy certificates revocation is a recommended feature. C. Reliability 1.Fault-tolerance is a recommended feature.

Assuring e-Trust always 12 OCSP Service client scalability and reliability  Intrasite –Using balanced NAT  Extrasite –Using balanced DNS with very low persistence

Assuring e-Trust always 13 OCSP Service – revocation source scalability OCSP Responder Cert Status Database CAs ∆CRL CA/RA CRL Updater LDAP CRLCRL Cert Status  CertiVeR v4 can set N Updater processes in order to push DeltaCRLs from the CAs

Assuring e-Trust always 14 OCSP Service – Flexibility Courtesy of CAOPS-WG

Assuring e-Trust always 15 New CertiVeR service available !  A new service - CertiVeR v4 - has been implemented covering the required features for Grids. Such service has just passed the Beta tests and it is available at: – –  Current features of the new service: A.1 ScalabilityLimited during pilot A.2 Use of cryptographic hardwareNot during pilot B.1 Revocation source requirementsYes B.2 Operation mode (Trusted, Authorized and Transponder) All except Transponder mode during pilot B.3 Coverage of proxy certificatesYes B.4 Extension handlingYes C.1 Fault-toleranceNot during pilot

Assuring e-Trust always 16 The next steps...  Release of client open source code  Dissemination and Validation of the service –Provision of pilots for Grid and Tacar CAs  Technical improvements –Addition of servers in order to improve scalability and fault-tolerance –Use of cryptographic hardware –Setting up of Transponder connections –DeltaCRL push mechanism to be directly provided to each CA

Assuring e-Trust always 17 For information about revocation services, try our demo at: