Soapbox (S-Series) Certificate Validation Jens Jensen, STFC

I&A Identification - The process of establishing the identity of an individual or organization, i.e., to show that an individual or organization is a specific individual or organization. In the context of a PKI, identification refers to two processes: (1) establishing that a given name of an individual or organization corresponds to a real-world identity of an individual or organization, and (2) establishing that an individual or organization applying for or seeking access to something under that name is, in fact, the named individual or organization. A person seeking identification may be a certificate applicant, an applicant for employment in a trusted position within a PKI participant, or a person seeking access to a network or software application, such as a CA administrator seeking access to CA systems.

Dramatis Personae Subscriber: responsible for certificate – Creation, handover to Subject, renewal/rekey Subject: using the certificate – according to permitted purposes RA (operator): verifying Subject info E.g. personal: Subject == Subscriber; Host or robot: Subject != Subscriber. RFC3647 is wrong: – Subscriber - A subject of a certificate who is issued a certificate.

Managed Keys Policy Subscriber (= key repository) – Generates and protects keys – Ensures that only Subject can use key Who generates the CSR? – Repository signs stuff, eg. proxy certs – A CSR needs signing, too – 1: Generate CSR with key, ignore the name in the CSR? User01, User02,... – 2: Let users create their own CSRs

Managed Keys Policy Use of repository for: – Key generation – hand over to Subject – Key generation and key archiving – Archiving and signing service (e.g. proxies) – Signing, and escrow? A repository can be many things – Will it not be best to assume: – Generation, storage, signing-at-user’s-req.

Certificate Validation Name of Subject represented in DN – (Using printableString encoding) Subscriber is in possession of private key Request originates from Subscriber Subject is entitled to a certificate (of given type) Certificate profile reflects the purpose Lifetime is right

OID in Cert CA must know how key was generated and protected Key is subject to CA policies... how does it know? An RA must assert it...

Look at RA processes... Bearing in mind: – Users, hosts, and users-with-managed-keys Bearing in mind: – The differences between MICS, SLCS, and Classic Bearing in mind: – Subject, Subscriber, RA are already different roles

RA Process Multistage process: – Identification of Subject – Recording audit trail of identification (maybe) – Recording association of identification with request – Checking Subject entitlement – Authentication of Subscriber – Association of Subscriber with request – Subscriber possessing private key – Checking protection of private key (maybe) – Collecting “private questions” (MICS) And – Revoking key (cert) when necessary – Authorising renewals and rekeys

RA Processes Some processes already delegated – E.g. MICS – Delegation: loss of auditability Some processes can be automated

Kirkhoff’s Law

RA Process Features Throughput Redundancy/availability Skills Data Protection compliance Integrity Compare DutchGrid’s “dumb” RAs And UK’s split RAs

What is this about... To make progress, we need to – Understand the processes of Subscriber – Understand the processes of RA Enable splitting roles, e.g., – Multiperson processes on validation Either split roles, or two-person validation – Record the steps... In an auditable form (for some steps) – Enable automating roles? Delegating? Understanding the consequences of linking steps

Issuance Can continue: look at all the services of the CA E.g. “outsourcing” the certificate issuance – TCS, SWITCH – National CAs still carry on with hosts Outsourcing the identity management... – MICS, SLCS Where is the CA...? – The CA is a PMA – Note about responsibility, e.g. for data protection

IdM If we link IdM to identity processes... – What are the implications of linking IdM to repository? – Federated identity management – home id generates (or at least activates) credential; MICS – “Entities possess and control their key data”