EU Grid PMA 2005-01-27

AustrianGrid CA — Willy Weisz

Project in Security Middleware work package of Austrian Grid.

CP/CPS based on RFC 3647.




UE: This is not in the policy: RA/CA is generating the private key.

WW: last-minute change. Will submit this as new CP/CPS if this is at least as secure as user-generated keypair.

Identification and authentication

Action: Remove provision for fax, phone identification.

Certificate Issuance

Acceptance and proof of key possession

DG: is there any thing to prevent user using key before it is marked active?

WW: RP cannot retrieve cert. If not accepted within short period cert is revoked.

WW: Will retain this acceptance process

JJ: Could set notBefore entry to some time in the future. May be problems signing acceptance before cert becomes valid.

Certificate life cycle


DG: Suggests to use browser-generated keys, or java applets Setup CA so that key never goes to disk. Stay within same SSL session.

DK: Some RPs unhappy with even encrypted private keys. We have “MUST NOT” in min reqs relating to CA/RA generating private keys.

MS: Problem not only channel security. Security of box is important. You must prove that server is secure (which is impossible). We don’t have templates for this type of service.

DQ: source for applets in Globus CVS. Part of the COG kit.

Switch PKI — Rolf Gartmann

CA Namespace

Private Key of CA

Name uniqueness

End-entity Certs

Proxy certificates

Approved pending CP/CPS changes and RA side-letter.

RC: Have to add Globus signing line for each RA/Organisation “/C=CH/O=”. Could issue certs with “/C=CH/O=Grid/O=” Others: Could take 6 months for sites to update and approve new RA! Also, need to avoid conflict with CERN namespace

WW: second O= is not allowed in X.509

Agreed to have long list of organizations in signing policy file for now. What if it doesn’t work? Unclear for now.

Switch packages will have 6 CA certs and CRLs.

NIIF Hungarnet — Tamás Máray

NIIF/Hungarnet the Hungarian Research Network


Online CA using Chrysalis Luna crypto hardware. Trusted computing base uses Sun hardware. Linux management workstation and firewall. Certificate and CRL published in NIIF directory.

Management console needs USB key and password to access.

One CPS and multiple CPs. One is a Grid CP. Grid ones have been translated to English.

JJ: Are there differences between Hungarian and English version?

TM: Plan to make the English version the primary version.



UE: more difficult to write completely new documents. Easier to extend.

MH: recommends having seperate documents for Server and Personal CAs.

JW: If a user wants a cert they need to have a project leader in Hungary

TM: Typically such a project leader will exist. Need to verify that a user belongs to an institute. JK: This is the job of the RA.

JW: e.g. Someone in Hungary who has contact with DEISA. Who does he go to for a certificate?

TM: If someone wants to go directly to RA they would have to bring official documents to verify that he belongs to an institute.

MH: For DOE Grids, each grid project has a RA.

DK: Assumption that projects are going to be static and well-defined. There maybe just one member in Hungary who is interested.

NF: Similar process for SEEGRID certs

BC: From RP POV we expect that you collect enough info that when you reissue with another DN you make sure it’s the same person. As CAs you limit who you issue certs to.

WW: If a user be registered with an institutional project sponsoring institute takes a certain amount of responsibility for user.

Others: Mixing projects, institutions with identity

New VO has been setup in Hungary for users who don’t fit into other VOs. But membership requires a cert to exist in advance!

DG: What is the recourse for non-project users? Institutional representatives?

TM: Already have contacts in large organsations. Going to setup RAs in these. Through these can cover geographically the whole country.

JK: Revoked certs are removed from the repository. Is this a bad idea?

JK: Cessation of services. “NIIF can terminate their service and revoke all certs”. Need to provide CRL.

BC: For signing, have to keep the CRL forever.

DG: Signing is outside the scope of this group.



Approved: pending new version and two-week review.

TeraGrid CAs — Mike Helm

CA Policy: not yet published.

Addition, Removal, Reinstatement

Interested in cooperating with TAGPMA but not sure what they want to do.


Checklist for evaluation.

TeraGrid Security WG has no connection with CA managers



JW: Users have to request access per site. Need discussion between DEISA and TeraGrid

Grid-FR In-depth status report — Sophie Nicoud

Retaining existing hierarchy.

Grid-fr will issue certs for grid users in France, for projects in which CNRS is involved.


JK: Will it be possible to download certificates for user or server? This could be used by email harvesters.

SN: We publish only user certificates, and they must be imported in the browser.



RA Organisation

Certificate Request Procedure

Request verification

Acquisition of the certificate

Host and service certs


DG: Other CAs should consider giving in-depth reports

German CA Coordination — Ursula Epting & Markus (?)

Currently we have existing GermanGrid CA and NREN-run DFN CA.

Could it be accepted that Germany has two CAs for slightly different purposes? In future it might be possible to coordinate.

DFN getting some DEISA/grid users and want to get grid certificates from one CA. It would be very useful if DFN were accredited. CP/CPS has been written, RFC compliant, in German and English. Would like to go through accreditation process.

Want to plan migration but it’s going to take longer than a few weeks. Some German people don’t want to get certs from FZK. Easier to get certs from the NREN: DFN.

RPs want a stable, well-run CA. Any well-run NREN should be taken very seriously as a CA. Makes good sense to run the two CAs in parallel for some time given the existing CA.

WW: Why couldn’t DFN act as an RA for GermanGrid CA?

DK: Suggest that NRENs should be a special case when replacing an existing CA.

TG: Group is now getting big. Might want to consider two-tier membership: executive committee and body of members.

UE: Want to discuss scalability. Currently only support small area of sciences. Plan to add more grids and areas.

LF: Diego talking about RedIris CA, so this issue of NRENs running CAs is appearing. How long would it take to merge in German case? Is it difficult?

MS: definitely over a year. We should push developers to support hierarchies.

We already have some NRENs. Where are the other NRENs?!

TG: will NRENs want multiple CAs accredited

MP: NRENs generally accepted as representatives of academic community, so they would not support, say, a university to do this.

JW: Also some national institutes such as UK eScience, which is not an NREN.

TG: PMA document designed to allow orgs to grow. Min requirements help to raise barrier.

GGF Update — Darcy Quesnel

CA Ops Update





It will be meeting at IGF meeting in Seoul

International Grid Federation

Plan to have CAs accredited by just one PMA, but RPs should be able to trust any accredited CAs assuming minimum requirements are common.

Yoshio’s min requirements comparison has been useful.

MH: Maybe we should push these requirements as GGF profiles

TG: Publish as an informational so that we don’t give much control to GGF.

DG: Want change management, to keep track of proposers, etc.

MS: IGF should agree, write and publish. Need publishing be fast enough to be at most one step behind “current” version.

DQ: Should be possible to get GGF publishing cycle down to 4 months.

Publishing alternative is IGF and PMA websites.

DK: talking about moving from three documents to one

Multiple profiles for classic, SIPS, etc. PMAs may have expertise in particular areas and will develop their “own” profile.

European Authentication and Authorization Roadmap

eInfrastructures Reflection Group

Discussing Authentication, Authorization, Resource Usage, etc.

JJ: Someone has to build the infrastructure

DG: New projects will implement the policies

JJ: Update on how we will implement eIRG policies

DG: On agenda for next meeting