Category: technical documentation
Status: DRAFT
Document: 533582878
Editor: David Groep - Michael Helm
Last updated: Wed, 09 March 2016
Total number of pages: 13
IGTF Distribution Process
Abstract
This document describes briefly the process of building and distributing the IGTF trust anchors.
Table of Contents
1
2
3
4
5
6
7
Scope of this document................................................................................................................... 3
Introduction ...................................................................................................................................... 3
Where to Get the Distribution.......................................................................................................... 4
3.1
Primary distribution .................................................................................................................. 4
3.2
Other mirrors ............................................................................................................................ 4
3.3
rsync ......................................................................................................................................... 4
Distribution Components ................................................................................................................. 4
4.1
CA Information ......................................................................................................................... 4
4.1.1
CA Trust Anchor – traditional Grid components: ........................................................... 4
4.1.2
CA metadata .................................................................................................................... 4
4.2
CVS Repository ....................................................................................................................... 5
4.2.1
carep module organization .............................................................................................. 5
4.3
PGP/GPG signing key............................................................................................................. 6
4.4
Distribution Products ............................................................................................................... 6
4.4.1
Mirrors and distribution sites ........................................................................................... 6
4.4.2
Distribution contents ........................................................................................................ 6
Updating the Distribution ................................................................................................................. 8
5.1
Updating the CVS Repository ................................................................................................. 8
5.1.1
Background – Policy........................................................................................................ 8
5.1.2
Process - direct ................................................................................................................ 8
5.1.3
Process – Indirect ............................................................................................................ 9
5.2
Building the Distribution ........................................................................................................... 9
5.2.1
Check the Revision.......................................................................................................... 9
5.2.2
Commit and Tag the version ........................................................................................... 9
5.2.3
Build the Distribution products ........................................................................................ 9
5.3
Signing the distribution ..........................................................................................................10
5.4
Announcing and posting the distribution ..............................................................................10
5.4.1
Pre-releases ...................................................................................................................10
5.4.2
Released Distributions...................................................................................................10
Distribution Business Relationships .............................................................................................11
6.1
Relationship with IGTF, IGTF PMAs, and IGTF CAs ..........................................................11
6.2
Relationship with TACAR self-signed CA repository ...........................................................11
6.3
Relationship with Grid software distributions .......................................................................11
6.4
Relationship with commercial and other non-Grid CAs.......................................................11
Distribution Operations ..................................................................................................................11
7.1
Software and hardware .........................................................................................................12
7.2
Personnel - local and external (regional PMA) ....................................................................12
The European Grid Authentication Policy Management Authority in e-Science
http://www.eugridpma.org/
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
page 2/13
Dated: 09 Mar 2016
7.3
Security keys ..........................................................................................................................12
8 Security ..........................................................................................................................................12
9 References.....................................................................................................................................12
Appendix A
Examples ...................................................................................................................13
A.1
Example CA metainfo and files.............................................................................................13
A.2
Content list of distributions ....................................................................................................13
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
1
page 3/13
Dated: 09 Mar 2016
Scope of this document
This document describes the current organization and operation of the IGTF Common Trust
Anchor Distribution (“the Distribution”).
It is closely allied with the TERENA Academic CA
Repository (“TACAR”) and software distribution services such as Virtual Data Toolkit (“VDT”). Only
interfaces to such organizations will be described. IGTF and each regional PMA in IGTF have
their own rules and process for approving Certification Authorities (CAs) and adding them to the
Distribution; this document will describe what data is needed from each CA in order to be added to
the Distribution, and how the Distribution is built; but the policies and procedures for arriving at
approval appear in other IGTF or regional PMA documents.
This is a snapshot in time of this service. Circumstances and requirements change, and the
Distribution service changes in response. This document is intended to provide useful information
to operators and users of this service, but does not represent a permanent commitment to the
features presented, nor a fixed specification.
2
Introduction
[Cross references needed in doc]
The Distribution is a collection of “trust anchors” in a variety of formats suitable for Grid relying
parties. These trust anchors have completed an approval process in one of the IGTF regional
policy management authorities (PMAs) resulting in “accreditation”, and a request for enrollment in
the Distribution. These trust anchors consist of CA signing certificates, and other metadata
associated with each CA, as described below. They are organized into sets of files and these files
are served from a trusted and secure repository hosted at NIKHEF in Amsterdam, on behalf of the
IGTF. The contents are mirrored at one or more sites in other locations. Distribution content and
organization have been developed in consultation with some of the larger Grid organizations and
relying parties. The Distribution is also collaborating with the TACAR registry (link), which provides
additional organizational checks and supports the wider community of NREN and academic PKIs
used in various research projects.
A uniform and consistent distribution of these trust anchors is very important to the security and
stability of several large scale experiments and Grid consortia (enumerate?).
The Distribution began in the early days of the EDG CA Operator’s group, as a service for the EDG
partners and users. An RPM-based distribution was organized by Anders Wäänänen, a table of
links and contact information was provided by Sophie Nicoud, and a CRL retrieval script was
contributed by Fabio Hernandez.
Other Grid organizations in the US, Asia, and elsewhere in the world either adopted this RPM
distribution or used it as the basis for their own repository services. As regional Grid CA PMAs
were established and joined together to form the IGTF, each had the obligation to provide
repository and registry services for their members. In addition, Grid middleware required additional
forms of the repository – Java environments need a Java Key Store (JKS) form of the distribution.
In addition to these drivers, as Grid usage expanded around the world, and world-wide
collaborative projects became possible, the need for a consistent, trustable distribution of Grid trust
anchors increased….
[NIKHEF and / or David Groep added and currently support these improvements as well as others.]
[Formation of TAPGMA and chartering of IGTF … Boston GGF Sep 2005 …]
[Perhaps this section should describe _who_ should read _what_ eg repackagers should look at
<X>, committers <Y> &c]
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
3
page 4/13
Dated: 09 Mar 2016
Where to Get the Distribution
[Probably this “Get the Distro” section should describe everything you need to get and install a
distribution copy w/o access to the other channels – javastore password – where to monitor
announcements – what else?]
The structure and contents of the Distribution are discussed in detail below.
3.1
Primary distribution
URL: https://dist.eugridpma.info/distribution
3.2
Other mirrors
Currently
http://www.apgridpma.org/distribution/igtf/ (synchronizes twice a day).
3.3
rsync
rsync can be used to create a mirror (for a project or other regional PMA), and is encouraged.
[what needs to be set up here] [obviously wget –r <distro-url> or some variant works too, altho
slowly]
4
Distribution Components
The Distribution collects information about IGTF trust anchors in a set of files. The CA information
files are the basic elements of the Distribution.
4.1
CA Information
Files use this naming convention: <hash>.<ext> where <hash> is the “subject name hash”, the
output of this openssl command:
openssl x509 –noout –in <CA signing certificate> …
<ext> will be defined in each case below as needed.
4.1.1
CA Trust Anchor – traditional Grid components:
<hash>.0
CA signing certificate in base-64 (“PEM”) format
<hash>.signing_policy
CA signing_policy file; see below
4.1.2
CA metadata
1
<hash>.info
Template for the “info” file:
This file must be in UNIX text file format (namely in ASCII characters with lines ending in LF or
ASCII encoding 0x0a).
[Should be a table?]
alias [short name for CA, no spaces]
url [URL for CA’s main web page]
ca_url [URL for CA signing certificate on above web page]
crl_url [URL for CRL on above web page]
email [email address for inquiries]
status:<state>:<profile type]
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
page 5/13
Dated: 09 Mar 2016
We currently have “classic”, “slcs” and “mics” as accepted profile types. All CAs in the “accredited”
category of the distribution (see below) will report “accredited” status; other possible values are
“experimental” and “worthless”.
sha1fp.0 [SHA1 fingerprint of CA signing certificate]
version
Several of these fields can be generated automatically [sha1fp.0 and version; which others?]
2
CA Application Form
[Maybe we could just put this in an appendix]
An online version of this form can be found here:
https://www.eugridpma.org/review/registration
It includes some of the metadata above






