the ca distribution process david groep july 2007 l.
Skip this Video
Loading SlideShow in 5 Seconds..
The CA Distribution Process David Groep, July 2007 PowerPoint Presentation
Download Presentation
The CA Distribution Process David Groep, July 2007

Loading in 2 Seconds...

play fullscreen
1 / 9

The CA Distribution Process David Groep, July 2007 - PowerPoint PPT Presentation

  • Uploaded on

The CA Distribution Process David Groep, July 2007. 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. IGTF Distribution and Formats.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'The CA Distribution Process David Groep, July 2007' - ciara

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • 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
igtf distribution and formats
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 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






  • CVS Repository
  • ssh access for committers only
  • web access for IGTF members


  • Buildhost
  • local network only to CVS, dist
  • PGP signing key on USB flash(stored in safe when not in use)



ssh only from local network

http/https/rsync from anywhere

no other services, apache serves static content only

getting into cvs eugridpma process
Getting into CVS (EUGridPMA process)
  • Supply all information specified at
  • 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 …

building the distribution
Building the distribution
  • See
  • 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
  • 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 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 “” list)
  • Downstream vendors pick up the distribution
a downstream vendor egee lcg
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