http://agenda.cern.ch/fullAgenda.php?ida=a031679 Agenda agreed
(presentation online)
Aiming for acceptance by DataGrid and hopefully EGEE.
Subordinate Certification Authorities favoured by management. Would need CP/CPS for each sobordinate site. There may be problem with CRLs. Need coordination to have a single correct CRL.
Inconsistency with min requirements regarding CRL issue. Min Req for CRL issue 7 days before CRL expiration.
2.8.3 “CA may disclose the time of revocation” if time is not disclosed then it’s not a CRL. Time is disclosed in time stamp, so in effect it will be.
Suggestion that multiple RAs and a single CA would be preferred.
Aside: There is a new CP/CPS RFC (3647 obsoletes 2527)
Authentication procedure
Rekeying: RA will not be involved in rekeyinging provided that the last identification is not longer ago than 10 years. Certs tie a user to an institution, so this could imply a tie long after the user has left. Agreed at a last meeting that we would require intervention from the RA at rekeying.
No definition for “relying partner”. Perhaps a typo for “relying party”. Impossible to inform all relying parties of changes to CP/CPS as the CA does not know who they are.
Rosette Vandenbroucke (or BEgrid CA) will address comments and produce a corrected version. If there are no further comments within 2 weeks the CP/CPS will be approved.
Christos: In HellasGrid institutions want their own CAs. Need to stop this tendency…
Darcy: previously dealt with in Canda.
Stephen: if 10 subordinate CAs pose a scaling problem then we already have a scaling problem!
(presentation online)
DN doesn’t have country code C=il, but it does have OU=IUCC which is assumed to be unique.
Aside, Stephen: put OU=USERS before OU=<institute> will give faster search of LDAP space.
Why should only “default” RA issue host certificates?
Discussion on key lifetime and key length. Should a longer key length give a longer lifetime? No, if a key can be broken in one year or two years it makes no difference. Key lifetime is to do with RA database refresh rate.
Stephen: 1700bits provides commensurate strength to 128bit AES. 1024 is fine for authentication (we’re not storing data) Get rekeying in sync with institute registration, etc. to reduce RA costs.
Certs are supposed to be for authentication only.
Relying parties don’t get info about users from CA, but the CA does vouch for info in the certs. CA only verifies that info was correct when issued. Ian: RA doesn’t continually check. Dane: someone changes institutions and their old cert may get abandoned and then stolen.
Function of CA is to provide unique identification. Contact info, etc. cannot be relied on. Email address or phone number getting invalid are not reason for revoking a cert.
Dane: if I’m worried about users I’ll keep my own DB or have an agreement with a VO to deal with problems.
Aside, Brian: eInfranstructure body wants to discuss authentication including CAs.
Discussion: what requirements from other bodies are there? We decide to trust each other, representing the relying parties and VOs.
Is there a reason not to allow 3 year user certs?
Tony: Is there a reason to switch to 3 years? Cost. With a large network of RAs it gets difficult.
Brian: is there a relationship with the lifetime of the CA? Well, it can’t be longer.
Moshe Goldberg will address comments and produce a corrected version. If there are no further comments within 2 weeks the CP/CPS will be approved.
(presentation online)
Discussion: Are Netscape cert extensions needed?
Root cert is for 3 years to allow for policy changes.
Distribution policy is related to user certs rather than CA root cert. It’s possible to have certs issued with different policies on a single CA root cert.
Discussion: routine rekeying based on a signed email without authentication by RA. Is there a lightweight renewal in use? Roberto describes a web-based renewal. Not lighter-weight for the RA! RA checks that link with institution is still valid. Very similar to signed-email approach. Stephen: check that email is still valid (local LDAP service, etc.) and then accept signed-email.
At renewal CA/RA should check that user is still an acceptable end-entity. Robert: renewal should be out-of-band.
Aside: CP/CPS should have lifetime!
Important that RAs are involved in checking authentication at renewal. This seems to be a difficult issue.
CP/CPS says that ArmeSFo will self-audit. Others may audit at their own cost.
Ara Grigoryan will address comments and produce a corrected version. If there are no further comments within 2 weeks the CP/CPS will be approved.
Interim approval may be possible with suitable discussion on the mailing list.
Start of a Baltic federation?
: 2003-12-11.plog,v 1.8 2003/12/22 12:03:12 ocalladw Exp $