3
<hash>.info file – see above
CA subject name (case insensitive) in OpenSSL X509_one_line format
CA signing namespace(s) in OpenSSL X509_one_line format (or see signing policy below)
CA signing certificate in PEM format
URL for CP/CPS on CA web site
Contact information for CA manager/operator (physical address, telephone/fax numbers)
crl_url file
This file is optional in the submission phase, but is a required product of the distribution. It can be
generated by cabuild.pl from the crl_url attribute in <hash>.info above.
4
signing_policy file
This file describes the namespaces for which the CA is authoritative. It can be generated
automatically from X509_one_line format [where is this defined] and should be checked by the
committer (see below).
5
CA relationship information
This is needed in order to encode “requires” directives and RPM dependencies [ also for YUM?
For other?] for hierarchies of CAs.
4.2
CVS Repository
The core of the Distribution is the management of CA information files and other components in the
CVS Repository. The repository can be browsed by community members (login required) at
https://cvs.eugridpma.org/cgi-bin/cvsweb.cgi/carep/.
The CVS Repository is used to manage sets of files consisting of the IGTF trust anchors and
associated information, and also some of the tools used to build distributions from those files. The
CVS Repository should not be considered a separate form of the Distribution, or used as such.
4.2.1
carep module organization
1
Buildtools
Contains scripts, text files, and some README files.
1.1
mknamespace –
mknamespace generates the <hash>.namespace file from <hash>.signing_policy file
1.2
*README* -
These are the text or information content source files for many of the branches of the online
distribution tree (see below).
1.3
cabuild.pl
This script builds the distribution. The technical description and structure of the IGTF distribution is
embedded and implicit in this script. It creates the directory structure, extracts the CA information
and locates it in appropriate distribution locations, stamps versions, links dependencies (RPMs),
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
page 6/13
Dated: 09 Mar 2016
copies README files and edits them for appropriate locations. It also supports the RPM signing
with a PGP key. It builds the various metadata needed by RPM package managers like APT [ref]
and YUM [ref].
cabuild.pl does some sanity checking on the distribution metadata. It will return errors if trust
anchors or metadata are missing. It will report signing certificates that are within 180 days of
expiration.
2
misc
Contains some uncategorized but useful CAs not in the accredited lists.
3
Regional PMA branches
Each regional PMA accredits and enrolls CAs drawn from its membership and scope of work, and
each has a separate branch in the repository. The regional PMA will check in, for each enrolled
CA, the CA information files (described above): the CA trust anchor and metadata files (signing
certificate, info, namespace, and signing_policy files). [List 3 current branches?]
4
5
PGP/GPG public key certificate (see below)
CHANGES
Contents of CVS logging - record of additions, modifications, and deletions of CAs, metainfo, and
distribution tools.
4.3
PGP/GPG signing key
The distribution signing key is kept on a flash memory device locked in a safe in Amsterdam.
Operations personnel have access to the safe and device, but not the passphrase for the private
key, which is known only to the Distribution managers. The current key specification:




