eugridpma status and updates david groep, tagpma ottawa summit 2006

EUGridPMA status and updates

David Groep, TAGPMA Ottawa Summit 2006

EUGridPMA Status Update, TAGPMA Ottawa 2006 - 2David Groep – [email protected]

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 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/


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


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


CERN-IS Architecture

Viewgraph: Emanuelle Ormancey,

Alberto Pace, CERN-IT/IS

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


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


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


Classic AP Update: SHOULD

Latest proposed text (1 Introduction)


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


Classic AP Update: subscriber status changes


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…


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!


Classic AP Update: CSR linkage


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


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 …


Classic AP Update: on-line CAs


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


Classic AP Update: on-line CA architectures


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 …


Classic AP Update: tamper-proof log?


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


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)


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


Certificate Profile

See separate presentation


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)


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

eugridpma status and updates david groep, tagpma ottawa summit 2006

Documents