Upload
kristina-hester-hunter
View
220
Download
0
Tags:
Embed Size (px)
Citation preview
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
APGridPMA Taipei 2012 meeting - 3David Groep – [email protected]
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
APGridPMA Taipei 2012 meeting - 4David Groep – [email protected]
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
APGridPMA Taipei 2012 meeting - 5David Groep – [email protected]
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
APGridPMA Taipei 2012 meeting - 6David Groep – [email protected]
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
APGridPMA Taipei 2012 meeting - 7David Groep – [email protected]
ToC for https://www.eugridpma.org/review/sha1
APGridPMA Taipei 2012 meeting - 8David Groep – [email protected]
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.
APGridPMA Taipei 2012 meeting - 9David Groep – [email protected]
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.
APGridPMA Taipei 2012 meeting - 10David Groep – [email protected]
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.
APGridPMA Taipei 2012 meeting - 11David Groep – [email protected]
RA MIGRATION AND RPS
APGridPMA Taipei 2012 meeting - 12David Groep – [email protected]
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.
APGridPMA Taipei 2012 meeting - 13David Groep – [email protected]
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.
APGridPMA Taipei 2012 meeting - 14David Groep – [email protected]
OCSP – PART II
APGridPMA Taipei 2012 meeting - 15David Groep – [email protected]
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.
APGridPMA Taipei 2012 meeting - 16David Groep – [email protected]
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').
APGridPMA Taipei 2012 meeting - 17David Groep – [email protected]
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.”
APGridPMA Taipei 2012 meeting - 18David Groep – [email protected]
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?
APGridPMA Taipei 2012 meeting - 19David Groep – [email protected]
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
APGridPMA Taipei 2012 meeting - 20David Groep – [email protected]
GFD.125BIS
APGridPMA Taipei 2012 meeting - 21David Groep – [email protected]
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?
APGridPMA Taipei 2012 meeting - 22David Groep – [email protected]
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