eugridpma caops-wg and igtf issues june 2012 delft, nl david groep, nikhef, eugridpma, egi and big...

EUGridPMA CAOPS-WG and IGTF Issues

June 2012Delft, NL

David Groep, Nikhef, EUGridPMA, EGI and BiG Grid

APGridPMA Taipei 2012 meeting - 2David Groep – [email protected]

Geographical coverage of the EUGridPMA

25 of 27 EU member states (all except LU, MT) + AM, CH, DZ, HR, IL, IR, IS, JO, MA, MD, ME, MK, NO, PK,

RO, RS, RU, SY, TR, UA, CERN (int), DoEGrids(US)* + TCS

(EU)

Pending or in progress ZA, SN, TN, EG, AE

TCS


Agenda

26rd EUGridPMA meeting10-12 September 2012, Lyon FR

27rd EUGridPMA meetingAbu Dhabi, 14-16 January 2013

28th PMA meetingKyiv, UA, 13-15 May 2013

29th PMA meetingBucharest, RO, 9-11 Sept 2013


Karlsruhe meeting results and issues

https://www.eugridpma.org/meetings/2012-05/

SHA-2 migration AAOPS Guidelines available – to be applied now IPv6 support OCSP RA Practice Profile RA migration to a new CA** GFD.125bis


Why the Risk Assessment?

hash algorithms (like SHA-x, MDx, RIPE-MD) are basis for cryptographic integrity of all PKI certs

SHA-1 most commonly used, but weaking rapidly ‘strength’ is the inherent entropy of the digest value strength is decreasing due to clever cryptanalysis good advice (NIST) has deprecated SHA-1 in 2010 more attacks are forthcoming

but moving to new hash algorithms (SHA-2) requires ubiquitous software support which needs to be in all M/W used by IGTF RPs but which is not (yet) there


Weighing the risks

assess the current state of the attacks on SHA-1 gauge probability of successful exploit in our PKI document possible remediations

that can be taken to preserve integrity of the IGTF for various attack scenarios and ‘complexity levels’

and consider the impact on our RP operations which things may break? how severe is a such breakage

and balance these risks against each other in an orderly fashion ahead of time!

Risk Assessment Doc


ToC for https://www.eugridpma.org/review/sha1


SHA-2 Decisions and Road Forward

ALL IGTF CAs should have or get the capability of issuing SHA-2 based certificates. All CAs MUST implement this a.s.a.p, and REPORT on the implementation of SHA-2 issuing capabilities by October 1, 2012.

This implementation of SHA-2 should encompass BOTH end-entity certs AND CRLs

CAs should schedule to start issuing SHA-2 based certs by January 1, 2013 (only if by December 2012 it is clear that everything will still break in more than one infrastructure may some CAs consider not moving).

CAs MAY consider shortening the validity period for EECs that are still SHA-1 based after 1-1-2013, so that the sun-set date for SHA- 1 (March 2014) is maintained. This will also encourage users to move to SHA-2.


SHA-2 decisions – the user end

There should be user explanatory documents describing the move to SHA-2

From Jan 2013 onwards, users SHOULD have the capability of requesting SHA-2 based certs from all CAs

Since software should accept at least SHA-256 and SHA-512 out of the SHA-2 family of hashes. To ensure that will happen, some CAs should use SHA-256 and others SHA-512, so there will and should be no IGTF guidance as to which one to choose.


IPv6 use at the CA end

All CAs should have an IPv6 capable end-point for their CRL (and OCSP responder), preferably BEFORE OCTOBER 1, 2012!

To encourage CAs to enable IPv6 and get the proper DNS records set, monthly reminders will be sent if your CA does not offer the CRL over IPv6 (or lacks the AAAA records). After October 1st, these reminders will come weekly.

Get your DNS servers on IPv6 as well And, yes, I know the IGTF itself does not have that yet,

but I’m looking into alternatives for Enom Inc.


RA MIGRATION AND RPS


RA Practices Profile

'well organised' communities of subscribers which are called 'RAs' in the context of e.g. DoEGrids

could benefit significantly from having their own well-defined 'Registration Practices

Statement' (RPS) AND keeping their own records and vetting data

and gain the ability to 'outlive' their CA issuing providers and even migrate between CAs with only limited impact to the individual subscribers.

and contract issuing CAs in competition However, this is *not* going to result in any change in the IGTF

structure itself, nor in additional 'membership categories' for PMAs. It is the CAs that are anyway responsible for ensuring proper RA practices, and as such they get to defend and present RPS practices. All communication will be and remain through the CAs.


RA migration: the practical use case

