What certificates are typically used for

1. What certificates are typically used for • Secure channel TLS / SSL for web servers • Sign emails • Authentication • Code signing • Encrypt files (EFS in Windows/2000) • IPsec (encrypt network layer) Per HAGEN, CERN IT, Internet Services

2. Recap how it works ... • Certificates are based upon PK (public key) technology • A pair of keys are linked together with an asymmetric algorithm (one-way). • The user requests a certificate via a local application (example: web browser). • At this point of time a key-pair is generated. • The public key is part of the certificate, while the private key is never exposed to somebody else (not even local administrators). • Asymmetric keys are only used for small amount of data (signing, protecting private keys). Symmetric keys (like 3DES) are used for bulk transfer of data. Per HAGEN, CERN IT, Internet Services

3. … how it works (2) … • The certificate is signed by a certificate authority (CA) • The CA checks that the certificate user indeed is the one he claims to be in the certificate request. • The CA signing is recursively based upon the usage of certifcates. The root CA certificate is self-signed. • The CA is therefore a critical part of the system and must operate in a secure and predictable way according to some policy to achieve confidence. Per HAGEN, CERN IT, Internet Services

4. CA hierarchy for HEP ? • Having one CA hierarchy for HEP does not seem to solve any real problem (although it looks neater) • When validating a certificate, all certificates including root CA must be accessible • Issuing and validation of certificates must be done where user registration is • To which CERN account should a SLAC user certificate map? Is there a need for a HEP-wide user-registration? Or special “guest” accounts? Per HAGEN, CERN IT, Internet Services

5. Improve HEP interop • Pre-install root certificates into user apps • Configure LDAP directory services into user apps (where public keys are advertised) • That is, my email client should by default recognise all HEP sites Per HAGEN, CERN IT, Internet Services

6. Security of CA • Must minimise risk of CA private key being compromised • Best option is to have off-line signing CA • Microsoft recommends using CA hierarchy where root CA is off-line and signing CA MUST be on-line • In addition, I believe using a smart card CSP for the signing CA would help (should be impossible to extract private key into server computer) • What if hardware failure? Too slow in W2K environment? Per HAGEN, CERN IT, Internet Services

7. Mapping personal certs into accounts • A personal certificate must map “one-one” into an account for the sake of authentication • In some systems, mapping are based upon X.509 naming attributes from the Subject field • Example: Microsoft issues certificate as CN=Full Name (account) • The account is local to the issuing domain Per HAGEN, CERN IT, Internet Services

8. Storage of private key • The problem of having the user to manage the private key is a treat (user support, key loss or compromise) • Windows offers the CryptoAPI + Protected Storage which saves private keys (encrypted) in the Protected Storage, which again is part of the roaming user profile. • MS apps like IE and Outlook take advantage of this, whilstNetscape which is optimised for cross-platform saves private keys encrypted into the configuration directory • Thus, user who mix applications or platforms must manually import / export private keys via PFX files. Per HAGEN, CERN IT, Internet Services

9. Smart card readers? • I have no real experience with this, just some opinions which need validation! • Price is not a problem (~ floppy drive) • Cannot read private key out of card, so cannot export private key to another environment • Currently issues with cross-platform driver / application support (ok if only Windows/2000!) • Should wait to see if it “takes off” • Will Internet shopping have impact? • Intend to evaluate smart cards on a small scale Per HAGEN, CERN IT, Internet Services