EUGridPMA status and updates David Groep, GGF18

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
  shoulds still kind-of fits
• issues long-term certs host certs, so does not
  make SLCS either
• new MICS profile seems a good fit
• see Tonys 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)
• thats 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 its also a pity to loose
  this guidance text

18
Profile Cleanup

• Classic
• MICS
• SLCS
• Aesthetically, a matrix of
• identity vetting requirements
• physical

19

• Q?