1. A Survey of Certificate Management Processes and Procedures in OSG Gabriel Ghinita and Mine Altunay {gghinita,maltunay}@fnal.gov

2. Goals  Understand CA similarities/differences  Request, renewal, re-key, revocation, vetting  Policy and technical factors  Improve usability  Identify features that should be part of a desktop certificate management tool  Assess the feasibility and attempt to define guidelines for development of such a tool 2

3. Methodology  Sample of 10 CAs  Counted CAs with 100+ users (grid-mapfile)  Also included additional US-based CAs (NCSA)  All but one (Fermilab) issue long-lived certs  Process data collected from CPS  Disclaimer: did not go through actual process of request, vetting, etc 3

4. CAs Surveyed  Fermilab KCA  DoEGrids  CERN  GridKA  INFN  UK e-Science  Grid2-FR  GridCanada  IrisGrid  NCSA 4

5. Identity Vetting  Vast majority of CAs employ RAs  RAs are separate entities  Typical requirement: physical presence at RA  Details vary with RA (type of documents, proof of token used at cert request time)  Organization-level CA  Badged users already vetted  Organization account (plus some second “factor”)  Fermilab (SLCS), CERN, NCSA 5

6. Certificate Request  Case 1: partial client support  web interface or GUI/command-line tool available  organizational vetting: immediate issuance  RA-based  users need to figure out RA and the correct DN  certificate retrieved later, using same machine and browser  Case 2: almost no client support  Users have to master openssl/grid-cert-request  Even less support for getting the DN right  Once users get the cert, plenty of work to import it into browsers, etc. 6

7. Certificate Re-key  Most CAs accept re-key  Almost none accept renewal or modification  Some (e.g., organization-level CAs) just do a re-request  Process:  New CSR is issued, signed with both the new key as well as the old key (if existing cert still valid)  Web interface to upload CSR, otherwise e-mail  RAs only need to approve request (eligibility) 7

8. Certificate Revocation  Most CAs accept on-line revocation  Revocation request is authenticated (signed) with the key of the certificate to be revoked  The revocation request is uploaded through a secure web interface (e.g., DoEGrids) or by e-mail 8

9. Shortcomings  Need for technical expertise  PKI is not a straightforward technology  Difficulty in understanding/handling public/private key pair  Need to import CA certificate to browser, etc  Administrative details cumbersome  How to set up the DN?  Wrong DN setting delays application  Certificate Usage: basic functionality not provided  Import into/export from web browsers, e-mail clients, etc  Ensure that key is stored encrypted 9

10. Objective: Improve Usability  Tool to support multiple/most/all(!) CAs  CA-related operations  Request, rekey, revoke certificates  Client-side operations  Proxy generation  Certificate store operations (MyProxy)  Integration with client-side software  Web browsers  E-mail readers  Grid tools 10

11. Existing Tools  jGridstart (NIKHEF)  Request, renewal, assists in vetting (generates forms)  Import into web browser  Export to file (PKCS#12)  NGS Certificate Management Wizard  Proxy generation (including voms-proxy)  Upload proxy to credential store (MyProxy)  Requires certificate in the filesystem (PKCS#12) 11

12. Recommendations  CA-related Processes  Technical process identical (X509)  Parameters may differ, use config files (openssl. cnf already does this)  Config files may be shipped with middleware (e.g., VDT)  Identity attributes included in CSR very similar  Name, Organization, e-mail  Customize required input for vetting  Use configuration files for form generation – not technically challenging  Most difficult task: client-CA protocol  Currently interactive web forms  Extend to web services: hopefully re-use existing server-side code 12

13. Recommendations (2)  Client Software Integration  Web browsers: Mozilla already solved (e.g., Fermilab get-cert)  Some difficulties with more exotic browsers – but CA-independent  Proxy generation/proxy upload  NGS tool already provides this  Merging jGridstart and NGS Cert wizard represents a good start to comprehensive functionality  Supporting organization-level vetting  Some code already exists (kx509 at Fermi, NCSA scripts)  This can represent an independent branch of the code  Possibly interface with existing tools, without having to integrate within single application 13

14. Q&A 14