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. Structure * Single CA for /C=AT/O=AustrianGrid * Multiple RAs * RAs only have to check identity and affiliation * CA defines DN hierarchy * CA stores requests and documents in database Institutions * Institutions apply for permission to request certificates * Nominate one "interface person" Requests * Web Form * Requestor can choose affiliation * Private key and request generated and transferred to user, request entered in CA DB * Interface person is informed by e-mail * Appropriate RA also informed > 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 * Present identification to RA, in principle face-to-face * RA sends machine readble copy of document along with acknowledgement to CA Action: Remove provision for fax, phone identification. Certificate Issuance * CA retrieves authenticated request * Transfers it to the offline server for cert generation * Cert transferred to online server * Today: cert mailed to user * Planned: user gets hash to retrieve from server Acceptance and proof of key possession * After receiving the cert the requestor has to check its suitability * If given he sends back to the RA/CA a signed message of acceptance * After positive check of the signature the cert is marked active -- proof of key possession * The certificate is available on the web site > 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 * CA cert for 5 years * User cert for 1 year or less, if so requested * Revocation initiated by owner, or CA/RA if misuse is discovered * No revocation of revocation * Certificate may be re-keyed CRL * CRL published on web site * Life span: 30 days or at revocation, which ever comes first * OCSP plans > 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 * Statement that subsidiary CAs are not going to issue certificates in each others' namespaces. Private Key of CA * Stored in Swiss bacnk deposit * Suggestion to rephrase min req 2.4 to allow this Name uniqueness * Allows non-unique subjects for disjunctive key usage * MS: this should be allowed by min reqs, but rephrase to make unambiguous End-entity Certs * Must not be generated by CA/RA: prohibited in side letter * Reference which CP/CPS is used by OID * Extensions: basicConstrainsts & keyUsage * lifetime: 1 year + 1 month to allow smooth renewal of keys. * MS: support this change. Others: no problem. Proxy certificates * Will be supported in next version of CP/CPS * Convinced supplier with reference to RFC 3820 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 * One of the oldest in Europe (since 1986) NIIF CA * Free certs for research users * Not just for grid 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 * Multiple RAs * Name space /c=hu/o=NIIF CA/ou=grid * One year * email is identifier Question * Grid CP currently only allows personal certs * New CP for grid servers/services? > 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 * "project leader" approved by general manager of NIIF * Similar to Austrian "interface person" Comments * Problem parsing the published root cert: in PKCS#7 format Approved: pending new version and two-week review. TeraGrid CAs -- Mike Helm -------------------------- CA Policy: not yet published. Addition, Removal, Reinstatement * Doesn't distinguish between TeraGrid-origin CA's and external providers. Interested in cooperating with TAGPMA but not sure what they want to do. Responsibilities * CA * Need agreement between TeraGrid and each CA to make responsibilities clear * AUP for certs issued for authn to TeraGrid * RA identity validation. Tie cert to a TeraGrid project * SLA: notification to TG of outages, etc. * Users * must report account compromise Checklist for evaluation. TeraGrid Security WG has no connection with CA managers Conclusion * Short term: TAGPMA link Questions: * Will policy document be available for review? * Will TeraGrid CAs make policies available? * Is there a requirement from RPs to support TeraGrid CAs? * Can TAGPMA accredit these CAs? > 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. Catch-all * Subject name starting with /O=GRID-FR/C=/O= * Email address in subject name * EmailAddress= is deprecated * Move email address to subject alt name * Some software won't parse EmailAddress correctly * MH: EmailAddress is deprecated, sort-of: * Some email clients like EmailAddress in DN * If there are multiple addresses clients won't choose properly * (discuss tomorrow) > 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 * As soon as a cert is revoked a CRL is issued * Valid for 1 month * Re-issued each night * Version 1 * Stored in dedicated GRID-FR CA repository Operations * CNRS PKI is operated by DSI/CNRS in Toulouse * CNRS PKI in control of UREC/CNRS in Grenoble * 2 RAs, Edith and Sophie * CNRS CA software written and maintained by UREC/CNRS RA Organisation * Only the 2 RAs can request creation and revocation of cert via the RA site * In each unit there's a local RA representative chosen by RA manager * Access protected by IP addresses and RA certificates * CNRS-Plus issues RA certificates * CNRS PKI committee Certificate Request Procedure * Fills the forms * Units and institutes are chosen from a list * Institutes must contact Sophie to be added to the list * Key pair is generated by the browser * User receives receipt by email Request verification * RA receives email * RA must verify: * that no certificate with a small difference has already been issued * (e.g. Firstname Familyname, Familyname Firstname) * Change of email address * Two certificates for same host with different admin email address * personal information * job information * Unit, institute * Duration of user contract * Participation of the user in Grid project * RA request the creation of the certificate by signing the request with CNRS-plus certificate Acquisition of the certificate * The user receives a notification email containing an URL to get his certicate on the CA web portal * He can get his certificate only if he has the private key associated * Proof of possession Host and service certs * Requestor must have personal cert * Unit and the institute of host cert taken from user cert * RA verifies request * Verify that host is in DNS * That user is admin for DNS * The certificate is sent encrypted and signed email to the user * The email address is deduced from the user certificate Migration * Stopped renewal since December 2004 * Issue certs with validity until June 2005 since November 2005 * Start CA as soon as possible after accreditation * Provide RPM * Start to issue certs for persons working in French institutions and new units * Test accreditation of CA on each site of the Grids * Revoke all old certificates before the end of 2005 * Revoke Datagrid-fr cert at end of 2005 > 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 * Christos Kanellopolous is now co-chair * Session in Seoul * IGF Session proposed * GGF13 dates changed Documents * OCSP Requirements -- Olle, Mike, Milan * Grid PMA Model Charter -- Bob, Tony, Peter, Mike * finalised * Grid Cert Extension Profile (retired) -- Mike * Grid CA Common Naming (retired) -- Mike, Tony * renamed * Might revive this as an activity * Certificates for Automated Clients -- Steve, Matt * Authentication Profiles -- Tony TAGPMA ------ Members * Mostly North American members * Should be more contacts in Latin America: some contacts almost ready Documents * Charter -- Tony * Min Req for classic CAs -- Dane * Requirements for short-lieved credential generation services -- Dave It will be meeting at IGF meeting in Seoul International Grid Federation ----------------------------- * Promote tust peering between The Americas, European, Asian Pacific * Promote establishment of top level CA registries * Use GGF for publishing standards 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