1. TERENA Certificate Service (TCS) September 2014

2. SCS,TCS,TCS-II – the ten year road to simple unlimited certificates › Back in 2004 many NRENs had set-up a CA - but these certificates issued were not trusted by web browsers (the ‘ pop-up ’ problem) ›Buying large numbers of certs one-by-one is slow, tedious, and expensive – so leads to people inventing ‘self-signed’ certs or leaving services insecure (web logins, imap, radius, …) ›So why not leverage the combined power of many to make a simple and affordable service – which is what Jan Meijer started at a TF-AACE meeting in 2004! Slide 2

3. A long (but rather successful) road Slide 3 IDEACfPcontract signed with GlobalSign Start of SCSContract renewed 2 nd CfP contract signed with Comodo Start of TCSStart TCS eScience End of SCS Contract renewed 3 rd CfP DigiCert selected as TCS partner Start of new TCS End of Comodo TCS service

4. Slide 4 NREN/CountrySPC SPC ACOnetAT  LITNETLT  - BELNETBE  UoMMT  - CARNetHR  --SURFnetNL  CyprusCY  UNINETTNO  CESNETCZ  -PSNCPL  UNICDK  -FCCNPT  -- FUNETFI  -RoEduNetRO  - RENATERFR  -AMRESRS  - GRNETGR  -ARNESSI  -- HUNGARNETHU  --RedIRISES  HEAnetIE  SUNETSE  GARRIT  -JANETUK  -- IUCCIL  -EENETEE  - Participants today

5. Slide 5 ›Five types of certificate available: ›Server Certificate - for authenticating servers and establishing secure sessions with end clients. ›e-Science Server Certificate - for authenticating Grid hosts and services. These are IGTF compliant. ›Personal Certificate - for identifying individual users and securing e-mail communications. ›e-Science Personal Certificate - for identifying individual users accessing Grid services. These are IGTF compliant. ›Code-signing Certificates - for authenticating software distributed over the Internet. Certificate Types today

6. The TCS structure ›TERENA is the ‘owner’ of the certificate services, which is procures on behalf of the participating NRENs (TERENA members) ›It sources the issuing service from a commercial CA service provider and sets the requirements ›Via the tender/RfP requirements ›Via updates to the CP/CPS ›NRENs then act as the user-facing end of the service ›They may re-brand or co-brand the service ›They can (or could) define some of the processes ›All have to agree to the same CP/CPS ›The TCS PMA controlling the CP/CPS is comprised of experts from across the community Slide 6

7. Interesting elements ›By its intention, the TCS CAs should ›Be publicly trusted in all major (mobile) systems ›Use mechanisms that scale to the European R&E community ›Don’t burden the subscribers (institutions) too much – in particular for auditing ›Preserve under TERENA’s control key elements that ensure continuity (no vendor lock-in) – for eScience, this means e.g. the subject namespace ›but of course not everything is under our control ›Changes to baseline requirements affect us ›Server certs are more tightly controlled than personal Slide 7

8. Delegated Responsibilities & Scaling

9. Built using contracts scales well to large numbers of organisations and users assurance requirements on subscribers ensure quality ID bound through legal contracts

10. Slide 10 ›Several NRENs decided to pool resources and operate common portal for personal certificates. ›Utilises mainly Confusa software (for personal) and Djangora (for server) ›Hosted on resilient servers at Tilburg University under contract to TERENA ›Some NRENs use directly the Comodo portal … and sometimes show ‘interesting’ certs as a result  ›For personal certs ›Each NREN community needs to operate at least one IdP, but multiple IdPs are supported ›Delivered only via federated mechanisms Current TCS delivery mechanisms

11. Towards a new TCS ›RfP process ›Initial market consultation to see is there was commercial interest in bidding on a future contract ›Made sure the requirements were ‘doable’ ›RfP requirements ›Explicitly include the eScience & IGTF needs ›Learn from previous experience and look forward to potential needs in the developing AAI space ›Keep an option for specific trust anchor hosting (our thinking was for things like Robots, SLCS services, STS translator services, …) Slide 11

12. The new TCS Make migration (also for eScience) easy ›Start early with pilots (about now) ›Transition period until June-2015 ›Old certs remain valid for their entire ‘life time’ (including revocation capability) ›Same namespace for subjects (but new issuing intermediates) ›We get OV (and now also EV) certs Details to be worked out over the coming months Slide 12

13. TCS for eScience certs Attempting a ‘painless’ transition ›keep the subject namespace (which is TERENA’s) /DC=org/DC=terena/DC=tcs… /C=XX/O=YY/CN=Given Surname ePPN@ishID ›intermediate and root CAs will change name, but services like VOMS can handle that ›Specific configuration hints will come through EGI ›It prevents the trouble that OSG had post-ESnet ›both hierarchies will operate in parallel ›Mid-2016 the last ‘Comodo eScience TCS’ will expire ›non-eScience server SSL certs will take till 2018 Slide 13

14. And while we’re at it ›eScience trust anchor will also be publicly trusted ›This is essential for portals that are user-facing ›Will pose some additional constraints on policy to comply with CABforum BR – but it’s worth it ›We do this today, so does not limit use cases ›Move to SHA-2 for intermediates and EECs ›In line with MS, Google Chrome and FF decisions no new SHA-1 EECs from publicly trusted CAs past 2016 allowed Slide 14

15. Transition ›We will need a revision to the CP/CPS ›aiming for January 2015 presentation ›it remains the same CA organisation (TERENA) so we consider this an update ›Two options ›Align TCS CP/CPS with supplier CP ›Extract registration practices and naming from current TCS CP/CPS and append to supplier CP/CPS (‘RPS model’) ›Keeping in mind ›eScience namespace to stay with TERENA ›leverage the public trust expertise from supplier ›don’t inadvertently shift a lot of audit requirements onto the NRENs or institutions Slide 15

16. Technical changes After presentation in January ›Security/operational audit has already been done ›DigiCertAssuredIDRootCA-Root is already in ›Plenty of external auditing done ›PMA to endorse the updates to the CP/CPS or RPS ›Introduce new intermediate trust anchors ›Additional namespace for DigiCertAssuredIDRoot ›New intermediates ›Fully operational early 2015 ›Testing is going to start soon! Slide 16