[31.05.06, morning, and some of the CERN afternoon bits: Minutes by Licia] Welcome and Round Table David G welcomed the participants and bashed the agenda. The first item in the agenda was the appointment of the EuGridPMA chairman: David G was re-appointed for another year. A round table of updates followed. Roberto Cecchini reported that the INFN root CA (five years validity) will expire in September06 and he asked whether he should renew the cert using the same pub key or whether he should issue a completely new cert. No objections were raised to renew the root using the same pair of keys. Roberto will verify if there are any problems with the verification process and will report to the list. SWITCHPki have plans to migrate to a new hierarchy in the fall 2006. NIIFCA will take over the role of issuing certificates in Hungary as June 2006. An NIIF-CA RA has been established at RMKI premises and this CA will be dismissed. Milan reported that CESNET's old CA will expire in three weeks and a new distribution for the new root will be required. The new root is already working for several months. The plan of OCSP implementation has been postponed due to the lack of resources. NIKEF CA migration to SURFnet is still ongoing, but it's not happening as quickly as expected due to other engagements on SURFnet side. Update from the TAGPMA Darcy gave an update on the work of TAGPMA which includes North, Central and Latin America CAs. The TAGPMA charter was finalised in September 2005 and the kick-off meeting was held in Brasil in March 2006. The profile for short-lived credential was approved in November 2006 and it is available on the TAGPMA website. Update from the APGridPMA Yoshio gave a update about APGridPMA. Yoshio is drafting a guideline to auditing CA which will be available on the GGF website. New CA: CERN-IS Emmanuel presented the new CERN-CA. Roberto evaluated the CP/CPS and sent some remarks to the list, which were about: - security of the CA: Roberto detected some malfunctioning of the firewall. - CERN RA procedures: it seems that detection of users leaving CERN is not properly done. A discussion followed on the role of the RAs in general. It was concluded that CERNS's problem is common to many RAS as in most cases RAs are not involved in the process of managing users. It was agreed that the identity vetting process and time shifting in CERN case are ok. - CERN on-line CA procedures were discussed. The procedures used for the renovation of certs were discussed and it was agreed that for the renewal users must use their certificate to authenticate to the system and request the renewal. A long discussion followed on the security of CERT online CA, which is protected by a single firewall. Further issues that were tackled were about the IdM that should be secured (and encrypted) and two-factors authentication was suggested. Not clear what the second factor should be, whilst the first factor should be the classical username/password. It was agreed to use as second factor one of the elements that is already in the database. [31.05.06, remainder of afternoon. Minutes by Jens] Licia presented TACAR potential proposed policy changes: * Need for Trusted Introducers ("distributed Licias") who act on behalf of Terena. Suggestion: Any member can nominate someone but has to be approved by majority - and Terena. One per (large) country, or continent. Need policy board for TACAR? Must have F2F'ed (ie exchanged keys) with Licia as part of appointment. List TIs on web site. * New interface, not operational yet, easier certificate download including multiple downloads - Milan has tested this. Hierarchy IGTF-approved/ * Replace PGP? E.g. to use X.509 with SMIME. Trust of signing certificate - MUAs tend to import the certificates they see. And then don't check CRLs. We tend to use X.509 more often. * TACAR's cert is self-signed, suggest replacing with SCS under Globalsign - agreed. * Provides bulk download where users can select which CAs they want. Suggestion to provide fast-click all IGTF, all classics, etc. Mozillas don't ask about all - only the first - but Milan has a magic script that should work around this. FIPS 140-1 L3 is fine - doesn't have to be -2 L3. Secure logging required for an HSM that is always activated, firewalls, scanning - part of arch because otherwise a compromised machine can issue certficates and no one will notice. DoE has private VPN, no other machine can access it. One firewall on the machine, another for users inside CERN, and one more for people outside. Best to sign on the VPN. Best to automate checks but not everything can be automated. Good thing to have ca op check the output - DoE checks requests after they have been signed and revoke the bad ones that slip through. Additional diverse protections (e.g. a linux firewall in front of the Windows firewall) increase protection but spread the support resource/training staff. DoE separates CA op, admin, firewall, intrusion detection teams. DoE actively trying to break security but has now switched to social engineering which seems to be the easier target now. Who can request host certificates? How CSRs are validated. Users use the IIS server on the _same_ machine - CERN argue that it is easier to secure a single machine. How well protected is the issuing machine then. How secure is the logging, if people tamper with the OS. Hungary and Czech R have separate firewalled signing machine. DFN and UK will also have it. DoE has the web server on the same machine, but has gone through a very tough firewall test - and is also on a VPN. Suggestion that the PMA should review the US govt common criteria certification that has been performed on the CERN setup. Volunteers: Jens, Tony, Tamas, Christos. E.g. WebTrust, keywise. Need better description of DoE setup for reference. [01.06.06. David O'C] CERN CA -------- Alberto: will review architecture and change to either firewall machine and add security checking of traffic _or_ to seperate web server from signing machine. David G: if we can compare it to existing Online ESNET or NIIF that should be fine. Would reviewers and community be satisfied, assuming it is well documented and implemented? Jens: difficult to say without seeing it. Christos: Would like to see clear decisions. Roberto: understood there would be another round of presentation. David G: ...in principle there should be no further issues. Milan: Not sure that just one of these changes is enough. Existing systems have both seperation _and_ firewalls. Jens: need a better description of Tony's setup for comparison. Christos: one thing is the architecture. Also need to synchronise minimum requirements with what we said yesterday. Would like to see this in the minimum requirements and then present again. Roberto: some discussion points raised yesterday will be discussed in the minimum requirements. Minimum requirements for HSM are a little bit too generic. Darcy: we should acknowledge that the process has not been that good for our CERN colleagues. Dave K: certainly true. But we should now have a better approach to minimum requirements. Alberto: CERN CA under lots of time pressure. Bob: does it meet the minimum requirements now? David G: too much of the requirements are in minutes and presentations Bob: There are lots of other places this can be attacked... David G: group will discuss on email and if it matches the existing infrastructures and we trust the implementation then it can be accredited. Christos: will the CERN CA issue certificates to all CERN affiliates around the world? Alberto: we will refer people to national CAs. Ian Neilson has sent an email on this discussion Croatian CA -- Dobrisa Dobrenic ---------------------------------- CP/CPS based on RFC 2527 CA key 4096 bits long User Certificate can be issued to someone "firmly acquainted with RA" Jens: invitation for social engineering. Willy: leaving it out will protect yourself "you did it for him, why not for me?" OID not yet registered Jens: looks very good. What is the problem with the OID? Dobrisa: It has been reserved, but don't know why it is not registered? David G: Who is the ITU-T or ISO member for Croatia? Dobrisa: Would like to use this arc. Jens: namespace is quite short. problems to coexist with another CA Dobrisa: is it possible to have two CAs with the same DN [namespace]. Allow for academic CA/commercial CA How do you distinguish between certs issued ? Dobrisa: based on issuer Milan: because software is not looking at issuer, we should be careful. Bob: safe deposit box. what is it? Details... Dobrisa: card-controlled access to room. Key for each box. In sealed envelope in our office. David: you will need access every two working days to issue 100 certificates per year... Asli: need continuous access for revocation. Also can someone without user cert request host cert? Yes, but procedure is as strong as getting user cert. Willy: how do you check that person is entitled to request host for particular host cert. Dobrisa: check with organisation that person is entitled. Milan: Key Usage: set very broadly for user certificate, if you intend just for grid authentication. Dobrisa: would like to issue certificates for other purposes. Milan: best practice is to divide usage between several certificates. Christos K: not what 99% CAs are doing. Dobrisa: don't allow to have more than one cert with same DN in CP/CPS Milan: recommend removing non-repudiation and document-signing Christos: problem with multiple certs. Difficult enough to educate users with one cert. Milan: the key usage in the cert should tell the software which cert to use. Roberto: would need to patch OpenSSL CA. Can't issue certs with multiple DNs. Milan: why is non-repudiation on the host cert? Dobrisa: I don't know. Jens: UK CA can renew host certs, but requires some user/client bits set. Allows host cert to send signed email, etc. Nuno: should use new CP/CPS format. David G: new one better for automatic translation Tony: new format much better organised. would like to switch but requires some time. Christos: converted CP/CPS without making any changes and took 1 week. David G: would SRCE consider rewriting? Jens: don't think it should hinder accreditation Minimal Requirements -- Jens Jensen -------------------------------------- Discussion on interpretation of SHOULD. Minimum requirements are stopgap instead of real risk management. Renewal if "RA can ascertain protection of private key" Problems if HSM vendor goes out of business, this applies to software too. Dave K: worried that it sounds like the minimum requirements will have to be modified before CERN is approved. Christos: process is unclear. need to put new details into minimum requirements before accrediting. David G: we reached consensus yesterday, and we can produce new draft minimum requirements. Tony: they have shown how they are roughly equivalent, and they can be accredited. The minimum requirements can be updated for the next CAs. Willy: They should be accredited under current requirements + our understanding. Next ones will get new requirements. Some discussion about cars without wheels. Christos: we're almost there with CERN but I don't like it when we sometimes approve and other times send away. Dave K: when they presented before we should have told them then that we needed to update minimum requirements. David G: minimum requirements didn't say anything and we're free to interpret. We have reached rough consensus and now we want to codify the consensus in the requirements. Dave K: yes, but it may take months to codify the consensus. Eduroam - Christos K --------------------- Bug on Windows, doesn't pop up window to enter passphrase for key. Eduroam--IGTF interconnection. Either single at the top level or one per nation. Tony: will support the single one at the root level but not interested in doing it at national level. Roberto: should we proceed if we have to tell users to leave their certs unprotected? Classical Eduroam doesn't need user certs. Bob: Need local contact information. Find where a user is connected _now_, not at their home institution. Tony: certs contain contact information. Dave K: maybe not up to date Minimum Requirements -- Live! ------------------------------- ### Identity Management ### #### Second authentication factor Willy: what about someone using a smart card? Dropped requirement for 2nd factor to be in IdM #### Re-keying Willy: is this relevant for the IdM discussion? Dropped #### Status change in IdM Willy: if the user is dropped from the IdM then the cert should be revoked. David G: higher standard than for existing DB Bob: even if they're removed they'll still be in other authz DBs Milan: In automatic system we don't have the RA. In classic system the RA could be informed and should react. Christos: if totally automated, user must reappear to RA. Not a problem for CERN, but we should require it. Tony: lots of old entries in our personnel database. Willy: suggestion that the IdM must indicate any relevant changes to CA. Christos: not always possible to get such information. If the RA has it then they can react. Jens: DB is not a person, it will happily continue. Milan: make it work automatically. If the person leaves, the cert can be revoked. If automatic, the system must be described. RA requirements apply to it. Willy: CP/CPS has to state that DB changes relevant to the certificate are sent to CA. Alberto: this is a general issue not specific to the IdM case. Moved to general RA section ### HSM ### HSM architecture should provide for a tamper-protected log of issued certificates. David G: syslog to a line printer. If signing host is distinct from web frontend then might be OK to keep logs on signing host. Tony: how does frontend communicate to signing host? Milan: several protocols... HSM guideline document to be written. Minimal Requirements -- Jens -------------------------------- Short 2--3 min discussions ### two operators ### require 2 ops to activate signing key. Willy: opposes it for revocation signing. David G: overkill for this type of CA. we trust how we select our operators. Yoshio: we usually recommend it. Split passphrase in two parts. David G: for CAs previously operating with single operator, would have to revoke CA cert. Milan: system requires 2 hardware tokens. Require one at monitoring centre come with CA admin to activate thing. doesn't know what he's doing, but is supposed to write down every usage of the monitoring token and sign it. so we have proof that a particular CA operator signed. A witness. Tony: we have multiple roles, each with different access and cards. We should explore multiple roles of the CA. ### renew vs rekey ### Best common practice is to rekey unless key held on a hardware token. Tony: users don't like it. renewal means users don't have to copy private keys around. RP may check if certs are renewed rather than rekeyed. David G: little difference between copying one or two files... Tony: how often can we renew? Jens: what happens if you import a renewed cert? does the browser show it as a second cert or replace? David G: need to test offline "renewed for up to _n_ years" for what _n_? Should it be years or renewals? "Credentials can be renewed without a new identity vetting for at most _p_ years" renewed or rekeyed... Some discussion on lengths and times. Bob: have to be more specific about "new verification of the identity data" David G: if the RA is positively sure the user is still valid. Reimer: really just checking affiliation. Tamas: who does the personalisation of hardware tokens? CA or user? David G: if the CA generates the key on the token, should not escrow the key. Milan: the PIN params are set at the same time, so some issues here. Willy: when tokens become more widespread we should have regulations at the beginning of the accreditation process. ### lifetime of online CAs ### Milan: the same as offline. [20 years] Reimer: in HSMs so fine. ### User Leaving Community ### Should revoke a user leaving the community? Reimer: community is defiend as the people it serves. Grid CAs should issue a cert to anyone who wants to do grid computing... ### CRL Delivery ### Do we need CRLDistributionPoints extension in cert? No. We don't forbid including an LDAP URL. ### Host Cert Request ### Willy: user from one instituttion requested service (?) cert for a host in a different institution from local RA. Got a complaint from RA of second institution. Service cert should only be issued if that service is administered by that host's administrator. Tony: different requirement in US. Remote sites don't want to become grid users to get cert installed. David G: delegat it to site admin, who is admin owner of machine. Tony: they don't want to do that. they'll install for the VO, but not get involved in cert request. David G: If you authenticate to a system that presents you with a service cert would you have any confidence that you are talking to the same host. Tony: only service admin can request service cert for specific hosts. David G: if you include DNS host in subjectAltName client will accept it. Perhaps for those specific service certs subjectAltName should not be included. Jens: shouldn't that apply to all service certs? David G: yes, unless it's requested by the host admin. Milan: how can you tell if it is a service cert? Tony: service/ in CN Some description of globus service certs/clients Milan: if we have a cert for a service, can the service be connected by other software clients? Jens: No. If it works with non-globus clients then it's no good. Milan: does the service operator want to let other non-globus clients connect? Milan: by including subjectAltName just saying that it runs on this host. Willy: Tony is talking about US situation. In Europe, which CA is responsible for service certs in different countries. Jens: service and host certs should be issued by person responsible for that host. And DOE Grids have a different but equally good system, so a SHOULD would be fine. David G: coming back to Europe. It would have to be the CA for the country in which the site is located. And it should prevent the case where the sysadmin doesn't know about the cert! Tony: talking about an international service running around the world... Milan: whatever hostname is included in cert in subjectAltName, CN, or after / in CN, the RA/CA should have approval from the owner of the domain name. ### Timeliness of revocation ### US RAs are requesting to have 24 hours to revoke cert. Tony: got in trouble for revoking "too quickly". User allowed access to cert to boss, but was still "in control" David G: can RAs block revocation for a "very important" service? CAOPS Meeting --------------- Alan Sill & Jesus Luna join remotely. Lots of CAOPS documents. Very few finalised. Already in use and not much interest in finishing them up. Proposal to arrange documents into groups. Create a glossary to capture terminology. Wiki page for the glossary and at certain points capture the contents. Document to define what an "authentication federation" is. Darcy: division makes things much clearer. Tony: require all CAOPS authors to submit glossary terms. ### OCSP ### Milan: got to the stage where OCSP is to be used for almost everything including authorisation and revoking proxy certs. Jesus: trying to perform validation mechanism. Blacklisting not a good term for the document. Milan: every use of OCSP that is not just providing revocation information I am not willing to accept. I plan to run OCSP service on my own. Other point is providing some global OCSP for grids. If we have two services with different behaviour we could get into trouble. Christos: requirements document should not specify blacklisting or things like this. Should just have requirements. Milan: we will have at least 2 implementors. At some point we need to decide if we want to provide more than just revocation. Christos: could provide use cases, but purpose is the requirements and not to specify how operators are going to operate the service. Jesus: agree that document should be as simple as possible. Some mention of David Chadwick and Credential Validation Service. Christos: issue of HTTP proxies Jesus: Will add note about use of caches Milan: add sentence that caching must be avoided ### Validation & blacklisting ### Christos: discussion on whether validation should fit in CAOPS. Jesus: not sure if it is relevant in OCSP requirements doc. Have in some other documents. ### Guidelines for Authentication Service Profiles ### one of the most important docs we have in the pipeline. more than just operating CAs: about international trust. Users want to use their institutes for authentication. Grid identity provider and authentication federation documents are background. Could reference glossary and existing authentication profiles. Also in examples. ### General ### Willy: difficult to follow CAOPS discussion because we are not familiar with documents. Certificate Profiles ---------------------- Clarify what we shall and shall not use in the subject DN. David G: recommend that we put restrictions on this in minimum requirements. Won't include CAs in distribution if they don't meet profile. Darcy: old-style proxy certs rely on multiple CNs. Tony: could move random number into a separate CN. Milan: but some software may only show last CN. Need to impose an ordering. Sequence of set 1, with most varying component at the end of the sequence. Some discussion on creating a seperate document for Certificate Profiles. David O'C: why not part of minimum requirements? Dave K: you'll have to change distribution, so there is a category of accredited and accredited with extra requirements... [02.06.06. Kaspar] Grid and CA plans for Romania - Cosmin Nistor --------------------------------------------- Grid task force initiated in July 2005, with the goal of developing a plan for the implementation of the national Grid infrastructure. Infrastructure to be based on competence centers and cooperation with international efforts. It's planned to accredit the CA with EuGridPMA (in cooperation with Hungary). ROSA, the Romanian Space Agency (established in 1991), chosen to run the Romanian Grid CA, as part of the pilot project. First draft of the CP/CPS has just been written, will begin with an offline CA. CA expects to be ready for service in summer/fall 2006, more information should be available by next meeting (Karlsruhe). Trust matrices and evaluation against APs - David O'Callaghan ------------------------------------------------------------- Continuation of Brian Coghlan's work (part of David's PhD thesis) Current EugridPMA trust model can be considered as a "non-signed Bridge CA" (collection of independent, self-signed trust anchors). Trust evaluation can either be static (relying on published policies/procedures) or dynamic (based on CA's activities). Possible Services based on trust evaluation: trust matrices (graphical display with feature or acceptance matrix), GSI/SSL authentication (extended by trust evaluation library), validation service (outsourced to a trust evaluation service), issuance of validated credentials. Current design includes three components: trust evaluation engine (ruleset based), trust matrices and validation services. Based on Kawa Scheme (a functional programming language), trust matrices service is implemented by a Java servlet (running under Tomcat). Rules can refer to certificate information such as key length, validity period and certificate extensions (policy OIDs etc.). What values to use in rulesets, how to assign and how to aggregate them? Currently to be considered as open questions, quite a number of options available. Near term plans: establish a pilot validation service before the next meeting, allow CAs to update their descriptions and the PMA/RP to update the rulesets. Jens: for writing rulesets, wizard-like tools would probably help people to write new rulesets (so they don't have to deal with Scheme or XML syntax intricacies). Benefit for EuGridPMA to be evaluated after availability of pilot service. CA In-Depth Update #1: UKeScience - Jens Jensen ----------------------------------------------- UKeScience to roll over to new hierarchy (two-tier): eScience Root with subordinate CAs. Three of them considered at this time: eScience CA, SLCS top-level CA and a Training CA. Root key is encrypted with AES-256, protected by a strong passphrase split into three (2 out of 3 required for key activation). Policy for the Root CA (intentionally) written from scratch, paying attention to legal requirements in the UK. eScience CA will be implemented as online CA (based on an nCipher HSM). Separate hosts for Web interface, signing machine and logging (DBMS), back-end network separate from Internet, signing host without connectivity to the outside. How to cope with time synchronization on the signing host? To be determined yet, possibly with a GPS receiver (preferrably with a receiver placed on the roof of the building, as suggested during discussion). HellasGrid CA update - Christos Triantafyllidis ----------------------------------------------- CP/CPS based on the UK one, CA operated by the University of Thessaloniki. Current CA cert expires in August 2007, so new CA cert needs to be rolled out in August 2006. Current procedures are rather error-prone (manual steps carried out by CA operators), goal is to automate checks whenever possible. New hierarchy is two-tier: Hellas Grid Root CA with subordinates HellasGrid EE CA and HellasGrid Tutorial CA, additional one could be SLCS (in 2007). Root CA is offline (key length 2048 bits), with lifetime of 20 years. CRLs issued every 6 months. HellasGrid EE CA (2048 bits) has lifetime of 10 years, signing host has no network connection, will synchronize clock via GPS. Plans to turn signing host into an online CA (with HSM), but not ready yet. End-entity certificates have have namespace with /C=GR/O=HellasGrid/OU=Institute/CN=RealName. Requests are handled at least once per day (manual steps carried out offline by CA operators). Subscribers have to accept the CP/CPS after receipt of the certificate within 7 days (cert will be automatically revoked otherwise). Milan: why set the nonRepudiation bit (in the keyUsage extension) for server certificates? digitalSignature would be sufficient, is different from nonRepudiation. ChristosK: no authoritative profile available when the extensions were defined. Follow-up discussion: a profile for Grid certificates is really needed, work on this has been done within the CAOPS WG. Tony: document needs to be revived (in CAOPS slot at next TAGPMA meeting?), plan and testing environment is needed, verification of profile with various implementations needs to be done. Mozilla and Grids - Tony Genovese --------------------------------- Mike Helm in dialog with Frank Hecker (see GridMozilla.doc document distributed on the list). Hecker to be invited to TAGPMA meeting in Ottawa (July). Mozilla CA policy (http://www.hecker.org/mozilla/ca-certificate-policy): Webtrust not mandatory, alternatives include ANSI and ETSI standards Plan: start with a small number of CA certs (1-4), then possibly continue with subordinate CAs. CP/CPS for top-level CA needs to be accepted by Mozilla. SCS Service and ServerSign EDU Accreditation - Milan Sova --------------------------------------------------------- SCS service offered by 8 NRENs (collaboration through TERENA), goal of the service: pop-up free server certificates. Press release issued in January 2006, first cert issued on 16 March, multiple dNSNames in the subjectAltName extension since 31 May. Some of the NRENs intending to use SCS certificates for Grid applications - next step: prepare accreditation of SCS under EuGridPMA, timeline for this not yet existing. Sample certificates: see e.g. https://www.switch.ch/pki/scs/ RA structure: currently 1 RA per NREN, implementation of additional RAs (including Sub-RAs) currently under dispute with GlobalSign (SCS supplier). Policy OIDs usage and 1SCPs - Milan Sova ---------------------------------------- Proposal: include OID for Classic AP into the policy extension of all certificates issued by EuGridPMA accredited CAs. Policy OIDs allow to distinguish between classic and SLCS CPs. Do existing CP/CPSes have to be adapted (include additional OID)? DavidG: should probably state something like "additional OIDs can be specified in the policy extension". Accredited CAs must not use these OIDs unless they have been certified under the respective authentication profile (i.e. OID arc). Benefit: would help to get rid of defining namespace constraints, since middleware could check for OID in policy extension. How should middleware deal with policy OIDs (e.g. versioning issues - want to avoid large lists of OID in certificates). Current proposal ChristosK): assign OID subarc to EuGridPMA/IGTF authentication profiles (including version numbering), recommend RPs to trust the OID subarc, (w/o version numbers). Closing - David Groep --------------------- Next meeting: in Karlsruhe, 5/6 October 2006 (two full days only). Meeting closed at 12:05 a.m. with thanks to the local organizers (NIIF).