Note These notes do not aim to repeat information that was clearly available in slides.
26th EU Grid PMA will be in Lyon, FR September 10-12, 2012 (Week before EGI TF, Prague)
27th EU Grid PMA meeting, to be discussed (proposal in Abu Dhabi)
DG introduced the agenda.
Malaysian CA is the most recent to join, accredited in February 2012. In Mongolia, Mongolian Academy of Science has taken over and re-started accreditation.
Some areas don’t have their own CAs but get certificates from AP Grid PMA members.
The AP Grid PMA meetings are routinely co-located with other events, in particular with ISGC in Spring in Taiwan.
EY notes that most CAs are concerned with the operations rather than policy, due to funding, etc. CAs are attempting to make their CAs easier to use. There are a number of regional and catch-all VOs operating in the AP region.
IHEP and APAC are responding to issue of email address in DN. ARCS CA is looking for funding after May 2012. New Zealand users may move from ARCS CA to ASGCCA.
Areas of interest included federated identity management, proxy delegation in portals, MICS, SLCS. The location of the next AP Grid PMA meeting is under discussion.
DS mentions services in progress: Peru. An XSEDE high-level CA has been proposed, which may allow consolidation of some XSEDE member CAs. XSEDE service providers would become RA.
NCSA have brought up a Two-Factor CA, which was accredited in three weeks.
TAGPMA website overhaul is overdue.
TAGPMA has accepted the updated Classic Profile v4.4. TAGPMA has scaled back phone meetings to once per month.
TAGPMA 16 will be co-located with the CLCAR conference in Panama August 27-31 2012. DS is planning to meet in the middle of the week, as there will be tutorials at the start of the week and conference sessions later in the week. It was noted that the meeting conflicts with the GridKa School and an Argentinian conference.
The Relying Party member NIH has been unresponsive lately as the person responsible has been promoted and is not available.
It would be good to have a co-chair to prod members to ensure they are active, and also to test response of CAs. It may be interesting to have a member of the RAT. We are looking for volunteers.
JJ says it would be useful to send an email every quarter to check that RAT members know how to use it, and perhaps twice a year, prod the CA contact list. The co-chair would check if there are any slow-responders and gather statistics on how CAs respond. There are tools to help run these tests.
Willy Weisz has offered to act as co-chair.
CK says that in general, they do operations well, but policy needs work. CK ran through the audit items. Eight of the “B” items are “practically A” (i.e. practice is good but some minor change required to policy).
DS asked what is the time frame for addressing these issues. CK and CT responded that most policy and practice issues will be addressed within weeks, however the issue with auditability of logs, etc. will take longer to fix.
CT says that – as for the HellasGrid CA – they do operations well, but policy needs work.
DG asks, as the CA is going to expire in 2014 will SEE-GRID CA issue a new CA certificate. The response was that it depends on the usage of the SEE-GRID CA: the catch-all service is likely to be needed by, e.g. some African countries.
Edgars Znots and David Groep volunteer to review both CAs.
The goal is the minimize the impact to users and services, and to formalize the procedures for CA, user/host and RA. In some cases, the RA is more stable than CA as RA is part of the user community.
Discussion will return to this topic after Scott Rea presents Registration Practices Statements.
Note on terminology: in TAGPMA, Registration Authorities (RAs) are often affiliated to a community or project, and may have multiple distributed Local Registration Agents. In EU Grid PMA, CAs are typically national and RAs are typically local agents in an organization.
SR notes that in a lot of PKIs the identity vetting is often performed by a community e.g. an enterprise, a university. Typically in the IGTF community we write combined CP/CPSs. In a lot of communities they are separate. A Registration Practices Statement (RPS) is becoming more common in the commercial PKI world.
SR proposes to add a new category of PMA members for Registration Authorities. These would publish and RPS, and a CA would describe how responsibilities are shared with accredited RAs, and how accredited RAs meet the CA’s CPS. One of the benefits would be that new communities, represented by an RA, could join the grid without needing to operate their own CA.
The OID of the RPS could/should go into a cert to indicate the policy under which it was issued, although the issue of middleware support for OID checking was raised. KC noted that in the case of FermiLab there are some CAs FermiLab is not willing to accept, e.g. University CA’s that issue certs to all students as an RP I have to be able to consistently identify which categories are allowed.
WW commented that up to now, when we’ve accredited CAs, the CA is in charge of checking registration process of RAs, If RAs are accredited independently, we will start getting conflicts (between RA and CA policy).
DK notes that there are two issues, registration practice statement (which are a nice idea) and registration authority accreditation, which is more controversial.
SR pointed out that an RA would have to show that they have justification to be accredited.
There was some discussion of what sort of RA is being discussed. In the US, and example would be OSG and their network of RAs (where ESnet CA services are being withdrawn.) SR clarified that Local Registration Agents would serve a single Registration Authority (subject to an RPS).
IG explained that people tend to be associated with lots of different projects over time. Would like an organisation to do identity vetting for a scientist, so that he doesn’t have to prove identity when moving from project to project.
KC noted that some of this is a consequence of CA operations in the US, e.g. DOE Grids won’t support non-DOE communities.
There was discussion of whether IGTF is the right body to accredit RAs. ABE stated that it was the CAs business to accredit RAs. SR explained how this is common for commercial CAs and could be less work to allow RA activity to be separated from CA. There was discussion of voting rights for RA members. Perhaps RAs would only vote via a CA. WW was worried that there might be tension between RAs and CAs leading to a split.
DG summarizes that RPS are generally considered a good idea, but changes of membership status for RAs is controversial. DG suggested we don’t alter processes. If an RA / community / project has an RPS and a new CA says it can take over the community, and if it has an RPS that was previously considered OK, it should be OK again.
MS notes that RPS is nice but there are many IdPs that already document their processes and won’t be willing to provide a new format. MS is worried about the situation that IdP can’t be used due to discrepancy of policy format, etc. SR says the reason for suggesting this is same as for CP/CPSs for CAs: ease of comparison, etc. and notes that nobody has to do this. DS states that if you have a an IdP that you want to be mobile between CAs, then this could make it more easy to do so.
RKM asks what are the cons. SR notes the additional work up front and some of the other cons mentioned today.
DS suggests an ACTION for SR, to clarify how the proposal helps to sustain CA responsibilities, that it is not mandatory, and to highlight use cases
DG noted that EY’s particular case will be discussed tomorrow.
Note: DG edited the risk assessment document during this session. Some discussion is omitted particularly where improved wording has been added to the document.
SHA-1 is weakening rapidly due to clever cryptanalysis. But moving to SHA-2 requires ubiquitous software support. Unfortunately the risk assessment is not complete. This session will be used to make progress on the document.
DG introduced an attack feasibility scale, where the risk depends on CPU availability and their interest in IGTF PKI. Targets are High-Throughput Clusters. DS noted that HPC systems can be complex to use and so the target is often embarrassment or botnets.
DS noted that in practice there is often an accelerating curve of attacks, e.g. when an automated tool becomes available. DG also noted that if a cryptanalysis breaking SHA-1 is done, it will be made public rapidly by researchers.
Discussion turned to attack surfaces. Self-signed root certs are considered to pose no risk. Intermediate / cross-signed CA certs contain no end-user (attacker) provided data. EECs can contain limited amount of end-user data and could be “turned into” an intermediate CA cert, by setting BasicConstraints to true. As the intermediate cart can be sent in SSL handshakes, pre-distributed intermediates will be overridden. Such an intermediate CA could also override revocation data.
Regarding proxies it was noted that there are easier ways to attack these than hash collisions.
Regarding CRLs, it is important to determine how to respond if SHA-1-signed CRLs are no longer trustworthy. OCSP was also mentioned and added to the document as a potential attack surface.
Blackmail and social engineering were added as potential attacks: if an attacker can claim to have the ability to break SHA-1, this can be used to extort money or services from CAs.
DOC suggested adding RA-CA communications and request submission as attack surfaces.
DG notes that we want to come up with a “remediation matrix” for each attack surface addressing the response for an attack on each attack surface at each level of feasibility.
DG presented a proposed timeline for changing from SHA-1 from WLCG. DS noted that publishing an advisory may help to pressure vendors to act.
SR described the experience in the US Federal space, NIST set a changeover deadline of 31 Dec 2010. Vendors did not act until US Gov said they wouldn’t buy services based on SHA-1.
There was discussion of how to avoid a “panic” situation by setting out the possible consequences in order to promote a managed changeover to SHA-2.
Regarding middleware support (in WLCG presentation) KC noted that VOMS and operating systems were not mentioned. It also wasn’t clear from the WLCG input what software was tested and with what variant of SHA-2 (SHA-256, SHA-512, etc.)
JW has asked PRACE internally and there are apparently no concerns.
Testing was discussed. SR noted the need to get SHA-2 certs for users and hosts and SHA-2 CRLs and to install in the normal operating environment.
MS asked if there is particular advice on the variant of SHA-2 to use, or is it good enough to say SHA-2: are we going to let CA pick what they want to use? SR responded that requiring “SHA-2” generically will allow CA to pick (some CA products only support particular variants). This was the approach in the US space. Possibly support for some variants such as SHA-256 and SHA-512 will be required in middleware, while others may be optional.
CT noted that many sites haven’t migrated to UMD and it has been out over a year. The implication is that it will take time for grid sites to migrate to updated middleware. KC said people moved from RHEL 4 to RHEL 5, when RHEL 6 was already available. DK suggested that validation of EGI UMD 2 should be done with SHA-2 in mind. IG agreed that once we decide we’re switching over, it’s going to take a year and a half to switch over and we have to allow this long.
MS proposed that we say that we will start issuing certs with SHA-2 in January 2013 and SR said that the US Fed Bridge required CAs not to issue certs with SHA-1 from 1 January 2011.
MS, in response to WW, noted that Redhat don’t include all the algorithms on RHEL (e.g. elliptic) so it is necessary to check the actual software installed, and not sufficient to assume the distributed version of OpenSSL will work due to age or version number.
It was agreed that it would be useful if IGTF CAs could say that they are capable of supporting SHA02. KC & IG note we want to make sure that SHA-2 works and that SHA-1 can be blocked. IG, KC and SR discussed possible approaches to “non-natural” rollover (e.g. revoking certs) and whether RA validation or authorization registration (e.g. with VOMS) will need to be redone?
KC noted that the document is missing discussion of what OS and M/W has been tested and found to interoperate or found to fail. WW added that we should consider hardware tokens which only support SHA-1, e.g Safenet eToken PRO. MS noted that we may not want to list software, etc. within the document, but instead link to an external evaluation.
SR suggested adding OCSP as an attack surface, and trust list management, i.e. can software handle CA / CRL signed with SHA-2?
Regarding testing, ABE suggested producing a test list and DG noted that IGTF should not be expected to do the software testing itself.
There was a discussion of randomly generated and strictly monotonically increasing serial numbers.
It was noted that the CA trust anchor distribution web site would need to be updated to use a SHA-2 signed cert in advance.
DS noted that having distribution packages signed with multiple different checksums in advance would be a mitigation. DG says debian packaging allows SHA-2 sig, so it is partly supported.
There was discussion of what “readily possible” compromise would mean. DOC suggested small numbers or slow stream of compromises.
JW said that, as RP would prefer it to be treated the same as “trivial”.
KC suggested that in this case CA’s could issue SHA-2 credentials based on existing SHA-1, then audit all existing SHA-2’s in retrospect, and revoke all SHA-1 credentials.
DS noted that in the case of cryptanalysis which has demonstrated feasibility on specialized hardware (next category of feasibility), that has started clock on changeover.
RKM asks can we reissue certs with SHA-2 with existing key material. The response is that the software may not know how to deal with this, but it would avoid the need to re-do face-to-face identity vetting. AB suggested CAs could start issuing two certs for every request (one with SHA-1, one with SHA-2).
CK notes that this issue affects not just grid infrastructures, and users, etc. may ask why should we take this measure if some other organization (e.g. a bank) does not? MS pointed out that banks are likely to have such a plan.