The next meeting will be in Lyon, France in September 2012.
There was discussion on the location of the following meeting 14-16 January 2013. Abu Dhabi, UAE has been proposed although not confirmed by the hosting organization. An alternative venue would be Florence, Italy. There will be a call on the list to check who can commit to go to Abu Dhabi or Florence.
For May 2013 meeting, location is Kiev, Ukraine. Proposed dates 13-15 May 2013.
For September 2013, location is Bucharest, Romania. Proposed dates 9-11 September 2013.
Version 1.0 was discussed at TAGPMA and aim for today is to address these comments.
DK has been looking for a volunteer VOMS admin to comment on it. Steve Traylen has read the document. His initial reaction is that it is somewhat complex.
TAGPMA had commented that IGTF limits the namespaces for CAs, and in the AA case how can we know that an AASP is authoritative for an AA. DK suggests that this may be out of scope. KC says that we have cases of AAs in multiple locations (e.g. ILC at DESY and FermiLab). Similarly for CMS, and Brookhaven does it for ATLAS.
EI notes that this is not a namespace issue. DK comments that it becomes an issue as VOMS server name is embedded in the credential. MS says that it is two different things: locations of the service and naming of attributes. KC notes that naming of attributes is an issue as VO has to negotiate with each AASP meaning of attributes.
DK says that we need a statement to say who does what. SR comments that, based on the discussion of RPS, we need to be clear about terms.
MS says we have an opportunity to standardize attributes, etc. for AA. IG and DK note that attributes can belong to a community and it has been difficult to get agreement, e.g. between LHC experiments. DK shows that the document states that the AA defines the semantics of attributes.
WW notes that the comment was requesting that AASP namespace should be limited, but this should be defined by the AAs somehow, not IGTF.
DK notes that the document may be missing how the AA gets the attributes into the AASP, but as technology may differ it may be best to make a generic statement that attributes will be provided securely.
There was a comment from TAGPMA that there is no mention of renewal of attribute assertions. DK says that the issue is who can request renewal. Discussion between KC, WW and others turned to how such renewal would be handled with Condor and VOMS, or MyProxy.
WW raised an issue with the “Responsibilities” section, where it is stated that AASP is responsible for validity assertions within lifetime of assertion. WW argues that it can only be held responsible for assertion at time of issuance. DG says that RP cannot take all responsibility. KC argues that RP could agree to accept some residual risk.
Australian CA may stop serving NZ users, but NZ user community will remain. Conversely in Malaysia, there is currently an RA attached to the Taiwan CA, which could move to the new Malaysian CA.
SR said taht he didn’t see any issue with CA establishing an agreement with the RA. If RA is involved with two CAs, they will be producing different certificates in different namespaces. EY was clear that CA 2 won’t issue certificates on behalf of CA 1.
DS says that issue of “transference” may not matter, as the new CA is just adding a new RA. DG asks do we expect RA to re-vet all persons. DS answers yes, if the rules are different. Otherwise it is fine.
SR says that in his mind CA 2 should treat clients of CA 1 as new clients. If agreement between RA and CA addresses how vetting will be handled this could be simplified.
MS says the best scenario he can imagine is that CA 1 knows when they are due to finish, and can find some successor, and agree that CA 2 will re-issue certs using records.
SR suggests that CA 1 could hand over key material to CA 2, and deal with it as a Sub CA of CA 2, as part of a wrap-up. AB raises the issue that CA 2 should audit CA 1 before taking this on.
The decision was made that the RA will serve two CAs. The documentary evidence will stay with RA and is known to be compatible with CA 2. CA 2 will be able to authenticate users of CA 1. Certificates will be issued to a new namespace.
During the discussion SR raised the issue of whether CP/CPSs have enough information on how to handle CA retirement.
ABE presented the EG Grid CA. ABE was involved in a project to develop and manufacture Egyptian PKI tokens, and provided some for attendees of the meeting.
SR asked if there is an online issuing CA. The answer is no, the Root CA is offline.
Feyza and Usman have looked at the policy. Feyza mentioned that the name form of server certs (including ’/’) had been sent as a comment. DG noted that the CA cert does not have a Common Name.
DG called on the PMA to review the CP/CPS within the next two weeks.
DK asked about key length: The CA cert key length is 8192 bits.
IGI is the Italian Grid Initiative, although does not currently have official status.
IGI is planning for two new CAs: an online MICS CA and a Root CA. The existing INFN CA will be come a Sub-CA of the Root CA.
RC explained how the MICS process works. A CSR is created by the CA bridge, a long term cert is created by MICS CA, a long-term proxy is installed in MyProxy, and the long-term private key is deleted. Note, the certificate is not revoked.
MS argues that if the MyProxy password is compromised / stolen it is necessary to revoke the certificate. RC says that the MyProxy credential will be deleted. CT notes that if you store a proxy in MyProxy you can renew it indefinitely. If the MyProxy server is pubicly available then anyone could continue to renew indefinitely. MS raised the issue that the keypair is being generated outside the user’s control. MS says this is the first CA to do so.
RC says that anyone interested in penetration testing is welcome to make contact. DG notes that potentially there is a possibility for other organizations to make use of this software or the IGI service as part of a business model for IGI.
See slides
SR discussed the CA attacks during 2011 and introduced proposals for improved trust management.
Long CRLs are a concern for high-value assets. For OCSP implementation is not consistent. CAs want to eliminate CA weakest link issue. There are now several hundred CAs in browsers / OSs. There are something like 650 trusted roots. Because all are trusted the same, you don’t have to go after the good CAs.
CAB Forum is focussing on minimum standards for ICAs; better implementation of revocation mechanisms; It may be interesting for IGTF to look at CAB Forum Basic Requirements. e.g. Elimination of issuance directly from a root cert.
CABF Revocation WG has participants from ICAs, browsers, Research and Edu, IETF, RPs. For Internet CAs, OCSP is important although there are costs for high-volume environments. DigiCert handles certs for Facebook.com and that accounts for 30-40% of OCSP traffic. Things like OCSP response sizes matter at this scale.
OCSP as small CRLs
Some clients will only check one AIA OCSP responder. Others will check all.
Current dev focus: getting Mozilla to support GET, and encouraging servers to support OCSP stapling: nginx and Apache work in progress.
ABE asks about grid infrastructure support for OCSP, and asks that if commercial CAs have been attacked and taken out of business what is the impact on this community.
SR thinks OCSP is worth looking at in IGTF. Regarding compromises, in this community there may be some CAs operating with better procedures, etc. and we may suffer from weakest link issue. SR notes that MITM don’t do frontal attack on CA and network, but on weakest link on RA, etc.
KC asks is the CABForum a body analogous to IGTF in some respect. SR says he thinks so, as it’s a self-regulating body run by browsers and CAs and including some RPs. It is planning to become more open and introduce open mailing lists. MS notes that browser vendors are given responsibility for browser users.
MS says he realized that he cannot delete CAs from Mozilla any longer. SR notes that a lot of users are frustrated that they don’t have control. There are power-users who are unhappy, but most users accept defaults.
RKM says, if you import CRL the auto update only works for US date formats. SR mentioned that Microsoft auto-update will restore deleted trust anchors. MS says he has “one” trust anchor: Mozilla.
MS says we haven’t noted CA-less PKI. SR will discuss it tomorrow.
Jens noted that some private key / certs are highly privileged, e.g. could be used to delete all files. So some keys may deserve better protection, and perhaps 3 or 4 LoAs would be enough. For users who can’t manage keys, a keystore is safer in their case. Suspension of keys (temporary revocation) may make things safer.
A CA defines what user can do with their keys.
Proxy generation and use is generally outside the scope of CA. Browsers may allow long-term activations. Proxy certs have non-revocable activations.
Key archival may be useful, or it may be necessary to prove that a key has been destroyed. Backups can be helpful, but activation of backups is an issue.
JJ notes that an online key repository may need to deal with data protection issues as, for example, use of a key with a particular VO may be sensitive (e.g. reveal that a user is working with sensitive data).
JJ notes that if there is documentation of host keys, there should also be some for unskilled user keys.
Best-practices for running a trusted their party repository would be helpful. JJ proposes that it must not be the CA, but can be run by the same organization that runs the CA. Possibly not even the same administrators.
Subscriber should use a trusted repository, trusted by RPs. JJ discussed use of a passphrase external to the repository, e.g. site SSO.
DG suggests putting a time-line on creating a first version in a couple of weeks. JJ has scheduled this.
S-Series Soapbox.
The meeting in September 2012 will be held in Lyon hosted by IN2P3 CC.