Guidelines document developed in TAGPMA almost identical to EU Grid PMA except when discussing end-entity certs and lifetime.
WW: Is MyProxy acceptable under rules of PMA.
DG: Normal use is OK. Storing a short-lived proxy.
DK: RPs or this group should define best practices for running MyProxy service. Are any CAs considering offering such a service?
MH: FusionGrid MyProxy/CA. Following NERSC MyProxy guidelines.
When a service is running online availability becomes important. VO or other operator needs to budget for support. People will expect a 24x7 service.
MH: Wondering about support for RADIUS and one-time password. Talking to vendor about 802.1x. Wouldn’t be able to generate proxies at first but should be possible in future. RADIUS server with account DB built in. http://www.infoblox.com/ Certs generated automatically.
MS: Could develop Open Source version. Alternatively we buy commercial software with some validation, but we can’t see inside.
MH: How’s cryptographic engine certified?
TG: Windows 2003 provides these services and is validated for government and financial uses, etc.
MH to send details to the list.
DG: Should we make a profile?
MS: Somebody has to
MH: Need some interested people
JJ: We plan to use MyProxy like this. Users put longer term proxies in Credential store. MyProxy uses MySQL DB to store credentials.
MH interested in distributing credentials
DG: Develop srevice and requirements in parallel
AW: Do these ideas require new CAs, and hence new minimum requirements?
DG: Several guidelines documents. All CAs accredited as appropriate. RPs can accept all accredited CAs, or just certain profiles.
Three categories:
Can have multiple ACS with one CA in the background: decreases proliferation of CAs. ACS is probably quicker to implement. ACS need not be linked to a site, could accept multiple CAs.
MS: Why have a long-term credential? You have to authenticate for access to the store anyway. Does store do crypto operations for you? It signs new keypair with your private key.
BC: Anybody can setup MyProxy without talking to us, and it should just work. This is a relying party issue.
MS: No, I must revoke certs that I know the private keys are stored on these services. So this is a policy issue.
BC: Not different to storing on NFS, etc.
JJ: BC’s reason is why I need ACS. Want users to have more secure remote credential store than NFS.
DG: Will there be a document on this in TAGPMA by May?
TG: DS has been working on this.
Rekeying.
If you change DN and hash then there is no problem. If you wish to preserve it, there may be problems.
With OpenSSL there are
Has anybody tried this with Globus? This may not have been included in GSI.
Need to work on updating CRLs. fetch-crl cannoth handle anything but .r0 files.
LS: Can cert extensions be used for specifying CRL.
Not defined for root cert, intended for EE certs. Is there a standard extension for OCSP location? yes. Again EE certs.
Easy solution for a site is to delete CRLs. Most grid sw don’t do CRL checking on the client side.
DG: Should encourage CAs to have CRL and OCSP locations in certs.
AW: Who should install certs and CRLs? In some cases the user.
MH: Software designed with network directory in mind. Out-source service to XKMS to evaluate if cert is trustable by you. Easier to subscribe to LBL XKMS service.
AW: it shouldn’t be up to the site manager to decide who you should talk to. yum repository auto-updating and dependencies helps.
MH: a lot of complexity. people don’t always get it right. Outsourcing to a service seems like a good idea. OCSP is a wedge… Imagine a cert that I “think” I should trust but how do I know?
Back to the CRL problem: Can you add more URLs to crl_url file? Anyone due for a change soon: AW, MS, DQ. Anyone willing to experiment: no!
What’s the ususal period to get new CAs iinstalled? Up to 6 months, maybe less than 1 month. Also needs to update fetch-crl scripts at sites.
Un-fork fetch-crl script and host at EU Grid PMA.
SN: why does LCG distribute CA/CRL through Marcus Schultz home page?
DK: LCG includes additional CAs
DG: sites should mirror eugridpma repository
Do we need multiple tools for different dependencies?
DG: happy to host at EU Grid PMA.
HSPD-12 http://csrc.nist.gov/piv-project/
Very aggressive deployment calendar
Good news
Less good news
Rumours
Should strongly-recommended extensions be listed in min reqs? (Modifications were made to Min Reqs during this session)
Sun Java JCE, at least, cannot support 4096 bit CA keys. Problem in DEISA but not sure which JCE provider. Globus uses BouncyCastle. Until this problem is resolved is resolved keys should have 2048 bits. 4000 bits not tested.
Make requirement that EE must have OID to identify. Put a timeline on this. New certs should have this starting in 6 months. In 1 year all issued certs should have it.
CRL distribution point in EE certs. Require this?
MH: Originally extensions weren’t included because tests had not been done.
Standard extensions in RFC 3280.
TG: Possible that distribution points could get blocked by firewalls, etc.
What protocol should we use for CRLDistributionPoints? Must at least provide HTTP (not HTTPS) URL.
Standard says not to put basicConstraints in End Entity certs.
MH: Our CA software doesn’t support basicConstraints in it. Could say “basicConstraints MUST NOT be set to ‘CA: true’”.
RC: “Should” needs to be explained better in the preamble.
If you run OCSP then MUST contain AuthorityInfoAccess.
OCSP RFC 2560. Format is URI.
Details in RFC shouldn’t be duplicated in Min Reqs
NSCertType must be compatible with keyUsage.
JJ: Added SSLClient to NSCertType and allowed different behaviour for renewing.
MH: would like to get rid of them
MS: No NS* extensions in Grid context
RC: No NS* extensions for last 6 months
RFC 2595 — SubjectAltName
Support for multiple DNS hostnames in browsers:
MS: can also be useful to have ipAddress in SubjectAltName
Message digests must change to trustworthy hash mechanisms like SHA1, and avoid MD5.
(Min reqs updated live)
Discussion of requirement that CAs should not be bound to a specific projects and should be operated as a long-term commitment.
Discussion of hierarchies: no longer such a key issue. Modified Section 1.
Secure environments: CAs have to document or audit.
Names: want entities to “own” the names. Come back to 3.2 after discussion
Discussion on persistence of name bindings to entities.
End Entity Certs
Revocation
Changes should take force 6 months after acceptance, and at most 1 year after.
Trying to encode intent.
Trust is axiomatic.
Private Key Risks:
At the moment the assests aren’t that interesting. High-value cert protected by 6-digit passphrase or 16-digit on a sticky note.
OTP adds extra factor, but out-sourced tokens might move risk. Software implemented OTP also possible: another set of risks.
Credential repositories seem popular because big sites can run them. But big sites don’t necessarily have great security record.
Important to have threat analysis, intent, etc.
BC: If we did risk analysis we might find that we’re wasting a lot of time on CA stuff when it’s a mess at the user level
DQ describes USB key with autorun Java application to provide proxy creation, delegation, etc. Can enforce key hygiene, etc.
http://www.eugridpma.org/meetings/2005-01/guarantees.txt
Key is compromised. Attacker renews. Revocation doesn’t catch new cert.
MS: User should be informed that a new certificate has been issued and should have to accept the process.
BC: Should renewals be allowed, say, 6 months before expiry? That should raise a flag.
May need to revoke certs with same DNs if renewed before revocation. EE can revoke cert without RA contact.
MH: But user could decide the cert is compromised, renew and revoke old one in good faith.
User claims to have lost old cert/keys. Will you re-issue cert with same DN? Social engineering opportunity.
CA promises they will not issue to same person. This is an RA issue. The RA needs to check.
JJ: fine, until we need to handle two people with the same name.
Do we have min. reqs. to hold onto identity documents? Not possible in some places?
Disagreement about how multiple certs per DN and per user should be issued.
Keys should only be signed once.
If one user has a keypair, and a second user comes along with a new request/keypair that’s the same, it is possible for them to find that they have the same keypair (i.e. they can see the existing cert) and then to impersonate the first user. First user should be informed and asked to renew? (Impersonator could attack this)
MH: Users like to renew with same keys. Convenient.
DK: Same argument as asking users to change passwords.
MS: 1024 bit public key available for 5 years is a risk
MH: even if private key is in hardware?
BC: If you’re not going to change the key then what’s the reason for renewal?
MH: Lifetime of people, jobs, institutions, etc.
BC: threat of replacing software users are using to generate keys by some virus to reduce keyspace.
A lot of software depending on DN being unique. RPs relying on CAs not to have overlapping namespace, and not to have unique DNs.
RPs should log serial number as well as the DN.
DK: as more CAs come along, namespace coordination of CAs is getting more difficult.
VOMS stores CA DN, and cert DN. This is a problem for CA renewal.
Existing software doesn’t seem to log serial numbers. Authorization done on string comparison.
http://www.eugridpma.org/meetings/2005-01/peer-service-certificates.txt
Not quite like automated clients. Use same approach as OU=robots, which is not allowed by signing policy.
TG: can’t run multiple services with the same name on the same host.
service/ tags in CN don’t have meaning to the clients or servers.
Discuss dates of next meeting in Tallinn over mailing list.