EUGridPMA meeting, NBI Copenhagen, 26-28 May 2008 Minutes by Jan Javorsek (including mistakes, misunderstandings, missing bits and misspelled names) Round table introductions of participants. Szabolcs: 2 CA's, one dropping out since NREN's is not going to fold up. Very few news. Romania Grid CA: only 1 Debian weakness problem. Germany NREN New CP/CPS soon en force. 37 affected user certificates, many servers, over 900 certificates in all. Planning on SLIC servers. Implementing integration into grid portals. Statistics: 76 RAs, 357 server certificates, 445 user certificates. Mike Helm, DOEGrid - lots of news. Lots of news, plans for developing of the architecture etc. Plans to expand/clone pieces of the CA all over the country due to periodic catastrophic failures in Berkeley. Interesting issues. Audit not yet submitted. CP/CPS will have to be recast in the new format, probably first rewritten and then recast. Yoshio, Japan, will give an update also on the A/P PMA Ursula --- a bit affected by Debian weakness. 6000 certificates, 1/2 valid. I can say that user interface of new software development is ready in the English version Milan, CesNet: 4 certificates affected by the Debian weakness, 2 personal. Jens: UK Science CA: interesting from the Debian weakness: 73 weaknesses. 1022 user certificates, ??? server certificates. A. Person: helping with the Danish CA. Neaderlands: 51 Debian weaknesses, server certificates. Yoshio ====== Examinations for accreditation PRAGMA-UCSD CA accredited with classic profile. Ngo-NeTrust (Singapore) and NCHC (Taiwan) accredited only after a long e-mail discussion. Domain component RDN for issuer and subject DN were agreed as a strong encouragements for new CAs. Yoshio still chair, but with a deputy chair. Had to install a spam filter. 10 members, 2 in attendance. Next meeting with OGF in Singapore. Mike ==== Last meeting in Aucland, 3 CAs under review for many months. Big issues are CRLs for SLCS. Next meeting in July, at Merida, east of Carracas in Venezuela ... slightly difficult, there are problems with local connections due to an airline crash (airport closed). Dana: Latvia presents its new CA at SigmaNet ============================================ SigmaNet (LATNET), part of BaltikGrid, BaltikGrid2 + independent Geant, research in Grid and semantic web. Planning a Latvian grid project, depends on the CA acceptance :-) Organisations involved: IMCS UL, Riga Technical Uni, Uni of Latvia, Institute of Solid State Physics Grid Activities: lexical analysis tool !!! Currently: ~200 user certificates, 120 valid ones BaltikGrid users, ARC cluster users, Data Grid users? CALG (CA): april 2007, SiGMaNEt (Latvain NREN), upgrading to the new RFC. End entities: user, services, hosts. Research/science/education only. Signed cert requests via mail, arranged meetings with ID/passport/student card, printed request. Server certificate requests must be signed by administrator user certificate. All other communication via secure channels. Authentication limit from request: 7 days. RAs in Latvia: trusted individuals, none now, but planning in big cities where most research users reside. RA info published and done on signed agreements. Security auditing... the usual lists, Dana reported what things should be logged and audited. Physical protection: devoted room, safe-box. Key in safe. Media storage in several removable storage medial. Backups on CDs. Status: no certificates issued (forwarded to BaltikGrid CA, we are their RA). Root certificate is being reissued, CP/CPS has been reviewed and is being updated. General consensus that the CA can be accepted with the current version, but only update the CP/CPS later to the new form. Jenses comments: relevant RFC references, CRL lifetime issues, proof of possession of private key - answer: he has to present the request. Jens: and you have to check the public key itself; Willy: you have to see that this is the key you are certifying. Accepted when reviewers accept final updates after 15 days of ok silence on the list. Wily: using BouncyCastle to generate keys - are there any suspicions about the procedure? The key rests with the user, and it is limited to Java 1.6, where access rights can be set so that the key is never readable except by the user. Reply: it has been running well in Germany. Christos: but it was frustrating for users running too old versions of Java, at least 1.6. Mike: Debian problem actually raises the issue that the key generation and its random number is the Achilles key of the RA, and hence the CA. We are dependent on thing over which we have no control. Willy: Whence the idea, since otherwise I have no idea what is used to generate the keys. Mike: It is difficult to test the key provided by the user. And there is very little software seriously tested, and look at OpenSSL, which was FIPS 140 tested. What can we do about it? -Jens: We can set up a kind of tests and try to run them. -Mike: But browsers have not really been tested, although their basis are know. ---coffee--- MD-Grid CA presentation: Valentin Pocotilenco, Moldova (.md) RENAM (Research and Educational Networking Ass. of Moldova), NREN MD-Gird, NGI, 14. May 2007 - 6 research institutions MD-Grid CA, based on a number of existing CP/CPS. AOID still pending. More-or-less standard name schema. ID: exceptional via video with a photocopy of ID by mail. Server certificates require a valid DNS and administrators user cert. Questions: Willy, in the CA cert, the CP/CPS OID should not be included since any CP/CPS change would imply a change in CA cert. -Jens: What about ID delivery via mail? -Brasilian notariated model. -David: IANA will take time. -David: Problem with the name - the use of ISO country name as top of your name should have it delegated by the national ISO registrar, to be sure it is reserved for you, so perhaps you should use DC base. **we need a formal confirmation for this!* -David: Who do you serve? -Only grid users. In future, maybe research/educational for the country. Lidija Milosavljević: MREN CA (Montenegrin Research and Education Network) June 2005 established NREN :-) Montenegro GI: cooridnated by NREN: 13 members, faculties, teleco, 2 companies Questions: Willy: minimum CRL life-time? Hmm, a wording problem? The point is, that at least 7 days of lifetime is required... Also the C->DC thingy. Minor technical updates from Emir (e-mails, operational problem with the order in names etc.) Accepted with the changes pending and 15 days silence on the list. ---lunch--- Milan Sova: new CesNet CA Requirements: full featured CA system with multiple CAs, separation of roles, web administration, HSM support. Change from the commercial solution: licencing too expensive per certificate, so more open licence is required - with no limits on # of certificates per licence: open source. (Changing software was important, with Entrust that proved to be a problem.) Conceptually, the software has to be _federable_, so that we can use identity providers inside entities for identification. Also, we want to have the signing key delivered _out_of_band_. Decision: EJBCA, java-based open source Swedish thing. Open source, support for different HSMs (nChypher, Luna SA, PKCS11), everything has a web interface, but it has other interfaces for the signing machine and the database: XKMS, CMP, SCEP ... It could be made federable. (None of these interfaces gives all functions for the user UI, thought.) So WS (web services) is more important, since it provides the complete API. Architecture: User accesses the web page, get credentials from his home IdP (identity provider), which is passed back via an attribute assertion in the form of SAML, where it is federated and the request is passed via WS to EJBCA. Attributes used: permanent in time, unique to user and unique to service: eduPersonTargetID: key attribute. Authorization attributes: eduPersonEntitlement (one value per CA/profile) with optional fields, such as IdP id. Naming attributes: depend on particular CA, such as shibHomeOrg etc. Demo: Connection gets reconnected to the IdP, to the login, i.e. shibboleth login. With the auth done, the session is redirected to the CA site. There, the user gets the choice of the CAs that are available with his credentials. Interestingly, the certificates can have different subjects, according to the profiles in question. Also, the IdP sends all the available e-mails for the user, and the user can select one of them for the subjectAlternativeName, since that is how the profile was configured. Then, the user has to supply his public key, confirm her identity with his IdP login and hopefully, there is the certificate. When I try to revoke the certificate, I have to do the IdP login again. -Mike question: how does the user knows the EduPersonTargetedId? -He does not, it only binds the local IpD with the CA database. And, of course, the CA does not care anymore about the content, the responsibility is with the IdPs... Of course, we can present you all your certificates. -Mike: but if the user changes organisations, it is a problem of accountability. I have a new IdP and a new identity. Is it the plan to retain your ID? -We did not plan for that, since it is not a big problem in CZ, but it is technically doable. So we might look into that. -Szabolcs: If someone has his IdP access compromised or his identity of the IdP is destroyed, what happens? -That is the responsibility of the IdP. The tools for this are not done yet, but once the functionality is there, it will be introduced into the system. Only that now it is manual. -Jim: What about a secondary id method, not published anywhere? -Thinking about it, especially since I could rid of the forced secondary authentication... -Germany: Are you planning to put CAs other than MICS profile? -Actually, yes! -Anders: What about host certificates? -IdP's responsibility, this is done in the same way as the user certificates. But the IdP part is not yet ready at this time. Back to presentations: Re-authentication. 1.3 Shibboleth does not support forced re-authentication, so we build another API to IdP that supported it. But sh. v2 was going to support this feature, however, everyone should install it. Hm. So we decided for Shibboleth 2, and we dropped the "hack". Assertions. For auditing purposes mostly. signed XML message with attributes: attribute assertion. We want to store them, so we can prove the IdP really asked for specific certification attributes. The future. HSM support for the fronted since everything is done with client certificates, so we can't expose this key as it could talk to the IdP. The fronted needs an HSM. The code will be published once finished and polished. "Smart" WAYF & Login so that the system knows how to re-authenticate, probably solved by Shib2. Some of the Unis still want to cling to the classic RA model, so we need to support that consistently as if it were an IdP. About the second authentication model secretly presently. It could be done without the second re-authentication. -Willy: How did you get the administrators to cooperate? -Dunno, they are eager to cooperate. Missing the policies though. -Allessandro: Would you consider only supporting SLCS? -No, because I don't support only grid use cases, but also i.e. EduRoam. -Christos: We understand that you take one auth token and convert it to another, lesser one. But I always prefer going from X509 to a login. -Mike: Everything depends on the validity of relationship with IdP, and it is not easy for the relying party to act on it since it is depending on the IdP, since most legacy auth methods don't have a revocation and validity method. We cant go back from the X509 as an independent token to the IdP. -Szabolcs: Most universities in Hungary implement a two factor scheme for the university login, and you have to return the token to get back the money you payed for it, so you get revocations when people leave. -Some of them are thinking of PKCSI. -Christos: Have you discuss the IdP requirements? -First, we have to define the general policy for the federation. Then we have to work on the specific policies. So far, we have been just discussing. This is not for tomorrow, but for the end of the year. Self-AUDITS ----------- Discussion on self-audits, some problems, and people whose reports were not reviewed (CyGrid, Slovak Grid). Jens plans to follow up. David has limited news from BE Grid: European project for outsourcing the classic profile in a European tender... They have contenders and will have to choose in August. Strange side-effect. What about HellasGrid CA? -Chrisots: the biggest problem was a mishap in the database configuration. Also working on a new version of CP/CPS for robot certificates etc. --- presentation of the Bohr Institute --- coffee --- Debian Vulnerability Report by David ------------------------------------ 90% in 48 hours replied. Several others in the next days, one on Friday after the end of business hours. Then PMA released a new version with the advisory, and the advisory went over to the relying parties, which created some confusion. Friday the 22nd. Grid Canada had delayed with the initial response and kept rather quiet about it up to that time, in spite of pressure. David started sending private messages, and on Friday prepared an interim intern release without Grid Canada, which did have an effect. That would not have been necessary if they had reacted earlier. However, this procedure has not been discussed previously, and we need to discuss if it was appropriate or not. Several points: initial delay was 3 days for the warning, and the relying parties started worrying before that. And some e-mail addresses were not working, so we should define who should be behind it. -Jens: but an open address has spam, so it need a lot of work watching. What about and incident response group? What kind of response time can we expect from our CAs? It is also interesting to know that larger groups, such as EGEE, took 4 days to deploy the update (because the weekend), but the OGF was very fast. -Anders: The release got out at Friday at 16.00, and I distributed it in 2 hours. -Discussion: We could raise it with the big groups. -David: 4days of response delay is a lot. -Jens: It may not be our problem, but it is still a concern. -Anders: It implies a lot of time to investigate the problem. People are working on tools. -Dave: An implicitly you are doing a risk analysis. -Roberto: Grid has to be doing something equivalent to an OCSP. Since user browsers do not check the CEL, so revoking a certificate for a web server has no immediate impact on the user if the manager of the server does not care of it. OCSP is necessary, we know that CRL is not a scalable solution. -DOE: we are running it, no problem. -Milan: If it is not an authorized responder, it does not help anyway. -Dave: The fact is, you had to act as the security manager for the PMA, and you had to tell the CAs what to do and how fast. Perhaps we have to define that role and the actions we should all take. -Roberto: We had 4 vulnerable VOMS. I could not revoke them immediately, or should I? -Willy: Do you want to take care of people or of security? Because from the point of view of security, thousands of passwords could have been detected. -Christos: I should react, as a CA, in the same way for any host, even a VOMS. -Jim: What we should define is in what time the CA should react to the request from the PMA chair. -Anders: Probably, it is important that you circulate information, even that you are looking at the issue etc. Information on status is more important than actual fixing of the problem. -Pavel: The info was set to the list. An we never defined that we have all to be subscribed to the list and to read it regularly - it was an info, not an incidence channel. -Jim: What OSF needed was a coordinated IGTF reaction - that is more useful than a response for particular PMAs. -Anders: If you have one PMA with no response, can you exclude it from the distribution? -David: I can't do that, I can't modify another PMA's release, and it would me rather immoral to exclude the whole PMA. <...missed...> TAG PMA was the slowest due to response from the CAs. On the other side, most software packages permit bulk downloading of certificates, so I could check for vulnerability. I even reverse-engineered PKIRIS js site. So I was able to bypass some slowly-responding CAs. -Jens: So, what went wrong? What should we do for further incidents? ... -Ursula & Jens: We need an incidence response team that can assess the severity of the problem and serve as the incidence information source. -Mike: due to the events following the "staccatto incident" somebody created a social networking that started the incidence-response team. Which we never needed up to now, where the last person on that committee was the one who responded. If you don't check it, these people go away. -Jens: There are security challenges on the grid, should be brig something like that in here? So: -Jens: We need a team to do the assessment ("The Early Incident Response Team), and a channel to send advisory. And there is procedure: the CA should acknowledge the reception of the message. Only then start to investigate - like a ticketing system. -Christos: I would like to use another mailing address, not the public one, so that it is more obvious. -Jens: And we should say what kind of response is expected from the CA. -Roberto: But how will the e-mail be authenticated? -David: The e-mails should be signed, either S-MIME or PGP. -Jens: All important announcements should be signed. -Milan: But not encrypted! -Mike: -David: Replies should be encrypted, as appropriate considering the content. -Jens: So we should protect the mailing list archives. Dave: So, if this is a high risk, like this one, what would you expect? -David: Personally, I would expect it in 36 hours, to cover a day of travel or something. So if you go away for more, you have to set-up a way to read mail. -Reimer: We define the CAs in the policy as a best-effort thing, and public holidays in a country should be taken into account. This is a requirement problem. -Dave: It is probably reasonable to only account for business days. -Christos: But this is what Harvey did: he replied, saying he will do it on Friday. David: And we need to continue to react to the updates to the initial queries in the same manner, on the next business day. Roberto: Imagining the machinery is in place. And there is a catastrophic bug, and we revoke 2000 certificates. And EGEE takes 2 days to realize the problem. This means they will have the certificates revoked before they realize the problem. Jim: What we did in OGF was that we made a general announcement with a link to a web page where the info was updated. So with that we say that we might be silent for a while, but here is all the latest info that we have. Reimer: However, most CAs are either under a NREN or related to a NREN, and have Cert as source of sec info. Ursula: But the problem is return info, how to know what happened at the CA. Jim: Also, when somebody has a server broken, we need to know, not just when the certificate needs to be reissued. David made a recapitulation, which I missed. ... and send e-mails to the published CA e-mails in the meta-data, but tagged as PMA Incident, and will contain the expected response time and form. The risk assessment team can also define a timeline in which the problem should be fixed. At the same time the relaying parties can inform their users and ... If the fist deadline passes without an acknowledgement and the resolution deadline passes without at least a request for prolongement, the CA in question should be suspended from the PMA release, which would also require a new release. There is a delay (2-4 days) before the release is taken up by relying parties. Taking up a new release: OSG in 4 hours, EGEE in 4 days, DEISA slowest. Jens: However, perpahs we should have the "Truly Emergency Get Jens Out of Bed number": a TEGOOB number. ... So: We should have a secret contact list where people can provide emergency contact phone numbers etc. Also, a CA should be able to request an extension delay from the emergency incident reponse team. Jim: I object: the number to handle emergencies should be published inside your CP/CPS. If there is no response in until the deadline, the process, the suspension process should start immediately and the new release is published to the IGTF mailinglist, at anytime, not just the prefeered Monday or Tuesday. -Milan: The process of suspension should include TACAR repository, so that the IGTF mark is removed. -Jens: Should TACAR be on the incident response list? -Milan: No. Dave: There is perception outside IGTF that it is no way to get out once you're in. So it is important that we create ways and methods to do that, but not do that lightly in practice. Suspension should not happen lightly, if at all. -Mike: We don't have a way to do that nicely, and this machinery could fall on us. Willy: I propose 2 steps: waiting for a certain number of replies, who can decide. If the nuber of answers is not high enough, nothing happens. Their decision has to be published to the PMA mailing-list, so the members can control what happens or overrule. David: In non-response a small subset would immediate assess reaction, and in 24 hours propose a decision that has to be put in action . --- should return to this --- We need a couple of functions: -core team: suspension sub-comitee -incident response team -ROBAB for distributions -> trusted committer -> builders, sharing keys?? -chair position David: I will send out an e-mail for you to consider if you are ready to be on one of these teams. Anders is a trusted committer, but can't build the distribution. Perhaps it would be wise that Mike and Yoshio could be builders too, so that any one PMA could build the distribution. Discussion on the implications of sharing the key. Teams: Jens: Risk assessment team should rotate. -Jim: And be IGTF-based. So first candidates: Jim, Jens, Willy, David David will set-up the mailing-list. The team will organize the archives for the mailing list. Core team - Suspension gate-keeper sub-comitee: Dave, Ursula, Jan Finally, we need the holder of a few secrets: the domain-name management and the mailing lists (eugridpma.org, info, eu). Anders will keep all the secrets. --- Tuesday ---- Reimer Karlsen-Masur: Short-lived credentials for portals Grid users need accredited certificates, but for them it represents a lot of hassle. We see the solution as community/robot certificates authenticating through portals and gateways to resources, so that the user is working with a community cert, identifying the portal. Grid-portals provide user-friendly GUI for authentication as a webapp, eclipse plugin, clientAuth, Shibbed ... Grid-gateways are similar, but ... DFN-PKI SLCS credential service implementation of the SCLS-CA. accreditation planned before end of 2008. It has low user interaction semi automatic portal driven subscription with automatic MyProxy Credential Store interaction. It has Shib IdP in all organisations. Portals and gateways should be shib providers too, but it is not necessary. - just helps a single sign-on experience. A JavaWebStart app and MyProxy credential store. Current grid portals are not ready for this. Architecture: the CredentialRetriever can retrieve a short lived credential, but not much more. Plans for uploading a primary proxy to credential store, like myProxyInit, and providing feedback to the portal. For the user, the difference is, that the user does not manage the certificates in any way, maybe even never sees a private key, since it is a short-lived certificate, that is only used to build a proper chain, without using the key again. If you need another one, you build a new one with a ney key. In the whole, there are 88 steps in the whole procedure ... not really simple, although the user only does the shib login and acknowledgement the request of SLCS and the upload of the MyProxyCS by clicking "OK". -Jensen: I am sure NGS has a much simpler architecture, but in a different federation with almost no attributes. -Pavel: But if the private key is retrieved on a public machine, it can be left there and ... -Yes, we can only put it in memory and that is much safer. -Jim: But if it is created on the portal, it is not much more different than as if you create your credential in a SSH account on a remote machine, after all, it is a secure session you created. David Groep: EGEE TCG ortal WG ------------------------------ EGEE technical coordination group made a group of compliant policies for portals. A wide range of aims - from how to get the cert to the use of particular software / input data, how to inform users on the use of certificates, accounting / logging etc. A very interesting mandate, however the working group only met once (May 2nd 2007!) Bio-informatics today use free portals with anonymous access, where they do 5000 analysis per day on avg, with no auth, autz, for free. Therefore, there are portals, and portal users, in some national projects. However, their datasets are increasing, and they want to use grid storage. And they want it all in the form of WS. And they want to create anonymous workflows. Selling PKI to them was bad. They don't require anonymity, but even typing in an e-mail is considered a burden, since in bio-informatics, free portals are prevalent. So, can we look for a way to provide grid resources for this kind of biologists? (Considering hight PR value involved and related groups.) Proposed 5 levels of ID: 1. anonymous (nothing) 2. pseudonymous (e-mail provided, but not checked) 3. id'd users without certificates (e-mail checked) 4. id'd users with grid certificates but allow the use of resource without the traditional proxies etc. 5. id'd users with certificates and full blown short time proxies, so users used to the usual way of doing things. That's how far we got in the group. Now for personal work by David, no formal approval, but it was circulated to the group and the joint security policy group. Classification of use cases by jobs: - "Web Rendering": jobs submitted via CGI programs that use the grid to render the output, so the results are available for everyone, and the user does not provide any input data. * robot certificates, no id of end user, portal has a list of IPs. grid use must be stateless and rate-limited - "Parameter Sweeping": jobs take parameters and are available to the users that submitted tham. * user must provide pseudonymous e-mail. robot certificates or user's real credentials. Grid use rate limited and steless (data copied back to the portal.) - "Data Processing": jobs submitted to the grid, but executables from the portal * Portal may user robot or user certificates. Grid use rate-limited, output is stored on pre-agreed locations on the grid. - "Job Management Portals" full-blown jobs with executables by the user * User should be able to use the full set of credentials and tools. Hopefully, this kind of policies will appear and we will see the use of this kind of use in portals. But we can control the use of credentials in such systems. Many credentials are already used in portals in "creative" scenarios. Dave: I think it is very good that IGTF can cover this and takes interest in the subject. -David: But mostly it is national grid projects that are using portals in some way. It may well be good to find any additional use cases. And then there is the question of authorization. -Dave: Yes, the authorization group is considering moving much more towards this new world of national grids and portal systems. -David: As we move to NGIs we hope to get much more contributions from and Reimer: If this is put into a more formal way, it is not going in the CP/CPS, but where, to the relying parties. -David: I think it can still be discussed on this list, but I might give over the management of this discussion to the Joint Security Policy Group (JSPG). Jens'es Robot Saop Box ---------------------- Dimensions ---------- What goes in the robot from CA's perspecitve: - Key Generaton - Key Storage - Cert Usage Out: - Cert Usage - "I am a Robot" - Authority chain. LOA, risks - usually signed by a special CA cert or smth, it is slightly complicated since it is not a normal RA-way to get a cert, basically anyone can apply for the robot cert. Basically , there is verified and non-verified info, the latter is asserted by the user. So the question is how to make things verified and what is the risks of non-verified information. This is true both for the normal and for the robot certificates. In particular here, we are thinking of the fact that the robot cert lives on an e-token. So the CA has to verify the token. This breaks the normal workflow: the RA needs to verify that the user actually uses the key to get the request etc. But on the other hand, we get a different level of verification, which permits some relying parties to do different things. Somebody at XXX found out the e-Token now somehow works with the OpenSC XX?. Key storage - what is the level of the assert stored on the token, FIPS certification level, or not certified at all but in the process of certification, or not even that. Actually, we may do care how the key is stored, it may depend on the key usage. The other dimension is the Robot Naming questioning. Actually, the naming currently is the ND - robots name themselves (Robot:) and name their owners. "Warm and fuzzy robots" - log files show it is a robot and whose robot it was. Authorization can work on DN for robots. Some sort of naming for robots therefore seems to be worthwhile. -Alessandro: If you are setting up a DN for robots, and I am running SLCS, would the robot be allowed to ask for a SLCS cert? -Yes, but: it depends on how their activation data is stored. A robot cert can in some cases work in the same way as a user. -Alessandro: The use case in SLCS would be to use it to , but that is not allowed. Could that be allowed for a robot, it would help a lot. How to communicate the information: you need a naming scheme, either a hierarchical scheme or current hacky versions. You can have OIDs, but the middleware has to parse OIDs (sticks and carrots). OR you can have another external source, such as an LDAP. In this case the CA makes an assertion about the robot certificate, but not in the cert, in an external source. Proposals: How tightly do we need to manage usage? For (1) VOMS, portals, we can say the robot is an object-signing thing. The problem is, that if the robot says it is depending on a person, you don't know who that is and, worse, you can't pass it on the next manager. So perhaps we need to move towards a role-owned certificate, as opposed to our current policy. This is different from what we have been doing. (Robot is an application certificate, not permitted to behave as a server). In this case the access to the private key can be shared. But how do you do identification? How do you identify the name? However, we still need to tie the cert to a single person, we need to know who has it a any time, I want to pin down the ownership. But since project go on longer than people's jobs, the ownership can be passed on. (In the national grid service we had some turnover, someone responsible for signing, i.e., moved on and we had to change all those certificates.) What kind of robot certificates do we want you have, what kind of things do you want to provide? The bottom line, however, is that the name in the robot cert would not be a personal name, but a project name, an abstract entity. But at any point we need to know who the actual owner is, and when the ownership changes. Maybe that is too much for all robots, perhaps only object-signing certificates should be of the role-type. Milan: 2 things: (1) the name of the responsible person in the cert - i don't think we need to do that. (2) sharing the private key - I don't think we need that. We could do exactly what we do with the host cert. -Jens: The new person has to take over the responsibility of the host certificate. If they consider the fact that the previous admin had access to the key a problem, they can consider this as a compromise and change the key. -Mike: Some people have a tihghtly maintained backend, but for example, we do not and we do something like that. So what can we take from our own experience and put back into that? Have you thought about it in that way - or you disagree? -Alessandro: I would think of the robot cert in the particular way of the use of the robot cert. -Jens: That is roughly what I am thinking, for example a VOMS - there a certain types of services we need to worrly about on a different level because you might just take down the grid. The same is true of SLCS. There are services that just have the key written in them all over the country. We have magical certificates that can do stuff automatically. Maybe we should think about considering VOMS and similira certificates especially. <...> Some people enter a personal e-mail as a subjectAlternativeMail in the robot certificates. <...> -Mike: Do you want a schema for information about the robot, and the CA would be responsible for maintaining the attributes and providing ... -Jens: Yes, and LDAP is just and example. It has to be accessible automatically and by the people. I just mentioned the case of host certificates, where we don't do that, we just provide the contact e-mail. (-Milan: No, we don't.) -Anders: But don't we do robots to avoid carrying the certificates around? -Jens: Yes, but there are exceptions, such as VOMS etc., where you have to trust also the public key. -Anders: But if you talk about the cert that is not tied directly to a person, then you don't have to change the database all the time. You want something person-neutral. -Jens: I can't expect a new maintainer to request a new certificate, since it would invalidate all the signatures from the past. -Milan: But, no, why, the signatures made in the past? -True, but you still to have sign all the versions of the software and distribute the signature. -Mike: So does that imply very broad naming rules, so you could give them DNS or host names. -Jens: I don't want to do that, since then you put them in the host naming space. I want them to be in the robot naming spaces. I have to set up my naming spaces and explain what that means. -Alessandro: But if we want to keep the info in the CA, we need to understand all the particular use-cases. -Jens: We already do. But we do need continuity in projects and not everything to depend on a single person. -Dave: But you can use a project name, if you know the thing will have the only lifetime as the project. But if you have something like a VOMS, you have to deal with the institutes that run the services. Well, they change names too. Milan Sova: 1 statement certification policies ---------------------------------------------- We want to be able to mark certificates with tags like "private key is on e-token", "this is a robot" etc. We don't want to put all these cases in policies with clever methods for tagging inside subject or other places that are not appropriate. So the idea is, that we write the policy in the XXX format, but making just one statement, i.e. on the way the private key is stored on an e-Token. This policy, with one statement, has its own OID. And then we can insert the AOIDs in the cert to convey the info to the relying party. So you can end-up with 52 (Jens: 6-7) OIDs in a certificate. -Jens: In my mind there are some 6 dimensions: key storage, robot states, identity vetting ... David: I think we agreed earlier that we would actually carve-out OID space for this, so that we can have a sequence of statements where the number does not reflect any relationship with the previous statement, but the space is hierarchical as to the space of the policy. Anders: How do we know that this is the case? -Jens: CA must be able to assert this. So for example, in the case of the e-Token, the RA has to witness the key generation from the token. This is the question of what information is verified and how much we want it to verify. Jan: So the details should be in the CP/CPS? -Milan: Those are policies, the details belong in the CPS, of course. --- launch --- One-statemet cert policies: David presenting proposals by Milan Sova. Currently in the form of full documents with "No stipulation." in most sections. Considering several examples: ..., Softwaer Agent Certificate Policies Draft v 0.2 (Known as Robots) or "Policy on holding private keys protected on a secure hardware token. Due to transfer from XXXX to XXXX RFC, this has now become a 4 statement security policy. -Jens: This is why I wanted to call them policy components. Which is not ideal either, as we discussed it. A policy cannot do without an overview, and identifier and a policy administration organisation. -Milan: 1.3 - Person determining the suitability should probably be there to, and be generic for all these policies. : Intention of the e-Token requirement description is to allow the case of the token such as Alladin were the non-certified version is actually identical, but has bigger keys. --- tea --- David Kelsey: Authorization (AuthZ Operations Policy) WG and discussion ----------------------------------------------------------------------- Discussion on mandate: first mandate to set up a list of all authz tools for the grid environment available. It would be helpful to discern advantages on SAML assertions vs Attribute certificates vs attributes directly included in proxy certificates. Some responses were, that essentially policy implications of VOs and VO service providers are the same regardless of their attribute-assertion technology and signing. Also, staying implementation-independent on VOMS was underlined, if we start working on the VOMS. If we look at the auths profile, at the start, it was short and simple, but in time, it got complicated and full of technical details. Jens: It seems to us that auths is easy, but only because this group has been doing it for many ways. Dave: We should have a look at the relationship between auths and authz. Alessandro: Perhaps we should discuss the attributes directly. Christos: Or we should start simply discussing what we actually have, and from a concrete situation try to generalize. Dave: It seems we should start from something concrete, yes. Alessandro: <...> David: But that is all on the middleware side, it has nothing to do how we actually operate it. Realistically, if we come with something now and obsolete technology, the turnover will be around 4 years. Dave: Let us at least make it work with what we have today. Jens: Beside VOMS, we also have shib (and use it at the grid). There are people using some attributes. But I agree we should start at the VOMS. Dave: Today we need to specify Policy models and specify and Attribute Authority Service Profile based on VOMS. Then, the other part is the VO procedures, since often VO managers are not actually running . Just addressing the problem space is something - JSPG is working on 2 documents, a VO Registration Policy and a VO Membership Management Policy. Milan: The VO in this case seems smth. that should work for a service provider. Christos: It includes the users. Alessandro & Dave: It is kind of IdP, they are signing the attributes, rights to join an organisation. Milan: So the VO is done via attributes. What does the VO registration policy means? David: An IdP joining the federation. Milan: Where that is the grid. Is it not then local to the VO? Dave: Because we delegate it out, as an IdP. David: They are actually much more tightly controlled. Milan: And the control is coming from the relying parties. David: The IdP should have quality members in it, and that is where this policy comes from. David: <...> have the administrative rights to say who can join and which rights they have. Alessandro: The VOMS server is in charge that whatever is happening on the VOMS server actually makes sense. Dave: And we must say hot this must migrate to IdPs and federations etc. Dave: I think we have general agreement to this two problem spaces. As to the scaling issue, i.e. EGEE, we don't even know what kind of order we have. The reason is that we have a big spectrum of what type VO's there are - very big and long-lived projects with well defined scopes, then international, but perhaps within a continent, and then VO's that are regional or local to the country or less. ~200 VOs, no idea on the number of VOMSses - need to quantify that - 10 to 30. But only ~100 VOs we actually know in detail. We have to accredit all the VOMS servers - the number is similar to the number of CAs, while there are many more VOs, beyond this. If we look at the EU situation, NGIs that are discussing and creating EGI are 38. Accreditation - we have a number of options.* use existing IGTF PMAs; * form new AuthZ PMAs; * large grids; * NGIs. My personal preferences is IGTF defining standards, others do accreditation with IGTF members (needing feedback into standards). We need something for coordination, something large and global, large grids or EGI, to accredit large global VOs and run AA services for them. My personal preference is also, that every VO should have its home grid - my start locally and become a national or bigger VO, but many with have a natural home. If the VO wants to go along, it can show its IGTF authorization etc. Alessandro: LHC is a bit of an exception here. Christos: We can help by seeing who is running a VO service and how we can get them accredited. Dave: Bootstrap: prepare draft profiles, (AA and VO), accredit a small number of global VOs, and improve them on feedback. David: It is important to <...>. Christos: We run local VOs that fit nicely in the EGEE/EGI schema. Dave: Just as we don't want everyone to have their own CA, we don't want the to run attribute authorities in general. Jan: But this is discussed as something NGIs might do. AC Validation - there is a document from OSG: Attribute Certificate Validation in OSG. Mike: It shows the problems, i.e. with push-pull mechanisms. It shows the problems with validation that we need to resolve, at least in the future. A bit of what they need from the data, how the trust works etc. We need to focus on what they are thinking, not what they are doing today (Garzoli, Jim Basney etc.). How they think on moving the services that they have along: how to supply the attributes and do the organisation too. Milan: But who is doing the attribute validation? Is it something like going through the attribute validation etc. -Dave: Something like that. Mike: But they don't discuss this per se. The architecture is evolving inside-out. Now their prefer GUMS, but the EU model has provided them with the VOMS-based proxy certificates with attributes inside, and they want to make them useful. But they have issues with local services that pull down the db from VOMS, but they have a man-in-the-middle situation there, and there is the question of liability - lots of data, some looking like PII (personally identifiable information - it is contextual) either from EU or from USA perspective, and the question of ownership of data - how do we deal with an attribute management system combined with PII and data ownership problems - really nasty. Dave: Meetings and plans. To start we probably need a small team and f2f meetings. That would require a workshop, probably in the fall, sept.-oct. (EGEE 08 Istanbul) Should we do it in the PMA in Lisbon? Or a special meeting? OGF in Singapore? Points of departure: what keys to be used, validation things, proper roots of trust etc. We know what is happening in the middleware - just the DN and VOMS server are still in there. And I think that requires a technical discussion, which is most effective f2f. Mike: Has any of these ideas penetrated to the various relying parties. Dave: I presented it to the LCG. We should use the opportunity at EGLA. Mike: What scared me was that they were saying that you can trust this since it uses attributes signed by a certificate signed by IGTF. David: Going back to Charter ---------------------------- We should probably be changed, because it says we will NOT define and enforce access policies and practices (authorization). By general consensus - deleted the phrase. Also, the specification on trust relations that are subject to PMA has been omitted by general consensus. David: SLCS Revocation: TAGPMA change and update time plan ---------------------------------------------------------- In Auckland - all SLCS certification authorities MUST issue CRLs. But if all your certificates are shorter than 24 hours, a CRL can live for 365.5 days in the future. However, if a certificate longer than 24 hours is compromised, you MUST issue a CRL on the web page for the lifetime of the certificate. Milan: Does that mean the change of the certificate profile. -Dave: Yes, that would mean the CRL point would get included in the distribution. -Milan: But the certificate profile? -Dave: Yes, if the certificates live more than 24 hours, you ought to include the revocation point, but I am not sure that the profile includes that. -Mike: We should discuss this, I am not sure this is what the document says. Jan: But due to the version number of the CRL, you need to issue a new long-lived one if you once issue a short-lived one. Milan: Yes. Also, because you can rely on the dates. Mike: The profile is not quite in sync with that yet, but we will get there eventually. Alessandro: Can be implemented quickly. Jan: But will pose problems to users who do not expect CRL downloading should be expected. Mike: But there is another problem: we changed the FIPS 140 level requirement from 3 to 2. It turned out the level 3 operation with requirements with personnel controls on identifiable operators are counterproductive, although the security products bring the capabilities for free. There was a considerable amount of bickering about this. <... missed a part of discussion on details of the required non FIPS 140 level 3 procedures to still id the responsible operator ...> Mike: This profile is now as good as the others, and as usable. On the subject of MICS/SLCS two-factor authentication ----------------------------------------------------- The problem of the password for MICS and SLCS - all sites are required to use secure channel for auth for this reason - sniff once use everywhere. Milan: But in MICS and SLCS, the sites are in position to enforce the use a good password. <... missed David's point ... but it seems he insist on a two-factor credential approach since it is hard to snoop both of them ... i.e. the date of birth. Since this is a useful for example for resetting password, for example. > Milan: I think it is not convenient to use the same long and complicated password on other machines. This should not be a problem. David: For example - if you request one of the lesser-used attributes in MICS. Milan: I do not want to share any additional secrets from the user - that would be additional authentication, and I don't want to do authentication anymore. David: What if the IdPs can provide more attributes, even different ones, and ... -xxx: But the problem should be solved by IdPs: they can be forced to implement a two factor authentication system. Christos: There is also a way of second authentication where users are notified of actions happening on your behalf, such as an e-mail. Alessandro: That is what is used in the VOMS. Jan: But is that an IdP or Service Provider problem? Dave: The problem is that the IdP can not show the level of assurance. Milan: In shib2 you should be able to, even to require different auth methods. David: In the federations I haven't seen these concepts defined on the policy level. Milan: Because this does not make sense, this is a problem between IdPs and SPs. David: Issue closed. Milan: For the moment. Yoshia: CAOPS ------------- New co-chair: Yoshio Tanaka! Transiton to the Security Area as a Standards Group. Next week OGF 23: dedicated. Results: -better dissemination of info to use community, recommendation track documents and publishing standards -different oversight: standards fucntion (charter revision) -long workshops and meetings planned Documents - (see presentation) Under consideration by LoA-RG: LoA definitions versus LoA requirements (Mike Jones); risk analysis in relation to LoA and use case gathering in and e-Science context (Mike Helm) Joint CAOPS-IGTF Workshops (OGTF 22 Boston Feb 28th) <...> David: Could you discuss one-statement policies with the software implementers there? (Meeting is not well-attended.) Christos: 200 people expected! But we have only one week, so whom to contact and what to push on the agenda. Alessandro: But the agenda is not decided. David: OGF has been a sponsored-spoiled organisation, via marketing departments of the big companies. Participants in OGF are looking for easily reachable open-source solution, while the industry looks first at commercial and then in-house solutions. So it is obvious that the marketing departments withdrawn their support and OGF is looking for financing - as a standard organisation costs money. So the attendance fees are very high, since they cover the organisation also. OGF is going through organisation, giving more value to attendance and being less addicted to sponsor money. --- direct to dinner --- --- 28th May --- KFKI RMKI CA report & self-assessment ------------------------------------- In 2004, community service was needed. The NREN was planning a CA, but no real roadmap and new improvements, so we decided to set up a CA, since 90 % of users were at the institute. In Brussels, Sept. 2004 the CP/CPS was presented, but the PMA community demanded agreement to preemt a 2nd CA institution, rightly. Answer: the Hungarian grid community will endorse the effort until the NIIF CA is operational with an RA at the KFKI campus. Agreement reached, accredited, production started in January 2005. At the time, we expected the CA to run one year, not more. Technicaly, a Debian/OpenCA platform, 224 issued, 47 valid user certificates. Just one CRL out of 120 overdue (but never invalid). Present status: NIIF RA progress - deployed and testaed a reliable RA secure admin interface with web interface in development, IdP for NIIF AAI Federation in deployment (for user preauth) - but not for actual grid identification, RA contact in preparation. This is proceeding very well and should be completed until September, 2008 would be really nice. Future plans: as soon as we have the RA, the old CA will close down. Technically, the CA will probably stay up to serve internal services, such as mail etc. Leaving the club... Formal procedure, as per David, we will be just dropped from the distribution. Self-assessment (nasty stuff) - What we learned: more is less - if not specified striclty in the CP/CPS, things can present problems later (such as host/dns or not in DN). Also, it would be much easier having all the operational documents before production. An operational review helps a lot, recommended way should be to do it even before production. Separation of grid name-space from everything else is recommended - to avoid nasty problems later. It should be recorded at what version of profile (minimum requirements) a CA has been accredited. It would also be easier if the audit guidelines corresponded to the versions of profiles, and have different versions for each AP (authenitcation profile). David: Thank you for the openness - perhaps you should join us in the AuthZ work? It seems to me that we all meet the situation when we have to deal with "creative exceptions". The profile S853 is interesting, since it represents a documentable auditable process for execution exceptions and specifying who is responsible for writing off the risk. -Mike: S853 actually represents a kind of defence, a way to document what actually happened as a kind of defence. -Milan: In the army, we had the concept of "exceptional event" - in this case the people involved had to document every detail and all they know about the event. Should we deal with this in the similar way? Majid Arabgol: Accreditation of new CAs: IRAN-GRID -------------------------------------------------- Accepted unanimously & immediately. --- coffee --- David: Continuous Audit Process: selection of new CAs to go through the process ------------------------------------------------------------------------------- On 1.5.2. Contact points - as defined previously in discussion, this is the way to reach the CA if there is a problem. I.e. in Shibboleth federation, each IdP has to define 3 contact points for different things, which can be the same person only for very small organisations. Again, I don't want to write a full CP/CPS that works for everybody, but a text with the most common bits to prevent the most common mistakes. A common mistake: the CA publishes an example, which does not tell what the host certificates look like, what the signing policy looks like, what part of the DN is fixed, is there and OU in it etc. Milan: Do you plan to have some examples in the template? For example, giving the example of DC-based naming. -Jens: Maybe we should say that we recommend to use the DC-based naming and show what it looks like, and say: unless you have really good reasons not to, this is how you should structure your names. -Anders: Also, if we can give examples, we can say "Here is a CP/CPS conforming to the given profile, with the exception of these bits that you have to change." -Jens: Yes, but I have to think of some kind of markup, better than the colour scheme. This what I have is practical, but the Word is not really the right way to do it. I was thinking of going back to an XML version and do it through XSLT. -Anders: That seems like the right approach, and then people can actually take the document and produce their document and we can see the differences. -David: There is another danger - if the CA takes too much of the standard bits, can we be sure the operational details? -Jens: That is why we need the operational reviews. On the other hand, at least we don't let you get away with no stipulation - of coure we can't verify it without going to visit the CA. -Milan: I don't agree completely - there is the CP, that says what you do, then there is the CPS, that should describe how you do it. David: It should be ok to reference a private operational security document. Christos: Are the same things going to apply to MICS and IdPs? Because if yes, I want to have every IdP to put in the exact same information. -Mike: Ups, we had a long discussion exactly on that. We found we were really out of scope on that and decided to define the clear separation between the identification service and what we do. So the text now says things like "An IdP SHOULD do this or SHOULD provide this information to the CA operator." The burden of providing that material would be colossal, and yet they do a lot of that material themselves as part of the federation operation and documentation. There are probably other similar processes, audits and approval procedures for new members, this seems to be the normal behaviour for these federations. So we should provide and interface for the work that is already performed. -Christos: My purpose is to decide if we go further with this document. I want to have the same level everywhere, so if I go further with such a work, I have to assure that it is done in the same minimal way everywhere. Else I might to consider moving the profile from Classic to SLCS or MICS or something. -Jens: There are more classic profile users, so we are aiming for those first. -Christos: And at the same time we make classic approval very difficult and SLCS and MICS much easier. -Milan: I think the aim of this document is not to define rules, but to make the life of applicant CAs a bit easier. So let us finish this one and let Jens work on another profile later. :-) -Christos: Yes, but if you put a wording here, then this requires my intention, this is more than minimal requirements. -Jan: This is more like best practices? -Christos: So this is a way of defining good practices? -David: No, this is just an example, you can write your own text with different best practices, but you will have more work and so will the reviewers. -Jim: Would it be helpful if every MUST and SHOULD should reference the relevant minimal requirements MUST or SHOULD, I think we are in agreement that there should be no MUSTs and SHOULDs that have no such reference. -Christos: This is then what we expect to see in a document. And in this point between the profile is beginning to really widen more. -Jens: At this level I am not concerned by SLCS and MICS. -Hungary: You can even put the usual question or guideline of the reviewers at the margin of the document to see what to expect. -Jens: That would work if we go with what Jim proposed, so we actually put in the references to the profiles. -Jim: One of our goals in the recent re-editing of MICS at the TAGMPA was to make it as close to the actual Classical profile as possible, that is what we should aim for. Jens: I wanted to do first a version that references correctly the Classic and then add the notes, then bring in bits and peaces from the Cp/CPS documents that were referenced as particularly good ones. -- lunch -- Jens: Mike suggested we need to start writing from scratch, due to copyright issues - usually owned by the employer. Anders has volunteered to be the first person to implement the template policy. We also nned to tie in the TAGPMA annotated CP/CPS (the red in draft version) - subject to copyrigh agreement. The document need to refer to the minimal requirements (authoritative, but it was suggested the template could replace the profile), the relevant AP profile(s). Technicaly, it should be written in an XML source file (Mike: Docbook?) to produce via XSLT translation LaTeX, Word, Docbook, HTML formats. Or in XML with a schema to output via XSLT. Perhaps a web service should be provided. (Jens: details should be figured out by a subwork-workinggroup :-) ...) Back to the document. There is a group of eager volunteers that are ready to work on this. So perhaps we should just slice up the document and delegate. Christos: What if we propose a document written for an imaginary CA so that it would be easier to copy. -Jens: That was proposed, but no work has been done. -Jim: But in a combined CP/CPS, I expect direct statements, of the type my CA is this tall and this high above sea level, not musts and shoulds. -Milan: However, I would strongly prefer separate documents, a policy and the CPS. David: If we go for separate documents, not many people will do that. And if we go for a faithful translation from minimal requirements to a direct CP, nobody will use it. (It might show holes in our requirements, though.) Milan: I think we should separate the documents, so that the CP template would be used as an OID reference, and new CAs only need to write the CPS and refer to it. -Jens: Can we just proceed with the document and see how it pins out, see what is appropriate and what not. -Milan: We should probably firs decide if this is a combined document or note. -Jens: I would like to write a CP/CPS combined, with markup to show what things need to be changed, in a complete 3647 implementation. -Milan: I think this is a bad think, and we should get rid of it somehow. It is not standard, the intention of the RFC was, to have the same template to write both documents. The template is intentionally the same, so that the CPS can refer to the CP more easily. -Christos: In theory I agree with you, but I have been reading a lot of these documents - and I think this would be too difficult for a newcomer, since it is difficult for me to grasp now. -Milan: But it is easier: you have a questionnaire as a CP, and the CPS is the answers. -Christos: You should try it perhaps. -Milan: I have it this way from the start. . Mike: I must say that this would be interesting for us, if I tried to recast our CP/CPS, but in this case I could use the policy, as I have a number of other policies that influence what we do, and it would be much easier than writing an independent CP/CPS document just for that. Milan: If someone is planning to change the format, they should really consider splitting up the document. -Jens: But joined forms should be allowed. Willy: Another question, about the nice one-statement profiles. I know, it is nice to refer to them from certificates, but is there any provision to mark in a CP/CPS that it includes a provision of a one-statement profile. Mike: I think the working comitee should consider this. Jens: Originally I imagined those to become components that you can merge to create a full document. -Willy: But I need a complete CP/CPS still. Could I use this other work and show it clearly in the CP/CPS. Szabolcs: It is easy to do with the split format. We could make a CP statement as a host for plugging-in the one-statement templates. Jens: Yes, the idea is to handle as much as possible to the IGTF and make it sort of plug-and-play. In this way we must maintain only one set of documents instead of revising the documents from the different CAs. Jens: This certainly is a part of the same work. However, it is important when we get to the new CA candidates, so that they don't repeat the same mistakes again. Milan: What about the "How-to-join-page". David: It is there, but slightly outdated. Jens: Obvious candidates would be the ones with the NATO PKI project. David: They should be instructed to get first in contact with the PMA and get a mentor. Jens: But getting people at the point of expression of interest. And people revising and updating on the new version. Jens: But what kind of process can we use to continue. Videoconferencing? Milan: But what was the decision? Jens: We will try for a CP template. Milan: In this case I volunteer for reviewing the stuff. Jens: But if we need to keep some more CPS like stuff in, would you object? Milan: Not really. .