1 / 19

EUGridPMA status and updates David Groep, GGF18

EUGridPMA status and updates David Groep, GGF18. Items. EUGridPMA latest overview New CAs and issues emanating from them Classic AP Update proposals. Coverage of the EUGridPMA. Green: Countries with an accredited CA 23 of 25 EU member states (all except LU, MT)

kane-burton
Download Presentation

EUGridPMA status and updates David Groep, GGF18

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, GGF18

  2. Items • EUGridPMA latest overview • New CAs and issues emanating from them • Classic AP Update proposals

  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 Recently approved CAs: • SRCE Croatia • traditional classic CA Almost there • CERN-IS Upcoming: • Romania (ROSA) CA • EAGIS (Serbia) • ACAD.BG (Bulgaria) Modifications: • General trend: move to on-line CA with an off-line root • UKeScience CA • HellasGrid CA • AustrianGrid CA

  5. 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 • see Tony’s upcoming presentation • 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

  6. 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

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

  8. 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

  9. 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…

  10. 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! MOVE TO MICS

  11. 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

  12. 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 …

  13. 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

  14. 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 …

  15. 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

  16. 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)

  17. 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

  18. Profile Cleanup • Classic • MICS • SLCS • Aesthetically, a ‘matrix’ of • identity vetting requirements • physical

  19. Q?

More Related