4.4
4.4.1
Key name “EUGridPMA Distribution Signing Key 3 <info@eugridpma.org>”.
PGP keyed: 3CDBBC71.
PGP fingerprint : D1 2E 92 28 22 BE 64 D5 01 46 18 8B C3 2D 99 C8 3C DB BC 71
This key can be found on the PGP keyserver network1
Distribution Products
Mirrors and distribution sites
[This is same as “where to get” section above – left here from my version. We could cross
reference and use this spot as a description for how to make mirrors.]
1
Primary
URL: https://dist.eugridpma.info/distribution
2
Other mirrors
Currently http://www.apgridpma.org/distribution/igtf/ (synchronizes twice a day).
3
rsync (for mirrors)
[what needs to be set up here]
4.4.2
Distribution contents
The current directory tree structure of the Distribution is described below.
1
http://minsky.surfnet.nl:11371/pks/lookup?op=vindex&search=info%40eugridpma.org&fingerprint=o
n
for the key signatures, or
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0xC32D99C83CDBBC71
for the public key. Most PGP keyservers should provide this same key.
Category: technical documentation
Status: DRAFT
Document: 533582878
Editor: David Groep - Michael Helm
Last updated: Wed, 09 March 2016
Total number of pages: 13
1
2
3
3.1
3.2
3.3
3.4
Outdated – some very old distributions
IGTF – Distributions since founding of IGTF; points to current
Util – Associated utilities
repodata – YUM metadata
patches – patches for utilities
headers - ?
fetch-crl
A script that downloads CRLs from each <hash>.crl_url available; plus README, sample crontab
configuration.
4
5
5.1
tests – test data/distributions
current – the current distribution
igtf-policy-intallation-bundle*
This is a collection of CA information files in a format suitable for a repackager to use. Additional
CAs could be added or existing ones subtracted […explain…]. Also a signed .asc file.
5.2
igtf-preinstalled-bundle-*
CA information files, sorted by profile. [For use by repackager or some other format?]
5.3
accredited.in
CA alias name and profile accreditation
5.4
tgz
Each CA information file set, one tar-zip file per CA. Plus a policy bundle [what is this for], listing
each CA and revision number [except all rev nos are the same].
5.5
jks – Java Key Store
Organized like tgz directory, one jks per CA. JKS currently only uses the CA signing certificate, the
other trust anchor and CA information files are not used. Also includes an all-classic and all-slcs
bundle [what about all-everything and all-mics?]. Not signed.
5.6
5.7
headers – repodata - ?
Accredited CAs
CA information files are tagged with a profile_type in the status attribute (see earlier). Because
each CA profile has inherently different policy and perhaps a different level of assurance, profiles
are bundled separately so that relying parties would make a decision to accept a profile rather than
being forced to accept them by default2.
Generated by the cabuild.pl script – [how/when signed?]
4.4.2.5.7.1
RPMs
There is one RPM v3 file per set of CA trust anchor + metadata files.
CA policy files [description]
The RPM installs the five CA information files in /etc/grid-security/certificates.
The RPM contains a PGP signature for integrity/authenticity
4.4.2.5.7.2
4.4.2.5.7.3
SRPMs [source package files – installs gzipped tar balls]
jks
This is a set of Java Key Store files. The password is [look for this; why a password].
4.4.2.5.7.4
tgz
This is a set of CA information files in tar + gzip format.
4.4.2.5.7.5
Accredit.in
A manifest.
4.4.2.5.7.6
Bundles of tar files
[description]?
5.8
Experimental, worthless, distributions
[use index file from web]
2
David Groep, email message 08 Aug 2007 to the TG-Security mailing list.
The European Grid Authentication Policy Management Authority in e-Science
http://www.eugridpma.org/
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
Dated: 09 Mar 2016
CHANGES – Release change log
GPG public key certificate
Version number
5.9
5.10
5.11
5
page 8/13
Updating the Distribution
Figure 1 The Distribution Update Process
5.1
Updating the CVS Repository
Committers appointed by the Regional PMAs update their respective branches. The Distribution
managers update the code and PGP sections as needed. Conventional CVS tools are used,
remote access to the repository is managed with ssh public keys.
Current information about the IGTF
https://www.eugridpma.org/review/using-cvs
CVS
Repository
can
be
found
here:
This web page has up to date information on build policies, tools, accounts, and other information
related to the repository.
5.1.1
Background – Policy
Each Regional PMA appoints at least one “committer” – someone who will do the actual enrollment
of the regional PMA’s CAs into the distribution. The committer establishes a relationship with the
manager of Distribution through PKI and/or a face to face meeting. The committer provides an ssh
public key to the Distribution manager, who creates and provides a local account for CVS access
via ssh for the committer.
The committer uses these local shell definitions for CVS client:
 CVSROOT=:ext:<account>@cvs.eugridpma.org/cvs/eugridpma
 CVS_RSH=ssh
