Tony's notes for Friday, May 27th, 2005 4th EUGridPMA Meeting, Tallinn, Estonia -------------- Meeting started 9:30am DG: discuss next meeting location and date. End of September in Posnom(sp) Poland Jan 2006 in Vienna DG: OCSP status Any one running at least an experimental? two raised their hands MS: Entrust does not have service DG: Openssl can do this as a service MS: Any load testing? Group: seems reasonable TG: problem could be created by have to run a 7/24 service: cost staffing MS: The relying party should be prepared for outages (MS and Ian exchange) The "Spanish guys" are going to get in the business, but I disagree with the model of a global service This could be a good first phase deployment, then we could role out a high quality service. How do run an openSSL ocsp? DG: it is a trivial implementation. Could you send us the link and instructions? I think this is a good idea to try Ian: I don't want to run the service, I want someone else to run it. MS: we can do this as an experimental service. I would like to see a significant number of us running this to test out the system. Cristos: has anyone looked at a DNS model MS: some issues, we should set up the base system. We need to test and report to relying parties TG: What does it mean to test? we have a service up and am willing to work on testing. This should be folded into the paper being written in the GGF Anders: garbled... Where should the info be, in the certs or the rpms? DG: It must be in the certs. It may be in the rpms ??: So when you start a production service you must put it in the cert DG: yes DG: Maybe we should use certicert. Lauri: If you are running an experimental service do you put it in the cert. MS: I am going to put it in the policy as experimental and I will put it in the cert. The user should read the policy not just to use the OCSP service. The policy is that it is experimental and may not always work. DG: I will send out the link to the software. Anything else? ??: should the OCSP do we need to secured? MS: yes, the signing key should be protected. This will only work with online ca signing. the OCSP can not check it self as valid, so the signing cert should be short live. ??: Do we need a HSM? MS: yes, the private key could be stored on a USB hardware token would work. ??: Does that mean you have to reissue this key every day? MS: yes. some say this key is more important then the CA private key. How this is updated is a question. I would regenerate the keys every year like the other cert keys, maybe more often depending on our paranoia. DG: we have a couple of issues left which one do we want to start with ??: there are others issues we need to discuss... MS: A Robot cert was first seen when we had to deal with a conference mail server... ?? This was to support a mailing list. My question was: what is the different between a personal cert and a robot certs. We should not change people or host certificate. we need to have a policy for "this" private key should be allowed to be keep in a non encrypted form. This is a policy issue. TG: How do you identify this certificate as different from another host certificate Jens: I think this is a good approach: we list a number of classes of how private keys are managed. Tokens could be used to hold the private key. We need to look at how we can identify the cert as one of the robot class: attribute, DN DC: In a grid example this would show up in the grid map file... Ian: another example of how a robot would be needed. file management example. many: general discussion on how we can identify this. Should proxies be limited that are generated by a robot cert.. Cristos: I want to be able to identify what any certificate is. I want to be able to tell if I am dealing with a real person or a machine... Darcy: Should we have a policy OID for each class of certificate? This could be a profile. TG: we could use different CAs for each class like verisign does... Darcy: You can check the different OIDs MS: One minor point, we should put the class or profile in the cert - maybe the OID is not the right idea maybe to use a URL ??: putting a URL to work with the software. The URL points to something that changes how do you make a software determination? MS: the url is just a string (URI) Darcy: if it is a string we are looking at this this is not different for using OID. MS: what we should put in the cert Darcy: we can develop our own standard for our community only. MS: we can start with this and move it to a standard body when we understand it better. ??: what does the relying party look at, they are looking only at the DN right now? MS: The relying party will have to do something more then they are doing now. ??: do it the standard way not the grid way. We should not be limited by the current practices in the Grid. MS: this is getting detailed and we can not answer in this meeting. lets move it to special working group. -- more general debate -- DG: wg: Jens, Ian, MS --- coffee break ---- DG: last item I have on the agenda is group use of certificate. Is there anyway to detect this? Jens: I would like to discuss this, I can't tell if it has happened, but you could tell something from the usage logs... Cristos: I think it does happen and we must be strict in enforcing this. Ursala: Why are they doing it? Cristos: Because it is hard to get certificates. the usability is bad, so it is easier to share. We have developed a client that helps them MS: we think the use of the token will help the user and slow or stop the sharing problem. There was a usability study in the UK that pointed to the token as the promising technology for this. Christos: we are running a my proxy service for some user. they like the experience. DG: should we run a test that checks if CRLs are there and send mail with the error? Ian: we have to be careful with transitive errors and not spam a CA Jan: we have a tool that does this. Christos: we can do this, but having someone do this for us would be great. DG: Jan, was nominated to run the service... Many: we need to handle scheduled down times so we do not get spammed or blamed. DG: any other topics round table discussion? Christos: CA generated host keys Many: discussion how we can do this. are there anyone doing this? It is convenient for our users to have the CA generate this. Chistos: if there is not security issues I would like to do this. Sophie: we do this by sending it to the user with encrypted mail. christos: how do we generate the keys on the server and keep them from being stolen? many: is this any less secure then what we have now - the private key is unencrypted on the host anyway. Christos: Well there is the concern that the CA machine could be broken in and all the keys could be grabbed. DG: we should not allow any new host generated key pairs. A wg should look at this and give a recommendation to the group. DG: any other issues? Ian: there is some people redoing there end entity names, I want them to be careful because this may impact the VO managers software. DG: the last issue I have is that we have the IGTF charter doc done by GGF14 Tony will handle edits. We should also review the new minimum requirements formatted docÂ… TG: I think it is time we set up the secretary and security officer roles to help the chair. Many: good idea we should look at this. DG: in the mean time would someone help with the website or setting of the wiki? DC: I could help set up the wiki.