1. Proposal for a server certificate service Towards large-scale usage of affordable popup- free server certificates for the European Research & Educational community Amsterdam, 3 November 2004 Jan Meijer Christoph Graf Olaf Gellert

2. 2 A What? A service (NOT a PKI, NOT a CA) to provide popup free x.509 server certificates for a flat rate for the NREN (and the site?) to the servers' admins with as little hassle as possible

3. 3 Why server certificates? To enable ubiquitous encrypted SSL/TLS channels towards the end user without harassing that that end user with the nitty gritty details: –PKI as an enabler for these ubiquitous encrypted channels Because these are what sites are willing to implement, at this point in time

4. 4 Why do it this way? Our currently available solutions are not popup-free or not flat rate or hurdle-bound

5. 5 Vision thing To make it normal to use a server certificate, as normal and easy as it is to setup a webserver Read: to make it lame to not use encrypted channels where you should To make it normal to use this security tool it needs to be easy and readily available

6. 6 Suggested technical architecture (1)

7. 7 Technical Architecture (2)

8. 8 Organisation of the trust fabric

9. 9 Architecture keywords Distinguish between technical and organisational implementation of trustfabric! Ease of use: –for the certificate requester –for the site's RA –for the NREN RA –for the service maintainers Hurdle-free: no 'this is hard, I'm not going to do this' moments during the whole process from the point of view of the certificate requester One technological platform branded multiple times 2/3 well-trained persons at each site

10. 10 Trust-fabric keywords We know our customers (contractual relationship) The contactpoints within our customers do not change that frequently (stable trustfabric) Establishing the trustfabric is expensive, running it not NREN takes care of organizing its constituency in the way best suited for their local circumstances Service takes care of central RA platform For the NREN mostly an organising effort, the service takes care of technology Flexibility is possible, but costs

11. 11 Suggested roadmap Get group & budget together (Dec 2004) –(DFN, RedIRIS, SURFnet, Switch already said 'yes' :) Start process to acquire service (Dec 2004) –(SURFnet, TERENA, Switch, DFN-PCA) Sign contracts (April 2005) get service up and running & assist participating NRENs in getting their RA up and running Service available July 2005 Evaluate after one year and decide on future

12. 12 Discussion: assumptions Popup-free? Popup-free for IE only? Flat-rate? -Each NREN is best equipped to create the proper level of RA delegation needed for its' own community, many NRENs will already have a delegated contactperson structure in place which is supported by (legally binding) contracts; -The technology exists to enable NREN-specific 'branding' of the proposed service; -Combined buyingpower plus our position in the academic world will allow us to acquire and thus provide the service cheaper through a consortium of NRENs; -TERENA is properly equipped and positioned to facilitate such a consortium.

13. 13 Discussion: Financial model Fixed annual fee per participating NREN One-time fee for joining the service is acceptable –setting up things, training people etc. Start with equal shares, differentiate to size of NREN after service is a succes

14. 14 Discussion: Architecture Each request is authorized by the NREN-RA? The NREN-RA takes care of initial setup of the trust-fabric, after that, each site-RA 'issues certificates'? ?

15. 15 Discussion: Organisation TERENA as the legal body to carry the contract Need some way to control the service Need some way to get for the participants to influence the service The Trusted Introducer model (?) –TERENA carries the contract –'management board' makes sure the service is properly taken care of and talks with contractor –service-participants can elect participants in this board