1 / 9

IGTF Distribution Process: Common Naming, Trusted Authorities

This article discusses the IGTF distribution process for registered CAs, including formats, distribution management, and trust. It also explains how downstream vendors, such as EGEE/LCG, utilize the distribution.

carloso
Download Presentation

IGTF Distribution Process: Common Naming, Trusted Authorities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The CA Distribution ProcessDavid Groep, July 2007

  2. 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. 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 locationhttps://dist.eugridpma.info/distribution/

  4. Implementation YT MK DG AW MH • CVS Repository • ssh access for committers only • web access for IGTF members DG • Buildhost • local network only to CVS, dist • PGP signing key on USB flash(stored in safe when not in use) YT DG https://dist.eugridpma.info/ ssh only from local network http/https/rsync from anywhere no other services, apache serves static content only

  5. 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. CVS browsing

  7. 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. 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 basevia their standard list(in the EUGridPMA, that’s the “announce@eugridpma.org” list) • Downstream vendors pick up the distribution

  9. 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: • the CA liaison (me) to build the lcg-CA RPM metapackage • the SAM/SFT developers to update the site functional tests • the middleware integration team to upload to the pre-prod repository and test the release again • 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 • 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

More Related