http://www.eugridpma.org/agenda/fullAgenda.php?ida=a054
Speakers are identified by their initials after their first appearance
IHEP CA did not have Key Usage set to critical
TERENA: NRENs-GRID workshop series; possible TACAR extensions
Not much to report. Tuning CP/CPS. Now using USB-based system. Approx 4000 certs issued, 1000 live.
Working on update for CP/CPS. Not quite ready. Updating agreement with WestGrid. Root CA set to expire April 2007. Forged new root certificate in January. Will last for 20 years. Transition over next few months, before March 31st. CA moving from NRC campus to Canarie offices.
New root certificate to be issued. 100 issued, 54 valid.
Root CA expires next summer. Some changes to CP/CPS, especially RA. Running experimental OCSP service. Around 500 issued certs.
SEE Grid 2 project starting. Effort to get countries in the region to establish their own PKIs. 700—800 issued certs.
Studying how to set up CA as part of EELA project.
Datagrid-FR CA is now finished. No news for GRID-FR
Patched OpenCA did not warn when first user cert expired. Mostly host certs issued, but more users expected next year.
Around 1750 issued, 900 valid. Nothing new.
Will switch off old CA in June. Trying to get rid of issuing host certs. Restarting OCSP work. Now has budget for HSM.
Now only issue certs on BalticGrid CA. Issued 87 certs: 31 user, 51 host. 9 RAs: 5 in Estonia, 2 in Latvia, 2 in Lithuania.
Change CA root next summer.
Increase in number of organisations to 20. Issued about 250 server certs. Not many user certs because of subject component ordering problem. Certs issued since end of December have correct ordering.
SwissSign working to get certification compliant with law for digital signatures. If they get accreditation they will have to change root hierarchy. Grid software will have less SwissSign certificates to include.
17 RAs, 6 more on the way. Issued 80 server certificates, 95 user certificates. Plans to move to online signing CA. Evaluating HSMs.
Running 2 different hardware solutions since start of SurfNet PKI. New version of RSA has split OCSP transponder from CA to “Verification Manager”. CA Root Cert expires April 2017 when TN retires.
400 Certs issued. Planning upgrade.
2000 certs issued.
Auditing all RAs. Audit includes visit from CAs. RAs get a chance to feed back.
Root expires in August. Thinking of moving to a hierarchy to establish a lower-assurance CA. Moving to a HSM.
Duplicates: can a hot-spare share host keys?
First renewals in March. Plans to move to HSM. Around 200 valid user/host certificates. A few more RAs. Tender for a HSM in progress.
860 certs, 268 valid. 21 RAs. Several roving RAs. New grid project that will be requiring many certificates starting soon.
(Presentation)
TG: It would be nice to move to, say, 2 year host certs. Especially for cluster managers installing 100 certs..
Software updated to RedHat Certificate Manager.
(Presentation)
Name form does not use ‘@’ in CN, e.g.: DC=es, DC=irisgrid, O=organization_string, CN=name.surname
TG: ordering in CP/CPS was not the same as in internal DN encoding.
DG: Need to check ASN.1 encoding. Should probably come back to this in policy discussion.
Teun Nijsson: Do Grid CAs issue CRLs only once per month?
DG: CAs must publish 7 days before next update field. Not valid for more than 30 days.
TN: Could this leave an out-of-date CA in the cache?
DG: RPs are not supposed to behave this way. Should update at least once per day.
TN: Are expired certs that are revoked kept in the CRL? Milan Sova: Not required for Grid authentication. Rafael Marco de Lucas: Needed if using certs for signing
WW: Does the individual CA operator have their own copy of the CA keypair? Do they take them out with them?
JM: They are left in the safe.
Christos Kanellopoulos: Are there plans for integrating Spanish CAs?
RMdL: Yes, in future.
CK: What is the general approach? We need consensus or policy for multiple CAs in big countries.
TG: 1000s of Universities coming on line so we’ll want to federate it.
RMdL: We’d prefer to keep both CAs in Spain for now. pkIRISGrid will be in charge of Spanish national Grid. For European projects users will have different needs. For how long, I don’t know.
CK: How do we resolve this? First-come, first-served?
DG: I try to do some research to see if the applicants are a good representative for the country.
TG: It should be a requirement that CAs are registered in TACAR.
Outcome: pkIRISGrid has been accredited.
Ian Neilson: Architecture of Grid CA in CERN is not going to scale to the number of certificates required. Plan to be replaced by CERN-IS CA.
(Presentation)
Will provide certs to non-CERN users using CERN services such as mailing list users. Not only for grid applications.
Web interface works with IE, Mozilla, etc. and also OpenSSL pasted request.
Users can request host certificate for any non-CERN host.
Validate CERN CA for Grid requirements. Define migration plan.
TG: What software?
EO: Windows 2003 Certification Service
TG: Does it issue only differential CRLs?
EO: There is an option to issue full CRLs
WW: External users will be able to get CERN certificates?
EO: Only users who don’t already have a grid certificate
WW: You have a virtual CA. Is the VM hosting environment online?
EO: The disk image is kept on a disk in a cupboard The root CA is offline. The issuing CA is online. It will use a HSM.
David Kelsey: What is the namespace?
EO: different from the old one.
EO: In short term they will be “classic” certificates
DG: Certs will be issued for mailing-list users?
EO: For users who do not have certs. If person is registered in CERN HR then we can issue a cert.
DK: What is the lifetime of the smart card? same as card expiry date?
EO: renewing is easy with smart cards so short expiry isn’t a real problem.
Jens Jensen: Are there standards for smart cards? Should we pick one?
TG: There are different FIPS-140 levels…
MS: We accept software with lower levels of assurance.
WW: tokens: FIPS-140-1 level 2
TN: level 3 very hard to reach
MS: We don’t put information in the cert that says if the key is on a token.
TG: If using a token-issuing station we can “guarantee” that the key is protected.
TN: Users don’t have secure keypads for smart cards…
TG: In windows, plug in token, leave the office with the token activated. We need policy for protecting tokens…
MS: Planned usage for the certs to be everything: authentication, signing, encryption.
EO: authentication and signing yes, but encryption to be defined. Don’t want to have people losing access to documents…. Not much demand for encryption from users.
MS: Do you plan to use seperate certs for authentication and signing?
EO: Yes, good idea.
Lunch
Some discussion on HSMs. How strict should the PMA be re: FIPS-140-2 level 3.
Reimer Karlsen-Masur: Considering HSM with level 2, but supports level 3 “mode”.
TG: level 3 is tamper-resistant. Covered in epoxy. Tamper-indicated.
TN: level 3 devices designed to be tamper-resistant. If you try to remove epoxy you will destroy chip. There is a white paper on well-funded attack.
TN: It is possible to use level 3 device operated in level 2 mode.
Should we drop the requirements to FIPS-140-2 level 2?
Action: To be discussed and circulated.
MS: If relying party cannot tell from certificate if it’s stored on token or not then we don’t have to care in minimum requirements. If we have a policy that marks the certificates that they cannot be exported from the hardware token.
TG: We should have some requirements for usage of token by users.
David O’Callaghan: This may also apply to software tokens in browsers.
DG: Internet Explorer is especially bad. Difficult to get it to protect software token.
DG: Is there a 1SCP for tokens?
MS: No. Working on issue of renewals. Would like to mark certificates issued on a token.
TN: disadvise making the policy field a critical extension.
http://www.terena.nl/news/fullstory.php?news_id=1509
GlobalSign have been contracted. Will probably start issuing certificates in April.
At a future meeting (September—October) MS will propose that this CA should be accepted by this body.
Ursula Epting: what is the proposal for namespace?
MS: Proposal is to define a namespace for the PMA inside the CA namespace.
TN: I’m a GlobalSign RA. Anyone wanting to become an RA has to go through an accreditation process, with 1-day course, check passport, etc. As an RA, you must check that hosts belong to the organisation.
MS: GlobalSign have some strong requirements for RA procedures that may be reduced. Replace telephone calls with signed emails, etc.
TN: GlobalSign are restricted by their WebTrust accreditation. There will be a large delay in making policy changes.
Anders Waananen: What about Globus service certificates?
MS: Everything in the subject has to be verified. Should be OK.
AW: Any indication of cost?
TN: Should be zero for users.
DG: I want to stop issuing host and server certificates.
IN: What is the interface? Is there batch support?
MS: We expect web interface. Tender requested batch interface. There are some XML interfaces to the GlobalSign system. Doesn’t meet all requirements but they’re willing to work on it.
TN: in general if you’re willing to pay GlobalSign will make changes.
AW: Press Release “Service may be extended to other countries”
MS: yes, after pilot phase we would like to extend it.
TN: Public answer was, after initial period, when people feel comfortable, they will be able to come in and they will need to pay a little more than the original 8.
DG: How do we go forward with accreditation?
MS: CP/CPS is not yet ready. Probably not ready for end of May. For next meeting after that.
RK: Will there be a new CA root for this?
MS: I guess there will be a new CA under the GlobalSign root.
Tea
(Presentation)
Uses native authentication environment. Turns it into a 7x24 operation by using local site security.
There may be some universal requirements, e.g. for photo ID. For now the SLCS requires that the SLCS must document policy.
Naming policies from Universities. There is a lot of reuse of user names.
SLCS are not expected to issue CRLs, but 11 days is quite long.
MS: why does commonName have to relate to actual name? Not really required for short-term tokens.
If the underlying account is compromised there could be a 11 day keypair about.
TG: There’s an issue about revoking access to the SLCS account rather than the cert itself
Will TACAR accept SLCS CAs?
Audits can be performed by “other accredited CAs”. Is this just other SLCS CAs?
MS: What is the relation between the End-Entity and the subject of the certificate? There should be a record of mapping authn accounts to DNs.
DG: Might be good to have an annotated version of the SLCS profile.
“Every DN in a SLCS cert must be linked to one and only one End Entity.” but this only refers to single cert if read literally. Also the Subject DN is the important one.
Is this required uniqueness instantaneous or over time?
DG: Recycling DN of authorization certs would lead to inherited authorizations.
RKM: Put timestamp in the CN?
DG: Perhaps date of registration.
WW: Normally a document has a date when it expires. Could DN include expiry date?
TG: Only guaranteed to be assigned to that end-entity for that period.
DG: Problems of reregistering when name expires…
Action: recommend to TAGPMA that name uniqueness is an issue.
Disaster recovery is very important for an online service.
TG: Nothing about sharing private keys.
Bob Cowles: also, accounts used to generate keys should not be shared.
DG: accrediting body, rather than TAGPMA, should be the place to discuss disaster recovery.
TG: Private keys would be generated in browser or agent.
DOC: If SLCS generates VOMS credentials directly they aren’t important. But this would require all hosts which trust that VO(MS) to trust the individual SLCS. May not be possible to have multiple trusted VOMS for a single VO.
DK: How do we address scaling issues? How many of these do we approve? Concerns about where the profile was “finessed”.
TG: They are going to be approved one-by-one.
DK: As a relying party, am I going to have to check these individually?
DG: discuss identity mechanisms tomorrow.
AW: Confused about split between authn and authz. For KCA, do you have to approve Kerberos infrastructure of each site? How secure is your key distribution centre?
(Presentation)
Shibboleth-based. There are other projects to interoperate Shibboleth and Grid. In EGEE: Shib-gLite interop.
Why do we need different authentication profiles for SLCS and traditional CA?
Wants to generate traditional certs online using Shib to verify user identities.
TG: You could use Windows 2003 Server. IGTF federation is simpler than Shibboleth. (?)
CK: This is the same case as active credential stores. Why not merge shib with active credential store?
TG: This is not a short-term certificate. when you’ve issued a long term certificate you have all the problems of the user managing the certificates.
MS: Why not issue a short-lived certificate?
CK: We are just discussing a new enrollment procedure.
WW: when a person leaves a university, then the university must revoke the cert.
MS: SLCS and classic CAs are different so deserve different treatment.
CW: the main difference is that if the cert is short-term you don’t need to revoke.
MS: for authentication you don’t need long-term tokens.
(Presentation)
TN: existing PKI for SurfNet uses RSA Certificate Manager on Solaris with HSM. Currently using encipher hardware.
DG: There should be parity between how SLCSs are assessed in all PMAs.
BC: rely on CAs that they do not issue the same DN to more than one entity
From IGTF Federation Doc “In case the identity refers to a natural person, this identity shall be forever bound to this one entity, to the extent that this can be realistically validated.”
“Realistically validated” means we aren’t responsible for accepting forged/stolen documents.
Action: Request TAGPMA make DNs unique for life of service/namespace
TG: this will cut out all the US Universities. They want direct mapping and they want to recycle names.
Darcy Quesnel: It could be name + student number, which they should have anyway.
TG: They can append unique identifier.
TN: Had student and member of the executive board with same name, initials, city (but big age difference). Not allowed to use Social Security number. Some university ID numbers clash with other universities.
MS: the CA or the RA must know how the random numbers map to real entities.
JJ: It’s the user’s problem. User must prove identity to relying party.
Classic profile requires face-to-face meetings and photo ID. What’s acceptable for SLCS?
MS: by issuing cert, the issuer claims “I know who the person is and he has some relation to me”. If we put the responsibility on the issuer then we don’t have to worry about procedures…
BC: From the RPs POV we’re going to duplicate it in VO registration. We require that when you renew it’s the same person.
DK: Authorisation people think the authentication people are going to do it, and vice versa!
TN: when I get a warning “This DN already exists” or “This CN already exists” I can work it out. But with SLCS we will expect reappearances…
BC: Would initials + a number be an “appropriate representation” of a name?
DG: In SwitchAAI what is the quality of the Shib IdPs? Which ones meet the requirements?
CW: None at the moment…
TG: Some of our accounts are for grad students and there were no face-to-face meetings…
TG: How do VOs vet identity?
BC: VOs are more likely to have a relationship with the person.
DG: Set an attribute in the account database that says whether there was a face-to-face and if so allow the SLCS to issue.
Alan Sill: uni has adopted shibboleth to move the problem somewhere else…
BC: I think it’s better to put the responsibility on the VO to do the identity vetting. When somebody renews you must know it’s the same person.
It’s not easy with classic. If I compromise a certificate I’m going to renew it.
AS: Universities feel they have solved the face-to-face problem… BC is right, and identity vetting for VOs should integrate with Uni authn.
DG: What if a VO disappears leaving files behind which contain illegal material. The VO is gone so you can’t find out who they belong to and the site is responsible.
BC: The VO should be long-term like a CA.
DG: but there could be short term VOs…
DK: We don’t know all the RPs. All we can do is specify levels of assurance, face-to-face or not.
MS: Requirement for face-to-face. Comes from the fact that most CAs don’t know their users. In the case of SLCs they are provided by orgs that know their users.
RKM: do the RPs want face-to-face? do they want to serve the masses via Shib, RADIUS, etc.
TN: Asked Dutch higher ed security officers “how many are certain that there are less than 1000 entries in the account databases that are not invalid or expired” and none raised their hands. In own institute the database shrank from 25000 to 15000.
Every university has guest accounts.
Discussion on VOs. The VOs need to do some checking of identity.
DG: At the moment we can only distinguish by installing or not installing roots of trust.
TG: There is a SLCS in production (KCA) and it’s working.
BC: Users get less access via Grid than they would via a local account.
DK: What is the identity service used for on-campus? Library? Is it the site’s main authentication service?
JJ: Not everyone in the system has authorization to sensitive information but if you trust the authentication system enough to grant such authorizations…
DG: Want to have a collective assurance level for all SLCS CAs like Classic CAs.
SLCS Profile is weakly specified compared to classic profile.
CK: FermiLab is a closed organisation and we’re now talking about a larger-scale system. … This issue from the policy side is can we find an equivalence for authentication in institutions to what we require (for classic CAs).
TG: I don’t see SLCS and Classic as equivalent. And it’s not. Short-term certificate doesn’t have to be revoked. We shouldn’t try to make a SLCS into a classic.
WW: Almost every SLCS issuer will have different policies.
BC: If the sservice is institutionally run that’s fine, but if it’s just set up by a few students…
RKM: Do you expect to see a SLCS at each institution? Or should it be run by an accredited CA?
DK: Suggested that a SLCS cannot be a self-signed root of trust, it must always be a Sub-CA so that it can be revoked.
DG: A SLCS CA in front of a federation would be an appropriate model for deployment in Europe.
WW: There must be a difference in the profile between SLCS that rely on previous identity vetting (such as CERN).
DG: We could drop SLCS for now, and have a common profile for federations. Another common profile, that removes need for face-to-face but based on institution authentication service suitable for access to HR database.
Coffee
Proposed text for TAGPMA to include:
The backend identity system must be the primary organisation-wide authentication scheme and personal accounts eligible for SLCS certs that is also used for at least one of the following activities, or have been validated in a face-to-face meeting:
[This may not be the exact text as it was editied during the discussion]
DOC: Must the individual have these rights or is it just that the system is used to grant such rights?
DG: The individual must have these rights
WW: We can make it more generic: that there has been identity vetting for the person. And the organisation must record that. [Comment: this may require organisation to modify procedures]
DK: RP wants a profile for which they can accept all accredited CAs. BC: OSG wants a profile.
DG: SLCS profile has no requirement for identity vetting.
TG: PMA reads CP/CPS and if it is approved then you can trust it…
DG: If you only got the current SLCS profile would you accept all CAs?
DK: No. TG: Yes you would!
DK: There’s not enough information in the profile.
TG: Read the CP/CPSs.
TG: Want to wait for more SLCS implementations before modifying profile.
CK: Should specify in Profile what is require in CP/CPS regarding Identity vetting. Also, how many? In EU Grid PMA we have a clear idea about numbers.
BC: SLCS profile requires PMA to excersise due diligence in evaluating CA.
AW: Should we develop new SLCS like YPCA. And say “we fulfil the requirements”. Also, do we have limitations on the numbers to join?
IN: Profile Document is actually more specific than apparent from discussion (section 3.1)
DK: Issue of scaling,
DG: Plans for Europe: SLCS attached to national federation.
MS: Attach SLCS to accredited CAs. If at the national level the decision has been made that the entity is entitled to have the certificate. Could just run one CA for all the federations in Europe.
DG: “no more than one” CA. SLCS CA is responsible for evaluating backend system.
DG: Technical infrastructure doesn’t like hundreds of CAs. Should we run SLCS at the national federation level.
TG: But SLCS profile is aimed at site-level…
[Some agreement that in EU SLCS should be national/federated…]
DG: Good reason to link it to accredited CA so that SLCS is not a root.
[Recommendation that SLCS should be supported by a classic CA. ]
RK: A CA can’t normally issue Sub-CA with lower assurance.
DK: Does an accredited SLCS give you membership of PMA?
BC: If you have accepted the certificate for one of these SLCS in your bag of certificates for Globus does it actually check above that to see if it’s been revoked? (Answer: Yes.)
DG: Expect these to be run by same entity running existing classic CAs.
Need to summarise requirements on identity providers. Put thoughts and opinions on mailing list. Try to get an annotated version of the SLCS on the wiki. Indicate open issues.
TG: EU Grid PMA going to write recommendations to TAG PMA.
Lunch
(Presentation)
TG: are you considering moving this into an international standards body? Probably…
MS: Everyone needs to add something to EduPerson…
End of Minutes for Day 2
The following notes do not represent a complete record
(Presentation)
“Outsource certificate trust decisions to a trusted service”
“OCSP is a subset and analogy”
“There is enough existing technology to develop a deployable common solution”
Globus, Internet2/Educause, US Federal Bridge
Develop initial requirements…
Software:
US Gov research http://www.cio.gov/fbca/pdvalwg.htm
What does the VS return? OK? Frank Siebenlist suggests: a useful “local name”
What needs to be developed: probably a pluggable service
What European Certiver interest might exist?
MS: Is the project about developing the global service? Routing validation requests to individual VSs
Going to GGF…
Limerick Terena conference 3 years ago. German firm presented similar work. http://sit.sit.fraunhofer.de/_SIT-Projekte/NSI/index-en.html
TN: service we would like to have in an ideal world.
There was an XKMS group in GGF…
Attempts to standardize profiles.
DQ: start certificate profile wiki pages…
WW: what extensions mean, what software uses it…
JJ: divide up work for people to do…
Example: text T-61 v UTF-8
Action: By 3 weeks there should be a wiki page and responsible person for each attribute…
(Presentation)
E-infrastructure shared between Europe and Latin America
(Presentation)
Coffee
Name space policy file is named
MS: Should use RFC standard format for DNs.
RKM: how long would you have to support old format?
DG: 3 years…
JJ: suggestions of other improvements to validation such as OID checking.
DG: Should be in gLite.
In Unicore, it doesn’t need entire chain.
grid-ca-monitor mailing list