[CA-coordination-20020627 revision 0 (initial version) DG/20020708.2]
6th EDG CACG meeting 2002.06.27
-------------------------------
Present:
Dave Kelsey (RAL)
Brian Coghlan (TCD/IE)
Jens Jensen (RAL/GridPP-UK)
Milan Sova (CESNET/CZ)
Anders Wanaanen (NBI/NorduGrid)
David Groep (NIKHEF/DutchGrid)
Tony Genovese (DoE)
Mike Helm (DoE)
Rafael Marco (IFCA/ES)
Emanuele Leonardi (CERN, via VRVS)
Sophie Nicould (CNRS/FR, via phone)
Ursula Epting (FZK/DE)
Jan Astalo\'s (Slovakia, astalos.vi@sarba.sk)
Pawel Wolniewicz (Poland, pawelw@man.poznan.pl)
Christos Kanellopoulos (Greece, skanct@physics.auth.gr)
[First session, Thursday June 27, 14.30]
Introduction
------------
Several new CAs are joining the CACG that are originating in
the CrossGrid programme. CrossGrid is an EU project, coordinated
by the Poznan HPC Centre in Poland, with partners from several other
EU states and associated states. Information is available from
.
The original idea behind CrossGrid was an "extended EU DataGrid",
focussed on interactive applications. New applications are meteorology,
flow calculations and biomedical imaging. CrossGrid will share a
common test bed (and at least common middleware) with EDG.
Besides the application WPs, there is a Middleware- and a test bed WP.
For the first year, the test bed will be exactly the same as the EU
DataGrid test bed, in the future newly developed middleware might
needs its own test bed.
We welcome the newly established CAs, but it does point to the
long-term scaling problems accompanying the changeover from test beds
to producion linked to both CrossGrid and, e.g., the LCG (LHC Computing Grid
Project). Should this group keep growing or should a new entity be
established. This item will be discussed under "scaling to production"
agenda point and the relation to GGF.
[Sophie leaves the conference call due to lack of audio]
[The CERN VRVS connection is now permanently at 0 fps and no audio]
Notes from previous meeting
---------------------------
Action points emanating from the previous meeting:
* on OpenCA: the dust only recently settled. Now Jens has the
presentation, that will be shown later on in this meeting.
Brian also has some slides regarding OpenCA.
* on other open-source products besides OpenCA: several alternatives
are available. In particular, Cristos will send info on "CSP",
Jens on and Mike will send info on other products.
* on the expiration of long-lasting credentials while the job runs:
Globus currently looks only at the subject name, so there
is no apparent problem. However problems might emerge when a
new proxy is needed, e.g., to send data home at the end of a job.
We have not yet seen this problem on the current test beds, but
there are in deed tools used that need re-authentication at the end
of the job. At the moment these always relies on the *old* proxy.
There is no way to get back to the user to get a proxy based on the
newly issues key pair.
Some confusion still exists on renewing CA root certificates,
especially how to implement the use of new keys for a certificate
with the same DN. Mike will contact the Von Welsh and Doug Engert
about possible solutions and guidance.
* Ursula has sent out the information.
* On the Matrix: It is noted that there is still some non-compliance
with the stated target.
* On GGF attendance: some CA managers will be present in Edinburgh.
* The CA directory configuration and examples are not yet
in the CVS repository. It is on Roberto's action list.
* on the CNRS catch-all CA. Sophie to contact Jean-Luc Archimbaud about
updating CP/CPS to act as catch-all. Since Sophie just left the
conference due to a dead phone line, the status is unclear and
the action is left pending.
Round-table
-----------
David (NIKHEF):
Since the CA has been in operation for more than one year now,
the number of renewal requests in increasing. The renewals
are based on home-grown scripts that generate re-keyed requests
encapsulated in S/MIME messages.
The result is better than what is produced by grid-cert-renew
from the standard Globus Toolkit: this created a mangled
subjectDN that needs a hacked version of the openssl "ca" command
to go with it.
The scripts are available for those interested on the Dutchgrid
CA site and the
server side on .
Tony (DoESGs):
Well established now. The ~10 DoE sites are being extended
with new RA's in NSF and Engineering Grid projects.
The potential subscriber community is ~20k users, but the
ramp-up to this maximum is slow.
A name change to the root and subscribers is due for purely
political reasons. The old one will be phased out over
a long period of time.
Anders (Nordugrid):
The NorduGrid CA just celebrated its first birthday. The
re-issuing has now started, with many subscribers using
the Globus-provided grid-cert-renew script (with the associated
problems).
The system has been moved to a secure location.
New services get "service certs", and the issuance of
host certs has now ceased. The CP/CPS will be with us shortly.
Ursula (FZK & GermanGrid):
Issued 29 certs till now. A new OID has been assigned to CPS.
Highlights of the changes:
- FZK has changed name of the CA to GermanGrid:
"/O=FZKgrid/..." -> "/O=GermanGrid/..."
- this namespace changed for political reasons.
All EDG CAs are now being accepted in FZK, but for some
reason the DoESG is not there yet.
Milan (CESNET):
Setup of an All-Academic CZ national CA is being postponed,
whilst looking for new organizational form. This has no
effect on the Grid CA.
Jens (UKHEP):
The new UK E-Science CA will be deployed soon, old certs will
expire gracefully.
Legal requirements needs RA to be appointed officially by a
letter from the responsible from the physical institution.
The RA procedure involves lots of politics.
The physical security of the CA system is being enhanced by
putting the entire system into a cage (not implemented yet).
New keys will be generated when this security is in place.
Namespace has changed slightly: the DN now identifies the RA
that authenticated for the user. This is there for bookkeeping
reasons only, and it is explicitly forbidden to use this
component for authorization. (the DoESGs CA explicitly does
not include this, because even when formally forbidden, such
a field would surely be used for authorization by someone).
As for the CP/CPS a draft exists, but presently contains
mostly guidance for the RAs. Last checks for compliance with
the Data Protection Act still need to be done.
Christos (Greece):
The CA in its birth phase will be called "HellasGrid CA". The
structure will be embedded in a national CA infrastructure,
with a root of which HellasGrid will be a direct subordinate.
The server is in secure location, disconnected from the net.
No certificates have been issued yet, but 60-100 are foreseen
spread over three institutes. It will probably increase over time.
A previous CA operated by the group had issued 300 certs.
A draft CP/CPS is ready and is proposed for inclusion in the Matrix.
A web site is there, a directory is soon to come.
HellasGrid will act as a national Grid CA for Greece.
Rafael (ICFA):
The CP/CPS was updated to reflect that the RA changed jobs
and went to CERN. With new requests coming in from all over
Spain, more RAs are being set up.
Also, new requests have come for Spanish-owned machines in
Wisconsin. If they are truly Spanish-owner machines, they
can come to ICFA. Otherwise, it might be worthwhile to send them
to DoE. The people involved may not even know that the DoESG CA
exists! If they are US owned systems, they should go to DoE.
Similar problems appeared earlier with Nordugrid machines
at CERN. The problem will be persistent, although the only
proper solution would be for the DNS admin to issue the certs.
In the relevant committees, the responsibility is being pushed
around between PKIX, DNS, SSL, etc. working groups.
A recent push within the PKIX IETF wg has been to put the FQDN
not in the subject name but in the SubjectAltName. The subject
name could then be an "arbitrary" string.
This has been tried at LBNL, but results were not promising.
Especially commercial software is not able to cope with this
cert structure.
The Globus "host/FQDN" notation is in itself incompatible
with many commercial applications like Netscape, and also with
the default verification routines in OpenSSL/Apache/OpenLDAP.
Specifically, "ldap/FQDN" did not work in OpenLDAP, unless
the FQDN was also in the SubjectAltName. OpenLDAP2 is now RFC
compliant: checks the cert name against the name used by the
caller (i.e. when issued with FQDN does not work with
"localhost"). Recommended practice is to first check for
the "correct" hostname in the SubjectAltName, and only then
try the subjectDN CN component.
CESNET puts for all host certs the FQDN in the SubjectAltName.
This is STRONGLY RECOMMENDED for all CA's.
It is also useful since it's required for IPSEC on OpenBSD.
For user certs, CESNET puts the email there, but other CAs
(at least UKHEP) has privacy issues concerning e-mail addresses.
As a side note: Globus seems to be case insensitive, but all
underlying code IS case sensitive.
Pawel (Poznan):
A CA system has been set up in secure room. This CA will serve
the Polish grid research institutes (currently 5), for which
RAs have been set up in all five cities. Till now only
one certificate has been issued. An early draft of the CP/CPS
exists (currently on paper only).
On CrossGrid:
A CrossGrid Information page is available on the web at:
. The
CAs in CrossGrid are a part of WP4/TestBeds.
The link to this page will be put on the EDG "marianne" site.
It is noted that the is no CA coverage in Italy for CrossGrid.
This is not considered to be a problem, since the only
Italian partner in CrossGrid is DataMAT for dissemination.
A Cyprian CA is not yet in place.
Before inclusion and approval by the EDG CACG as "equivalent CA",
the CP/CPS of the new CAs will be pre-screened by a
subcommittee consisting of Brian, George and Rafael.
A presentation on CrossGrid from their Krakow conference is
shown. It can be retrieved from the main CrossGrid web site at:
.
Jan (Slovakia II SAS CA):
CA is on a dedicated server, non networked, based on OpenSSL.
The draft CPS is based on the LIP version; comments are welcomed.
To date no certs have been issued to any of the three organisations
that are part of Grid-related projects.
Brian (TCD):
The "old" CA is still up and running, but since november 2001
no new certs have been issued. All the effort has gone into
setting up a new OpenCA-based CA, for which the 31-day trial
has started on June 10th.
The new system is much more elegant then the previous setup,
and much easier for the RAs to use.
Mid July this CA will be switched into full production,
and a new CPS will be issued since the namespace has changed.
The RA name is coded in the DN here as well.
There are no directory services yet, but certs are publicly
available or listable on the web.
CERN(by proxy):
For the new CA issuing long-lasting certificates, the
CERN "team leaders" will be acting as RAs.
This new CA should have started already in May but is not
yet operational.
How the RAs will do the authentication is not yet sufficiently
detailed. The technical part (typing "ca_approve" on system
with AFS) is there. The CA singing system will remain off-line.
As alternatives to the "standard" CA, CERN is investigating the
use of automated CA's linked to their Kerberos KDC. It would
be issuing Short-Term certificates based on Kerberos identities.
This research is part of the LCG project.
More information on the CERN CA is in a presentation, which
will be sent to the list.
More CAs are now joining the EDG CACG, and it may be nice to
monitor the progress on a "management" level by producing graphs
of issued user certs, host certs, renewals and revocations.
An example is already in the presentation on the DoESGs CA.
The graph binwidth should be approx. quarterly and collated before
each meeting.
The graphs will first be distributed to the group before they
get wider publicity.
Update on minimum requirements and procedures
---------------------------------------------
(1) Lifetime of the CA root cert
In the US, subscribers are asking for very-long-lived certificates
(in the order of four years and more), since they are not particularly
happy with having to do renewals. This has related implications for
the root certs. Since root changeover is even harder, DoESGs CA
prefers a long (>30yrs) lifetime of the root cert, and then
devolve the actual signing to subordinate CAs with a shorter
life time.
Within the CACG, earlier discussions focussed on the relation between
lifetime and the number of bits. Although a recent publication claims
to have brought down the time to crack keys, it is yet unclear
whether the statement are really applicable to "large" keys (>=1024 bits).
But a relationship between keysize and crackability does exist, and
we should prepare for new technologies (both faster systems and
new algorithms) to emerge in the coming years.
In practive, the keysize cannot grow much larger, since most commercial
hardware key storage devices cannot handle 4096 bits and above, setting
the keylength to 4096 limits your vendor choice to just one supplier.
Also, most Netscape 4.x browsers cannot handle user certs with a
key length >1024 bits, although Mozilla can.
In the end, the main security risk is with the subscriber and his
care in handling the private key. We have no control over the user
handling their keys, e.g., whether they use null-pass phrases etc.
The initial response from DoESGs CA to long-lived (>1 year) user certs
was therefore negative. Because people do not stay in a position for
a very long time, change jobs etc. and machines get decommissioned
periodically. Revocation is still a weak system and is not able
to cope with rapid changes. In the end, no-one takes the responsibility
to oversee the termination of certificate validity.
On the other hand, NASA IPG and the Alliance CA issue 4-year end-entity
certs. Under the current minimum requirements the EDG CACG would not
allow this.
However, it does bring down cost. For the DoeSGs, issuing one cert
costs about $1000 in manpower, machines, training, etc. Even if
an infinite number of certs is issued, the cost would still be $5
to be paid to IPlanet CMS. For new, with only a few certs issued,
a cert costs $10,000!
In the end the basic reasons for changing the end-entity cert
life time are:
* user requests: DoESG subscribers want to change it to 2 years
* less work for the CA staff and reduced cost
Lifetime of the end-entity certs and the CA cert lifetime are linked.
With longer end-entity life times, you will have to renew your
root CA certs quite frequently. This may at some time wreck havoc
on the Grid, especially when many root certs expire at or around
the same time (the same problem that VeriSign had on Dec 31st, 1999).
Although EDG seems better organised than many of the US grids, the
problem might one day pop up.
In the end, it is the responsibility of the site administrators
as relying party to "trust" the CAs they install. Within the EDG
Test Bed, Anders implements the consensus of this forum
as policy.
Since we are only concerned with asserting a "reasonable identity"
bond between a certificate and an end-entity, our issued certs
are not to be used as the sole basis for an authorization decision.
This is also a pretty good reason to opt for a "flat" name space
in the certificate subject name.
Taking into account all of the above arguments, we decide to leave the
wording in the minimum requirements, being "... lifetime of personal
or host certificates must be no longer than one year", unchanged.
Other alternatives, in particular changing "must" to "should" are not
rejected out-right, but are not deemed necessary. In the end a user
with a long-lived cert can be banned at an individual site, according
to that site's policy.
(2) Renewal
The current version of the minimum requirements has no
section on renewal. In particular, it is unclear whether in
the renewal or re-keying process the end-entity should be
re-authenticated, i.e., should the subscriber go to the RA again.
Different CAs (and organisations) now use different mechanisms and
standard. In DoE, this process is distributed to the individual
labs; at CERN, one needs the signature of the Team Leader again
(although is includes also authorization).
A "renewal" section is therefore needed to be added to the
minimum requirements document. This item should be discussed
on the mailing list.
The new version of the minimum requirements document will be called
"... for test bed 2". Input regarding the evaluation of the current
policies should come from site managers and security officers.
(3) Network security of the CA signing machine
In the minimum requirements it explicitly stated that de CA
signing machine must not be connected to any network. The
reason being that, if the CA key is caught, the malicious party can
issue certificates with a new key pair but with the same subject
and thus gain access to all the resources to which the original
subscribers have access.
The DoESGs CA uses a Hardware Storage Module (HSM), where
- the private key cannot be extracted from the hardware module
- the break-in needs to happen whilst the CA activation data are
present inside the CA software.
If you get access to the system you can still re-generate certificates,
but, you have to break both the on-line machine and the CMS IPlanet
software containing the activation data, before you can access the
HSM. In particular, a brute force attack to take the key from the CA
does not work.
Moreover, it is earlier to crack the RA systems: all the protections
on the HW storage module will not be able to protect against this.
Thus, your administrative roles are sufficiently harmful already.
By use of a HSM, the private key of the CA is sufficiently well secured
that it is no longer the weakest link in the signing process. It thus
fulfills the intentions expressed by the minimum requirements document.
In the new version of the min. req., the wording will be changed so as to
allow this particular grade of HSMs: they should be compliant to
the FIPS-140 standard at Level 3 or above. Only then is the CA
machine allowed to be on-line, when suitably protected.
The exact phrase to be used when referring to FIPS-140 Level 3 will
be sent by Mike.
We leave the option open that acceptability of an on-line CA machine
can be decided on a case-by-case basis by the CACG. If we do so, the
wording in the minimum requirements may become "acceptable method".
Significant worries about such a phrase are expressed by several members.
[Next day, starting at 9:15]
(4) Registration Authorities and Authentication
The current requirement for authentication by RAs is by
some "rigorous means". It is unclear what these means should be,
especially in the wake of a large user community. The scaling
of the RA process, with potential subscribers appearing in-person
before an RA is cumbersome for distributed communities like
CERN and iVDGL (many users scattered over many campuses).
The CACG will insist on an exact description of the practices
of a CA in its CP/CPS. The methods used may differ between the
CAs, but the CP/CPS should give sufficient detail to judge whether
the methods are adequate and equivalent. The wording in the
minimum requirements will remain the same.
The new proposal for the CERN "long-lasting" CA is to use
the exsiting Team Leader hierarchy to act as a RA system. All
potential subscribers to the CERN CA have authenticated at least
once in-person to the Users Office. On renewal, the default is to
show u at the Users Office as well, although dispensation may be given.
For renewal, the Team Leader has to re-affirm the identity of the
(CERN) user and sign for his/her affiliation.
A primary concern may the the "ease" of getting identity certs.
Like in the issuance of passports, getting/stealing a passport
is relatively easy, but making a good forgery is much more
complicated. All malicious efforts therefore goes to getting
official papers issued to "false" entities.
Finally, the absolutely weakest link is the end-entity itself:
however strong the authentication and strong the signing process,
there is now way to enforce good pass phrases by users.
In the end, the whole process should be "reasonable", so
we keep the wording as-is: "... acceptable procedure for
confirming....".
Further discussion on RA authentication procedures for a "Test
Bed 2 version" of the minimum requirements should be done
via the mailing list before the end of the summer.
The DoEGrids Public Key Infrastructure (by Tony)
-------------------------------------------------
(see the DoEGRids web site at )
The scope of the DoEGrids CA has expanded to include sites
part of iVDGL (an NSF project) and Earth Sciences. The
community now consists of PPDG, FusionGrid, PNNL, ORNL, ANL,
NERSC, DoESG, LBL, iVDGL and soon EarthScienceGrid.
The main impetus still comes from the PPDG project.
The DoEGrids CA is operated by ESnet under funding by DoE.
Because of the extended scope, the name of the CA (and the
root certificate) has changed to reflect this broadening.
A 15-member PMA has been established.
October 15th is the official launch date of the new CA.
By June 20th, 2002, 258 certs have been issued (101 users,
100 hosts), 5 requests are pending and 29 have been revoked.
A proper RA operator should have a turn-around time of max. 1 week.
The revocations are largely due to errors in the namespace that
have not been trapped by the RAs. It is hard to prevent such errors,
since the use of name constraints breaks much software
including OpenSSL. It is close to unusable.
[an interesting discussion on firewalling and network
topology of the CA signing systems has been suppressed]
GGF CP Working Group
--------------------
Version 6 of the GridCP is finally finished, with the document
changed to a guidelines text for Grid CAs. The working group
has closed down.
A new CA-OPs (CA Operations) Working Group is in the process of
being established. This new working group will focus on PMAs,
cross-domain trust, CRL management and certificate profiles.
The new draft in GGF on PMAs is now out, taking the EDG CACG as an
example of a working PMA.
The BoF for the new working group is scheduled in GGF5 in Edinburgh.
Everyone is invited to send outlines, a slide with issues, etc to
be discussed in the BoF.
CA Matrix and Automatic Evaluation (by Brian)
---------------------------------------------
A few changed are proposed to the submission templates used
to fill the feature matrix. A group "publishing" has been
added that incorporates the "frequency" and "max_latency" data
of certs and CRLs. The unit for these variables is "days".
Other changes are still to be discussed.
Planed is the extension of the problem/rating/issue scheme with
a "grade": a factor that defines the "badness" of a particular
issue. Since many minor issues might constitute a big issue,
the "grading" of issues, like "0.4 x Major", allows to
express that many not-so-bad issues within one category taken together
can accumulate to a big issue *AT THAT LEVEL*. Accumulation of minor
issues can not lead to a major issue.
For now the accumulation will be a linear sum.
Automatic extraction of a "rating" from a CP/CPS is difficult but work
has started on this. The focus is on a common standard to define a
CA. To do automatic grading, the CACG should define a rule set that
will evualuate the feature matrix (later maybe also other criteria)
and assign a weight@class grading. Individual CAs can than make their
own extensions to the ruleset when they want to give "advise" to the
national user community.
Currently, the automatic grading based on the feature matrix
"half-works". A simple rule set syntax can be evaluated. The
content of the final rule set (which would reflect the minimum
requirements) should be discussed in the CACG, preferably on
the mailing list. Brian will send out a mail with the working
of the rule set and initiate the discussion.
A presentation of this work for GGF is very appropriate: it is
the necessary foundation for a future Bridge-CA for Grid.
The presentation should preferably be given by Brian, if he
is going to GGF5. Otherwise, it may be postponed to GGF6 (October).
What should go where in the CP/CPS is generally unclear. This
makes an automatic comparison based on the exact CP/CPS difficult.
A good guidelines document is the "PAG" standard published
by the ABA (American Bar Association). Although full of legalese,
it is quite useful. It can be found at
The document explains, section by section, the "proper" interpretation
of RFC257 (the new RFC has a similar structure, just some omissions
have been corrected). It can be used to self-audit your own CP to
see whether the proper stuff is in the proper sections.
OpenCA, modifications and operation (by Jens)
---------------------------------------------
See the slides at
and the working system on
The work at RAL was based on OpenCA version 0.8, but has
been heavily modified. Problems were encountered in the area
of browser support, where different key-generation commands
were needed for Netscape 4.7 and MSIE. Mozilla has yet
another set of peculiarities, and Opera support is largely
lacking although key generation should work.
The database format used by OpenCA 0.8 is BerkeleyDB, whereas
v0.9 uses mySQL.
A demo of the RAL-version is available at
Brian has also worked on OpenCA for TCD. Fewer changes have been
made to the OpenCA core, but the service selection web page was
re-written, making use of the OpenCA CGI scripts in the background.
Cross-trust establishment for FZK/GermanGrid CA
-----------------------------------------------
A draft CP/CPS for the FZK Grid (version 0.1) was distributed to
the mailing some months ago but did not trigger many comments.
A new version (0.2) dated June 2002 is now available.
At present only one "remote" RA is operational (in GSI,Darmstadt).
In the future this number is expected to increase as more
institutions in Germany join Grid projects. To reflect the
national scope of the FZK CA, the certificates signed are
in the namespace "/C=DE/O=GermanGrid", although the name
of the CA roor cert is "/C=DE/O=FZK-Grid/...". It is
unclear whether the "/C=DE/" top level is still managed in
Germany.
The CPS is unanimously accepted and the FZK CA is therefore
an CACG approved CA. The RPM containing the root cert, CRL reference
and the signing policy will be created by Anders and distributed
to the EDG test bed sites as part of release 1.2.
Cross-trust for new CrossGrid CAs
---------------------------------
Within the CrossGrid test bed CA working group (within CrossGrid WP4)
there will first be an internal check of the CP/CPSs. If this
CrossGrid group (Brian, Rafael en George) approves a CPS,
a discussion on the mailing list and a presentation in the EDG CACG
will follow. The discussion and the presentation will be
input for the acceptance decision. After approval a new CA will
be put in the Matrix.
Personal contact between the CACG and the prospective CA manager
is deemed to be essential.
For the new CrossGrid CAs (Greece, Slovakia and Poland),
presentation will be given at the next CACG meeting.
The Greek and Polish CAs will be ready for operation at the end of July,
the Slovakian CA will follow in September.
In the meantime, the new CP/CPSs should be distributed on the
mailing list, and after three weeks of discussion these three
CAs can be "provisionally" accepted (and the RPMs put in the
EDG package repository).
On the next meeting, there should be a formal presentation before
a final decision is taken.
Since no EDG release is planned till September, the new RPMs will have
to be pushed to the sites "by hand".
The users of CrossGrid are dependent on the acceptance of the new
CAs in the CrossGrid test bed, and since that test bed will be largely
shared by EDG and CrossGrid, implicitly also on the EDG test bed.
Christos will therefore make an instant presentation already at
this meeting.
CA Publishing Directories
-------------------------
It is unclear what the requirements on a CA operator are with
respect to publishing the certs and related information
in a public repository. All the information is there in the
mail exchanges on the list during the last few weeks, but it should
be put together in a document so that new projects can easily find
the info. There is the opportunity to make a general document
and put it to GGF.
Mike and Roberto should create a draft for this document,
in the format of a couple-of-page operations guide.
This document should contain the specific schema, the name forms
to be used and the tree organization. And there should be some
info about who needs the directory, and specifically about the
Authorization VO tools.
The HellasGrid CA (by Christos)
-------------------------------
The HellasGrid CA is managed by the PHYSNET team at the dept. of
Physics, Aristotle University of Tessaloniki.
The CA signing system is in a controlled environment on a dedicated
server that is not attached to any network.
The 2048-bit private key is kept in a safe, protected by a suitable
passphrase. The HellasGrid CA cert itself is signed by the
PHYSNET ROOT CA. Lifetime of the Grid CA is 3 years, of the PhysNET
root CA 5 years.
CRLs are issued according to the minimum requirements, Audit
records are archived for 10 years.
Authentication of end users:
Everyone has to come in person to the CA, which is still
reasonable given that Christos travels regularly between both Athens
and Tessaloniki, the two sites that actually use the HellasGrid CA.
In the future a new RA will probably be established in Athens.
The authentication policy, being a bit cumbersome in the long run,
is likely to change within a year.
A pointer to the CP/CPS is on the CrossGrid web page (see above). The
OID is 1.3.6.1.4.1.13089.2.1.1.1.3
The HellasGrid CA cert is particularly "feature rich" with lots of
extensions. It is Christos experience that this is extremely useful:
users can use this info to find the proper information back.
On the other hand, Roberto has always favoured less info, since
the exact information is likely to change more frequently that the
lifetime of the cert. It is clear that GGF is the proper forum to
discuss such matters.
Brian will send a overview of possible extensions to the list for
reference.
CRLs and CRL "validity"
-----------------------
Problems with the CRL publishing by DoESGs earlier this year was
mainly due to a communications mismatch: lack of clear documentation
on the use and on what the community needs to get things running.
The use of the CRLs is required in EDG TB1. To facilitate the
retrieval of new CRLs, this there is a tool distributed as
part of EDG TB1 that does "wget". Since many of us come from a
Globus background the most obvious thing was a URL with a PEM
formatted CRL, since that's the format used by Globus.
Also, Globus uses particular conventions to interpret the CRL.
The nextUpdate field is interpreted as "valid until". This
is a mis-interpretation of the X.509 standard: if the ITU
had intended "validity", the field would have been called "validity"!
Mike and Tony opened a bug with Globus on this issue.
CRLs were introduced in the Globus Toolkit about 5 years ago
in request of a different party for formal reasons. In
reality, Globus currently does not really care about CRLs.
But EDG does care, and requires CRLs for use with Globus.
It is clear for these and other discussions that a *single* document
is needed that details all the EDG requirements. It should
include required publishing info, file formats and a brief
statement of its intended use. Anders volunteered to write
this document.
Next Meeting
------------
It is generally felt that the current meeting is slightly too short,
since we never finish the agenda. To increase efficiency, the next
meeting should probably be a bit longer (1.5 days), starting at 1 PM
on the first day.
The exact date/time will be discussed on the mailing list, the
proposed meeting place is CERN. The meeting must be held before
October 15th.
Other nice dates:
* 5th EDG Conference, first week of September, Budapest
(not a particularly suitable location for a CACG meeting :-)
* October 2002: GGF6 in Chicago.
Action List of the 6th CACG meeting
-----------------------------------
6.1 OpenCA alternatives
by: Christos, Jens, Mike
On other open-source products besides OpenCA: several
alternatives are available. In particular:
a) Christos will send more information on "CSP"
b) Jens will send info on
c) Mike will send info on other packages
6.2 Renewing certificates with same DN but different key in OpenSSL
by: Mike
Some confusion still exists on renewing CA root certificates,
especially how to implement the use of new keys for a
certificate with the same DN. Mike will contact the Von Welsh
and Doug Engert about possible solutions and guidance.
6.3 CA directory configuration to be put in CVS
by: Roberto
The CA directory configuration and examples are not yet in the
CVS repository. It is on Roberto's action list.
6.4 Update of the CNRS CP/CPS regarding catch-all
by: Sophie
Sophie is to contact Jean-Luc Archimbaud about updating CP/CPS
to act as catch-all.
6.5 CP/CPS of NorduGrid
by: Anders
The CP/CPS for NorduGrid will be distributed by June 30th 2002.
6.6 SubjectAltName convention for host and service certs
by: all
It is strongly recommended that all CAs put the FQDN in
the SubjectAltName extension for all host and service certs.
6.7 Link to CrossGrid CA web page to be put on "marianne.in2p3.fr"
by: Sophie
A CrossGrid Information page is available on the web at:
.
The link to this page will be put on the EDG "marianne" site.
6.8 Pre-screening of new CrossGrid CA CP/CPSs
by: Brian, George and Rafael
New CP/CPSs from the CrossGrid CAs are to be pre-evaluated
by this subcommittee before approval during the 7th CACGmeeting.
6.9 Presention on the new CERN CA
by: someone from CERN
More information on the CERN CA is in a presentation, which
will be sent to the mailing list.
6.10 CA scaling graphs
by: Dave and all
Quarterly data summary (issued user certs, hosts certs, renewals,
revocations) to be made and collated for each meeting.
DaveK will send the request of to the list.
6.11 Renewal section in the minimum requirements
by: all
A "renewal" section is therefore needed to be added to the
minimum requirements document. This item should be discussed
on the mailing list.
6.12 Use of HSMs allows a CA signing machine to be on-line
by: Mike
The extact phrase to be used in the new version of the Minimum
Requirements about on-line CA machines regarding the FIPS-140
standard at Level 3 will be sent by Mike.
6.13 Authentication procedures by RAs
by: all
Further discussion on RA authentication procedures for a "Test
Bed 2 version" of the minimum requirements should be done
via the mailing list before the end of the summer.
6.14 Discussion on the basic ruleset for the automatic evaluation
by: all
The content of the ruleset to be used for automatic evaluation
of CAs in the CACG should be discussed on the mailing list.
6.15 Explanation of the ruleset syntax used for the automatic evaluation
by: Brian
Brian will send out a mail with the working of the ruleset
and (thus) initiate the discussion.
6.16 FZK "GermanGrid" CA RPM to be created and put in Release 1.2
by: Anders
Status: DONE
The RPM containing the root cert, CRL reference and the
signing policy will be created by Anders and distributed to
the EDG testbed sites as part of release 1.2.
6.17a New CrossGrid CAs
by: Christos, Pawel, Jan
Send the draft CP/CPSs to the mailing list
6.17b by: all
Discuss the CP/CPSs within three weeks on the mailing list
6.18 Create CrossGrid CA RPMS
by: Anders
If a new CrossGrid CA is accepted after discussion, create
the RPM and put it in the EDG repository.
6.19 CA publishing directory documentation
by: Roberto, Mike
This document should contain the specific schema, the
nameforms to be used and the tree organization. And there
should be some info about who needs the directory, and
specifically about the Authorization VO tools.
In the format of a couple-of-page operations guide.
6.20 List of possible X.509v3 extensions to be sent to the list
by: Brian
Brian will send a overview of possible extensions to the list for
reference.
6.21 Single-source document detailing the requirements for
new CAs
by: Anders
Anders will write this document for EDG. It will detail what
is required to include a new CA, and what the CRL is used for.
6.22 Date for next meeting
by: all
Discuss new date on the mailing list. It should happen
before October 15th.