1. Zeepkist Jens Jensen STFC SurfNet, Utrecht, 24-26 Jan 2011

2. Contents of the Talk Compliance Level of Assurance The Warm and Fuzzy –W&F appears in every talk! Private key protection (as example)

3. Quote of the Day "Errors really aren't all that serious and you should be allowed to, like, chill man and just groove with the heavy consequences, dude." --Damian Conway in Exegesis 4 (p. 3) [very much taken out of context!]

4. Quote of the Yesterday “Must comply with the requirements” “… or we devalue the whole thing”

5. Compliance with What? IGTF, PKIX, X.509 PKIX > X.509 –E.g. single-set RDNs IGTF > PKIX –E.g. printableString names APs, GFD.125, minreq

6. Changing a CA Compliance Non-Compliance Level of Assurance Warm and Fuzzy High Low Warm Cold

7. Changes Compliance is better than non- compliance Higher LoA is better than lower ? –Up to a point? Warmer and fuzzier is better –Right?

8. Changes Self-reviewed, in a sense –If you build it, you review it (sort of) The role of reviewers –Post-change assessment –Pre-change assessment? What if changes are hidden?

9. Change Approval Survival of the noisiest –Silent acquiescence Just vote yes Just do it

10. Change Management (IT) Project Management –Planning, resources, etc –Depending on size of change People –DREC –And the curse of DREC

11. “Trust No-One” Can you trust X to run a CA? Assessor –Relationship and independence (cf RFC3647 8.3) –Qualifications (8.2) Can you trust yourself…? Audited *anything* is more trusted –Particularly by a trusted auditor

12. How much do we need to trust you to trust no-one? Small stuff: can decide for yourself –Eg repository publications Bigger stuff: need advice if unsure –Eg cert extensions Even bigger: probably need advice –CP/CPS update, CA software Biggest: advice from group of experts –Initial accreditation

13. Non-Compliance A: actually it is probably OK B: really ought to fix eventually C: fix at next given opportunity D: fix sooner than that “In case of non-compliance, the CA manager must announce plan for addressing the issue.” (or similar)

14. The Scale of Cs How serious is non-compliance? –E.g. 393 days vs 395 days (Reimer) –RFC3647 vs RFC2527 Assessor and reviewer often disagree –Not always A>R, sometimes A<R –Implications for normal operations?

15. The Role of Understanding Understanding stuff takes time Insights take even more time Toxicity of RFC2119 SHOULD –IGTF-SHOULD is healthier –Consequences are bounced off the PMA

16. A Deo Rex, A Rege Lex Where do changes come from? Who can request a change? Can they request change for any reason?

17. Change happens, too Cold and distinct

18. Change happens, too Technology and related –Eg hardware tokens RP reqs –Compare global requirements with national –Biomed with physics

19. Change happens, too Boo boos –Fixing mistakes –Embarrassing, but necessary The “??”

20. Change Change is good –The world is not static –We need to move with it Change is bad –Difficult to implement globally 6 months unrealistic –Babies and bathwater

21. Change What are babies and bathwater? –Losing something we had But may not have known we had? –“Oops legislation” Not understanding consequences Not grokking the issues

22. From Istanbul (Soapbox) 1.Protection of private key 2.Validated parts of the DN 3.Security of identity vetting 4.Types of auditing (frequency, thoroughness) 5.Purpose of certificate 6.Protection of (CA) infrastructure

23. The LoA

24. Understanding the risks and impact Compliance with law etc Federations Dependence on technology Independence of technology The role of technology The role of usability

25. Identity Vetting 1.Maintain uniqueness of DN –Resolve name clashes –Affirm links to previous names 2.Auditable records of issuance 3.Maintained within scope of CA (eg DPA) 4.Maintain fully traceable links to user –Provide potentially legally binding docs

26. Goodenoughism Authenticating people at CERN –Initial –And re-authenticating Setting up RA at JAC… –Even if members of STFC

27. Identity Vetting “but I know the user personally” –Loss of auditable records “I know someone who can verify the user” –No formal links to CA

28. Maintenance of Links Continuous or regular (eg at rekey) Auditable verifications

29. The Private Key What is is? –Something you have –Something you know What it is for? –Proving that you have it –Without revealing information about it (ZK)

30. What problem? Users: certificates difficult to manage Slightly clunky key changeover? (rekey) –Renewal also clunky, for different reasons (But not with the cert wizard!) –MyProxy integration should ensure freq.

31. What is the solution? (Further than Jim B’s proposal) Remove key handling from users? Do not use X.509? –Other ZK? Probably don’t need ZK if key prot’n strong –Other two-factor? Still need two factor –Or we lower the LoA

32. Goodenoughism example 1 year proxies in MyProxy –Escape the eeevil clutches of the CA –Now cannot revoke the credential –Trouble at rekey, original p’key needed

33. What is Key Handling? 1.Generation of key 2.Delivery (-ies) 3.Storage (in protected form) 4.Activation 5.Deactivation 6.Destruction Auditable Audited

34. What is the problem with managing keys? 1.Key generation => provable 2.Key delivery => N/A 3.Key activation => single factor 4.Who can run a repository? 5.Purpose of certificate –Authentication vs digsig and nonrep

35. Do constrained envs help? Grids require: –Authentication –Digital signatures Grids do not require: –Anything else Normally

36. The Private Key Protection Problem Support existing purposes Maintain the LoA –Or increase the LoA –Need two factor authentication (tokens) Can the problem be solved? –Maybe –Does need careful thinking and review

37. The Private Key Protection Non-Problem Accept a formally different (lower) LoA RPs will take it anyway, they take anything :-P

38. The Repository Question Repository for proxies Or private keys Distinction: –Lifetime of credential –Revocability of credential

39. Who can run a repository? The CA? The infrastructure provider? The security chappie for a project? The student, under the desk? Probably similar to req’s for running AA

40. Who can run a repository? Locally (ie user generated) –Users own key, only Home organisation “Third party” –Not the CA, surely CAs MUST not generate keys for users(?)

41. Final slide (no really) A conclusion of sorts –Anthropology: CAs are people too –Quixotic quest against goodenoughism? Canwedobetterism –At the end, not so worried about lack of understanding –Worried about the silent majority?