1. The CA Distribution Process David Groep, July 2007

2. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 2 David Groep – davidg@eugridpma.org Aim  Common naming for all registered CAs in the IGTF  In a variety of formats as suitable for our larger RPs  Well-trusted  but backed by TACAR where available

3. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 3 David Groep – davidg@eugridpma.org IGTF Distribution and Formats  Apart from validation via TACAR, the IGTF manages a distribution of all accredited authorities  formerly known as Anders’ RPM set, today also available as: JKS, tar-gz, configure && make, …  usually built by the EUGridPMA (me, actually)  mirrored twice-daily to the apgridpma.org site  copied and re-distributed by downstream vendors (EGEE/LCG, VDT, …)  also contains the fetch-crl utility (now at version 2.6.3)  Download location https://dist.eugridpma.info/distribution/

4. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 4 David Groep – davidg@eugridpma.org Implementation CVS Repository ssh access for committers only web access for IGTF members YT DG AW MK MH Buildhost local network only to CVS, dist PGP signing key on USB flash (stored in safe when not in use) DG https://dist.eugridpma.info/ ssh only from local network http/https/rsync from anywhere no other services, apache serves static content only DG YT

5. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 5 David Groep – davidg@eugridpma.org Getting into CVS (EUGridPMA process)  Supply all information specified at https://www.eugridpma.org/review/registration  In a secure way (F2F, or electronic: trivial with PGP, or with designated personal cert off your existing CA for updates)  CVS-committer (me) re-checks this information  like a limited version of the operational review  basic sanity of the root cert and CRL URL  does the contact address work?  is namespace defined and exclusive?  generate the signing_policy.conf file  based on the data provided by the CA  in some cases, the CA provides the entire EACL file  generate the derived.namespaces file therefrom  except where the ‘namespaces’ file is actually better, or in case the signing_policy.conf syntax cannot express the policy  Yoshio, or you, may use a different process, i.e. rely on the results of the operational review, or rely on what the CA gives you …

6. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 6 David Groep – davidg@eugridpma.org CVS browsing

7. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 7 David Groep – davidg@eugridpma.org Building the distribution  See https://www.eugridpma.org/review/using-cvs  on a dedicated buildhost  so a CVS update will show all changes  review all modifications, check for sanity, and update the CHANGES file for the release  Update version file, build the distribution and post on a private web page so that everyone can comment

8. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 8 David Groep – davidg@eugridpma.org Announcements  New releases built in a coordinated fashion  pre-announcement to igtf-general  version number should increase monotonically  every committer could build (using documentation and the cabuild.pl script)  each PMA should PGP-sign the RPMs and other content, but if you just mirror you get the EUgridPMA key #3 signature  Build and upload to the distribution site, and then:  builder (DG) sends announcement to igtf-general  each PMA should announce to the subscriber/RP base via their standard list (in the EUGridPMA, that’s the “announce@eugridpma.org” list)  Downstream vendors pick up the distribution

9. 3 rd TAGPMA ‘Austin’ meeting – Nov 2006 - 9 David Groep – davidg@eugridpma.org A Downstream Vendor: EGEE/LCG with my EGEE SA1 hat on …  EGEE/LCG relies  on RPM and yum/apt for distribution  on fetch-crl for CRL download and management  on SAM/SFT for site monitoring and consistency follow-up  EGEE security and release process coordinators are subscribed to the eugridpma-announce list  on release, trouble ticket is entered in system (GGUS) which triggers: 1.the CA liaison (me) to build the lcg-CA RPM metapackage 2.the SAM/SFT developers to update the site functional tests 3.the middleware integration team to upload to the pre-prod repository and test the release again 4.when SAM/SFT update is done, the MW release team migrates the RPMs to the public EGEE repository and announces the update to the sites 5.All sites than have 7 (or 1) days to update. While they are not updated, SAM/SFT test show WARN  After 7 (1) days error becomes critical and site is blocked by most VOs http://goc.grid.sinica.edu.tw/gocwiki/Procedure_for_new_CA_release