1 / 23

EUGridPMA status and updates David Groep, TAGPMA Ottawa Summit 2006

EUGridPMA status and updates David Groep, TAGPMA Ottawa Summit 2006. Items. EUGridPMA latest overview New CAs and issues emanating from them Classic AP Update proposals Certificate Profile Miscellaneous ‘stuff’. Coverage of the EUGridPMA. Green: Countries with an accredited CA

bette
Download Presentation

EUGridPMA status and updates David Groep, TAGPMA Ottawa Summit 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EUGridPMA status and updatesDavid Groep, TAGPMA Ottawa Summit 2006

  2. Items • EUGridPMA latest overview • New CAs and issues emanating from them • Classic AP Update proposals • Certificate Profile • Miscellaneous ‘stuff’

  3. Coverage of the EUGridPMA Green: Countries with an accredited CA • 23 of 25 EU member states (all except LU, MT) • + AM,CH,HR,IL,IS,NO,PK,RU,TR,“SEE-catch-all” Other Accredited CAs: • DoEGrids (.us) • GridCanada (.ca) • CERN find-your-CA clickable map at http://www.eugridpma.org/members/worldmap/

  4. New applicants and updates New CAs: • CERN-IS • a bit special … • SRCE Croatia • traditional classic CA Upcoming: • Romania (ROSA) CA Modifications: • General trend: move to on-line CA with an off-line root • UKeScience CA • HellasGrid CA • AustrianGrid CA

  5. CERN-IS CA Application • CERN-IS • successor to the current CERN CA • to issue long-lived certificates, but based on identity vetting that is ‘time-shifted’ with respect to the certificate issuance • certificate issuance based on authenticating to the HR database (the CERN identity management system), using two independent credentials • username/password stored in Active Directory; plus • the date of birth stored in the HR database • identity vetting for this HRDB based on periodic (2-yearly) personal appearance in front of the RA office with a passport • same IdM (but just the username/password auth) used to authenticate for financial transations and salary payments;so the CA issuance is marginally stronger than that by requiring a second item, the DoB

  6. CERN-IS Architecture • on-line CA architecture • Windows Server 2003 CA as web front-end (IIS), • HSM on different machine (also 2003 Server) connected to front-end via private, monitored, network Viewgraph: Emanuelle Ormancey, Alberto Pace, CERN-IT/IS

  7. CERN-IS CA Accreditation discussion • The CERN-IS CA is a stretch for the Classic Profile, but with appropriate interpretation of “should”s still ‘kind-of’ fits • issues long-term certs & host certs, so does not make SLCS either • new MICS profile seems a good fit  • discussion on both IdM and technical protection have resulted in (many) proposals for profile changes • technical changes have been implemented to make the process secure and auditable • highly protected online-CA architecture was a hard requirement: • either a dedicated link between web front-end and HSM hosting system • or on the same but, but behind a two-layered firewall with a (monitored!) IDS on the segment • aim was to make sure that, in case of compromise, at least a list of ‘bad’ certs can be made in a reasonably tamper-proof way • specifics proposed in new draft of the Classic Profile • the EUGridPMA agreed in its F2F not to stall the accreditation of this particular CA while we are discussing new profiles

  8. Proposed Changes to the Classic AP • clarify process needed for violating a ‘SHOULD’ • FQDN ownership • add the need to describe how subscriber status changes are communicated to CA/RA • time-separated identity-vetting info. protection/use ** • list approve on-line CA architectures • the ‘tamper-proof log’ may be still impossible to implement, but a near-tamper proof log may be possible • refer to cert profile guidelines • clarify due-diligence for end-entities • take a string password • initiating revocation in a timely fashion see http://www.eugridpma.org/temporary/ for the drafts

  9. Classic AP Update: SHOULD • Latest proposed text (1 Introduction)

  10. Classic AP Update: FQDN ownership • Latest proposed text (3.1 Identity Vetting) • Move the burden of description to the CP/CPS • per-CA implementation should be reviewed for adequacy by the PMA at accreditation time

  11. Classic AP Update: subscriber status changes • Latest proposed text (3.1 Identity Vetting) • Intended to address periodic (yearly) checking by the RA whether the subscriber data are still correct. In case of SLCS or MICS this is likely done anyway, but in the classic case, contact between subscriber and CA/RA may be scarce • Leave precise definition out, but require description of the process in the CP/CPS • e.g. asking the RA at the yearly re-keying time whether he/she still knows about the subscriber…

  12. Classic AP Update: identity magament systems for time-shifted vetting operation ** • Latest proposed text (3.1 Identity Vetting) • text may be (more!) relevant to the proposed MICS profile • key element: IdM should be a highly trusted one at the organisation, and appropriately managed and kept up-to-date • face-to-face requirement is there, and for a reason!

  13. Classic AP Update: CSR linkage • Latest proposed text (3.1 Identity Vetting) • this text might have prevent the repeated discussion regarding ‘weakly-linked’ CSRs, where no shared data links the electronic CSR to the actual identity vetting

  14. Classic AP Update: CA Architectures • Latest proposed text (4 Operational Requirements) • distinguish clearly between on- and off-line CAs, and make clear that both are allowed, definition of terms • needed to then describe pre-validated on-line architectures …

  15. Classic AP Update: on-line CAs • Latest proposed text (4 Operational Requirements) • HSM FIPS 140-2 level 3 operation (but certification statement accompanying the HSM may be level-2) • make clear that the highly-monitored environment must be reviewed and approved by the PMA • two pre-selected environments mentioned explicitly

  16. Classic AP Update: on-line CA architectures • Latest proposed text (4 Operational Requirements) • Model A: HSM on a separate machine, not the (web) front-end, linked via a dedicated monitored network that only carries the signing requests (NIIF, CERN-IS) • Model B: HSM on the front-end, but the front-end isolated from the non-exclusive network by two firewalls, and the intermediate network link actively monitored with IDS capability (DoEGrids) • or come up with a new architecture, but you have some convincing of a PMA to do for the coming time …

  17. Classic AP Update: tamper-proof log? • Latest proposed text (4 Operational Requirements) • intent of this proposal • there may (and likely will be) a compromise • if you log directly from the HSM to paper or WORM, at least you know which of the issued EE certs were involved in the compromise • this is also the reason for the complicated on-line architectures • (invisible) monitoring of the link between web front-end and signing system with HSM, capturing all signing requests sent across accomplished the same thing(i.e. using a fibre splitter at layer-1 and capturing all traffic) • that’s why the signing box should not be directly on a user-accessible network

  18. Classic AP Update: Certificate Profile • Latest proposed text (4.3 Certificate and CRL Profile) • as we learned more about certs and our middleware, we now know better what to do and what to avoid • making ‘useless’ EE certs • does no good to no-one • causes problems in the CA distribution • overloads the support channels for both (grid) projects and the PMAs • guidance document draft available (target audience: IGTF and CAOPS-WG)

  19. Classic AP Update: Subscribers • Latest proposed text (9.1 Due diligence for EE) • incorporates some text moved from 4.4 (Revocation) • is not enforcible, but it’s also a pity to loose this guidance text

  20. Certificate Profile • See separate presentation

  21. Miscellaneous Services • OID Registry for the IGTF on the webhttp://www.eugridpma.org/objectid/ • Find-Your-CA clickable maphttp://www.eugridpma.org/members/worldmap/ • Subject Locatorhttp://www.eugridpma.org/showca • Member statushttp://www.eugridpma.org/members/members-full • CA statushttp://signet-ca.ijs.si/nagios/ (user guest:guest) • Wikihttps://grid.ie/eugridpma/wiki/ (register with David OC)

  22. Other Items • CA monitoring • still a large number of ‘almost expiring’ CRLs • Reminders get sent, but I still have to send too many … • eduroam™ interoperation • use EAP-TLS 802.1X authentication using your IGTF certificate • eduroam test domain “hellasgrid.gr” • as matching is on CN only (a FreeRadius limitation that is already being addressed), registration is necessary • pilot-service only • windows XP built-in 802.1x client violates policy • OIDs • prepare to add additional policy OIDs to EE certificates, indicating, e.g., IGTF profiles or 1SCPs

  23. Q?

More Related