In this case, the community RA in NZ actually is well organised and has retained all documentation, so a migration of the entire community to the ASGCCA Catch-All function would sole the problem. The IGTF discussed the options and since the RA has retained all documents and vetting data the existing CA will continue to operate in a 'transitionary' mode, so

there is an authentication point for the RA's subscribers the documentation and vetting processed for the old and new CA are

compatible the RA will transfer audit capability for their documents to the new RA

the users will be allowed to migrate from the old to the new CA without a new F2F vetting step, since the documentation remains available, and through authenticating with the 'old' credentials subscribers that re- apply to the new CAs can link their new request to the original vetting data.

The new CA will issue in its own name space, so the full DN of the subscribers will change. This is, however, well solvable in the VO registration systems today, and common practice.


OCSP – PART II


OCSP conclusions

IGTF CAs SHOULD provide production OCSP responder JAN 1, 2013

To enable this to happen, the following actions will be taken: those that run OCSP responders (either the regular 'heavy' ones or

the precomputer 'light-weight' OCSP responses that can be cahed and served over a CDN) will send some documentation

CABForum will (in about 3+ month) produce two whitepapers on OCSP: one for service operators and one for RP clients

All CAs should start deploying OCSP responders now, and setup a server for that

authorityInfoAccess OCSP endpopint extensions should be included in all EECs issued after Jan 1, 2013

from then on, AIA in client certs will be used, and after 400 days all EECs should have it.


OCSP conclusions

the server(s) running the OCSP responders should be highly available, and have controls around them to make sure they are secure and safe. If you use a signing OCSP responder, it should have an OCSP signer cert which is reasonably short-lived , and preferably hosted on an HSM.

pre-computed responses should be preferred, and can be signed beforehand off the normal issuing CA directly (making them smaller and easier to process) Client will interpret the OCSP responses and do the 'right' thing (known should be equal to 'bad').


But: what to do at the client end?

Experiments by Krysztof Benedycak (quoting from his mail):

“I did a small experiment using all OCSP responders defined in all CA certs from the IGTF distro + one from big guys, i.e. VeriSign. There is only few of them:

http://EVSecure-ocsp.verisign.com -> OK http://ocsp.usertrust.com -> OK https://ocsp.quovadisoffshore.com -> OK http://ocsp.digicert.com -> OK http://ocsp.cesnet-ca.cz/ -> no luck, 4xx HTTP error https://ca.grid.arn.dz:2560 -> no luck, connection timeout

Results: For all that I managed to query and get a positive answer I've used the same settings and get the same results, i.e.:

I've used unsigned request, however signed one was also accepted anonymous TLS in case of https (for quo vadis) nonce extension was not honored, never

it seems that all responders create responses once per day (or so) as I always had "producedAt" several hours in the past and it was constant.”


The current proposal by Krysztof

“Solely basing on this experiment, here are defaults and assumptions that I'm going to implement. Any comments are welcomed …

1.use in request or require response nonce? NO, not supported by servers

2.hash algorithm to be used in requests (for hashing checked cert issuer and key, not the one used for request signing)

fixed to SHA1 do we need to make it configurable? Are there any SHA2 hashes

required/supported? and if the answer is yes: is there any chance that admins will be able to guess a better default value for the hash?

3.server's authentication in case of https responders don't support this at all, i.e. use https for connection encryption only, as it would

be quite hard in general (hen and egg problem) alternatively we can check the responder's SSL certificate simply, by requiring it

to be the same as the certificate of the authority which signed the later received response. But does such effort makes sense?


More from Krysztof ...

4. signing of requests --> no; seems to be ignored by servers

5. client's authentication to the responder in case of https --> as above

6. no other extensions are going to be supported

7. OCSP answer for a particular certificate will be cached -> by default up to 24h -> cache time will be configurable


GFD.125BIS


Grid Certificate Profile Update

Document URL

https://forge.ogf.org/sf/go/doc16402

version 3 with track changes One addition made based on mail from Roberto

Can we sign off on this version? Has anyone looked at it?


Agenda

26rd EUGridPMA meeting10-12 September 2012, Lyon FR

27rd EUGridPMA meetingAbu Dhabi, 14-16 January 2013

28th PMA meetingKyiv, UA, 13-15 May 2013

29th PMA meetingBucharest, RO, 9-11 Sept 2013

eugridpma caops-wg and igtf issues june 2012 delft, nl david groep, nikhef, eugridpma, egi and big...

Documents

implementation of sha

new hash algorithms

crls cas

ca endall cas

road forwardall igtf

based certs

aeagenda26rd eugridpma

ipv6 use