Project in Security Middleware work package of Austrian Grid.
CP/CPS based on RFC 3647.
Structure
Institutions
Requests
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
CRL
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.
http://www.eugridpma.org/agenda/askArchive.php?base=agenda&categ=a043&id=a043s1t2/document
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 the Hungarian Research Network
NIIF CA
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.
Grid CP/CPS
Question
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.
CPS/CP
Comments
Approved: pending new version and two-week review.
CA Policy: not yet published.
Addition, Removal, Reinstatement
Interested in cooperating with TAGPMA but not sure what they want to do.
Responsibilities
CA
Users
Checklist for evaluation.
TeraGrid Security WG has no connection with CA managers
Conclusion
Questions:
JW: Users have to request access per site. Need discussion between DEISA and TeraGrid
Retaining existing hierarchy.
Grid-fr will issue certs for grid users in France, for projects in which CNRS is involved.
Catch-all
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.
CRL
Operations
RA Organisation
Certificate Request Procedure
Request verification
Acquisition of the certificate
Host and service certs
Migration
DG: Other CAs should consider giving in-depth reports
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.
CA Ops Update
Documents
Members
Documents
It will be meeting at IGF meeting in Seoul
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.
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