Where <account> is the account name provided to the committer by the Distribution management.
5.1.2
Process - direct
The committer will download and interact with the CA distribution module – carep – through the
typical CVS commands. The committer will add CA trust anchors and metadata files, change
existing files, or delete files as appropriate. The committer must only modify files in the appropriate
scope of responsibility – namely, the committer must only add or modify CAs from the regional
PMA that has appointed the committer.
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
page 9/13
Dated: 09 Mar 2016
The committer should be familiar enough with CVS to know how to use the appropriate add,
update, commit, and logging commands in CVS.
The committer should perform some sanity checks on the contents of additions or changes before
committing them. The CA trust anchor and metadata information must be complete, and the
signing policy and CRL_URL pointer must be correct, or the CA’s customers may not be able to
interoperate with Grid users and services. [The committer should notify the Distribution manager
when updates have been made.][Does the CVS process send notification to the Distrib team
members or ?].
1
Namespaces
<hash>.signing_policy and <hash>.namespaces should be checked carefully. Presumably, the
sponsoring PMA and the CA operator will have checked the signing_policy file for correctness, but
not all errors have been caught prior to the Distribution build stage. CVS committers should use the
mknamespaces utility to generate a new <hash>.namespaces file, and make sure that the results
are correct. In particular, quoting of trusted paths must be done correctly [The specific problems
and instructions should be stated.]
5.1.3
Process – Indirect
A trusted authority for changes to the distribution (such as a regional PMA chairperson) may
interact indirectly with the managers of the Distribution, or a trusted committer. This authority
sends the committer a message containing the information in the “Application Form” (see above).
The message should be sent in a trusted way – in a face to face meeting, or electronically with a
signed PGP or S/MIME message, or notarized, or in some other fashion. The designated
committer will then interact directly with the Distribution CVS Repository as above.
5.2
Building the Distribution
[I cribbed most of this from the “using-cvs” page, the slides, and a few details I remember from the
oral presentation]
Typically, a distribution build is done on a clean, dedicated system, to minimize the possibility of
errors, unwanted revisions and interactions, and other problems.
5.2.1
Check the Revision
cvs update -R -A -d . in the local copy of the carep module
5.2.2
Commit and Tag the version
[What is the “tagging” standard]
Version numbers should increase monotonically.
5.2.3
Build the Distribution products
[This needs to be explained some – why are there 2 different lines with 2 different sets of options?]
cd buildtools/
./cabuild.pl -f -s -o /tmp/dist --version=AUTO
* The build tools are now in a separate directory "carep/buildtools/" and /from that directory/,
you can issue a single command to build the entire thing:
.../carep/buildtools$ ./cabuild.pl --gver=0.33 --release=0.test1
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
page 10/13
Dated: 09 Mar 2016
and optionally append a "-f" option to wire the old build directory first. The result will be the
complete distribution tree in "../distribution/" by default (use "-o distdir" to put it somewhere
else).
The status field of a CA in its <hash>.info file determines whether or not the corresponding
distribution files for that CA will be built. If it belongs to a supported profile, it will be built; if its
status has been changed to discontinued it will not be built [what about other status?].
5.3
Signing the distribution
The distribution is currently signed by the IGTF Distribution PGP key (see cert above). The IGTF
signer is [… describe and how the key is managed.] Building a signed distribution is an additional
command line option; add “--sign” above. The approved signer must know the signing pass
phrase, have the device installed, and have the appropriate attributes for signing in ~/.rpmmacros
[we could put the example here or in footnotes or in appendix?]
[There is the intention that every committer or every PMA anyway would have its own key and resign the distribution. The RPM documents are a little confusing but the way I read them, only one
signature is supported per RPM file ie a new signer replaces previous signatures.]
5.4
Announcing and posting the distribution
Preliminary and test releases are built in the same fashion as final distributions. Preliminary or
“release candidate” distributions are announced on the mailing list igtf-general@gridpma.org, which
forwards to members of the regional PMAs. Announcements contain a proposed revision number
and a proposed release date. Typically two weeks are allowed for comments and corrections.
New distributions appear [how often – not quite monthly; usually more often than quarterly] and
occasionally on demand, when required.
Distributions are posted to the main web site (see above) with rsync.
5.4.1
Pre-releases
Pre-releases like so [This needs some work]
rsync -e ssh -rav --delete ~/distribution-1.14/* \
webegp@dist.eugridpma.info:/project/srv/www/site/eugridpmadist/html/distribution/tests/PMA-PRIVATE-PREVIEW/1.14-MAY23-01/
and to be sure, also on the hidden repository on the dynamic public site:
rsync -e ssh -rav --delete ~/distribution-1.14/* \
webegp@www.eugridpma.org:/project/srv/www/site/eugridpma/html/distribution/tests/PMAPRIVATE-PREVIEW/1.14-MAY23-01/
but then don't announce prereleases to the public) [what is the hidden repository?]
5.4.2
Released Distributions
rsync -e ssh -rav --delete \
/tmp/dist/ \
myname@dist.pmaname.info:/var/www/html/distribution/igtf/1.0/
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
page 11/13
Dated: 09 Mar 2016
Then the symlinks in the distribution tree are updated; the "XXXX-is-current" file is re-written,
and the home page is adjusted.
The announcement is sent out using the default template [which is?]
6
6.1
Distribution Business Relationships
Relationship with IGTF, IGTF PMAs, and IGTF CAs
The Distribution fulfills the final step in IGTF accreditation. Each CA works with a regional PMA to
gain accreditation by that CA. This typically requires a review of the CA, and approval of the CA by
the regional PMA. Grid security and technical requirements mandate that CA information be
collected together and distributed to the very large number of relying party sites. The end result of
accreditation by the regional PMAs is enrollment of the CA in the IGTF Distribution, which allows
the CA’s customers to interact with other members and relying parties who trust IGTF CAs.
6.2
Relationship with TACAR self-signed CA repository
TACAR (http://www.tacar.org/) is a repository of Certification Authority signing certificates used in
the academic and NREN communities.
Typically these are self-signed root CA certificates.
TACAR does not validate policy, but does check ownership of a CA, and validates the identity of
the person representing the CA. This provides a trusted path for validating the CA signing
certificates presented for inclusion in the IGTF distribution. The TACAR process and the IGTF
process for CAs are complementary: TACAR validates the ownership and affiliation of a CA, and
the identity of a CA operator, but does not evaluate CA policy for any particular purpose; IGTF
evaluates and accredits CA operations for use in the Grid, but does not strongly identify operators.
The TACAR repository is meant for root certificates, and does not provide the CA information files
and CA metadata needed by some applications; the IGTF repository provides a complete package
for each CA, and dependencies (hierarchies) as needed. TACAR provides web browser
downloads of CA trust anchors, the Distribution supports Grid applications and in particular those
built on typical Grid software/middleware distributions. [express as bullets?]
[The intention is to make IGTF and TACAR processes as congruent as is useful to both services to
maximize benefits for the overlapping communities served by both organizations.
It seems
important to say this, altho perhaps could be seen as out of scope or inappropriate.]
6.3
Relationship with Grid software distributions
[LCG is strongly connected to this service, partly for historical reasons. VDT isn’t. Not sure how to
say this nicely.] [LCG: http://goc.grid.sinica.edu.tw/gocwiki/Procedure_for_new_CA_release3
6.4
Relationship with commercial and other non-Grid CAs
Currently, the Distribution does not support commercial CAs, or bridge-mesh PKIs, or other nonGrid CAs. In a few cases, Grid CAs are nodes in a hierarchy of CAs from some organization. In
those cases the top level CAs and appropriate signing policy files are crafted and placed in the
distribution in order to meet technical requirements of security middleware in use in the Grid.
7
Distribution Operations
[I think this is overtaken by previous sections]
3
David Groep, email message 16 Aug 2007
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
page 12/13
Dated: 09 Mar 2016
7.1
Software and hardware
7.2
Personnel - local and external (regional PMA)
7.3
Security keys
8
Security
[This section should describe various issues and risks we assume.]
The PGP signing key is a single point of failure. Transition to a different key, or multiple keys, or
distributed signing, are not addressed at this time.
Signing is localized to a particular geographic location and institution.
Committers may intrude in areas outside their responsibility in the CVS repository.
It is possible for committers to damage files and hence the distribution thru incorrect update and
modify actions.
Controls on access to CVS Repository machine and controls on changes to CVS files (CVS is not a
secure service). Controls on backups. The CVS repository is currently confined to a single location
(which presents a single point of failure), but a distributed solution would create an opportunity for
corruption.
The relationship between CA certificates enrolled in TACAR and CA certificates enrolled in the
Distribution is not completely defined yet.
Different software vendors have different levels of integration with the Distribution.
The need to use CAs not in the IGTF accredited list is widespread; even the Distribution makes
some of these unaccredited CAs available.
ssh keys require some form of strong, out of band identity proofing to be trustable, and have no
inherent key management features (expiration, revocation &c). The number of keys in use in this
service is very small.
9
References
Bailey, Edward C. Maximum RPM. Red Hat, 2000. http://www.rpm.org/max-rpm/
Florio, Licia, ed. “Policy of the TERENA Academic CA Repository (TACAR)”.
http://www.tacar.org/docs/TACAR-Policy-v1.4.3.pdf
Jan 2007.
Groep, David. “Using the IGTF CVS Service”. https://www.eugridpma.org/review/using-cvs
Groep,
David.
“Required
data
https://www.eugridpma.org/review/registration
for
getting
into
the
Distribution”.
Groep, David.
“The CA Distribution Process”.
(Powerpoint) TAGPMA, July 2007.
http://www.tagpma.org/files/cabuild-process-20070716.ppt
Groep, David. “TACAR Updates”. (Powerpoint) TAGPMA, July 2007 and EUGridPMA, Jan 2007.
http://www.tagpma.org/files/TACAR-abingdon-20070117.ppt
OpenSSL man page. http://www.openssl.org/docs/apps/openssl.html
OpenSSL x509 man page. http://www.openssl.org/docs/apps/x509.html
the European Grid Authentication Policy Management Authority in e-Science – http://www.eugridpma.org/
IGTF Distribution Process
version 1.0
Appendix A Examples
A.1
Example CA metainfo and files
[pick]
A.2
Content list of distributions
[don’t need? Have the net]
page 13/13
Dated: 09 Mar 2016