Chapter 9ii: Public Key Infrastructure Flashcards
- X.509 is a ITU standard that …
- X.509 is part of the X.500 family of standards (ITU)
- X.500 vision: global directory to store and retrieve entity information
- All information stored in a tree → strict naming discipline
- X.509 is the certificate standard in X.500
- X.500 never saw much deployment
- The X.509 certificate standard was reused by the IETF to create a certification standard, in particular …
- CAs and subCAs responsible for …
- The concept of a tree was given up → any CA can…
defines the format of public key certificates
to link domain names to public keys
controlling access to sub-trees
issue certificates for any domain
X.509
X.509 and SSL/TLS
SSL/TLS include certificate-based authentication
* Original design of SSL by Netscape (Mozilla!)
* Goal: …
* The attack model in mind was more a criminal, less a state-level attacker
protect sensitive information like cookies, user input (e.g., credit cards)
Fill in the blanks.
X.509: Multiple Domain Names and “Wildcards” in Certificates
- Often, a certificate includes only one domain name, called common name (CN), e.g., net.in.tum.de
- The CN is …
- Optionally, it is possible to …:
stated in the subject field of the certificate
create certificates that are valid for multiple (sub-)domains
- This means, the same certificate (and asymmetric key pair) can be used by a server to serve multiple web- sites/services
- E.g.: the server uses the same cert/key pair for net.in.tum.de and webmail.net.in.tum.de
- Such alternative (sub-)domain names are listed (usually including the CN) in subject alternative name (SAN)
fields
X.509: Multiple Domain Names and “Wildcards” in Certificates
Benefits and Drawbacks?
- Benefit: simplified configuration, reduced workload, and cost for certification
- Drawback: private key leaks → affects multiple (sub-)domains/services (central point of failure/error)
R: Root certificates
Root stores: contains certificates of trusted Root CAs–> Explain.
Root store processes–> Explain.
Root stores: contains certificates of trusted Root CAs
* Root certificates are “self-signed”
* Every application that uses X.509 has to have a root store,
i.e. a set of certificates of “trusted” CA (trusted to issue certificates to the correct entities)
* Operating Systems have root stores: Windows, Apple, Linux
* Browsers use root stores: Mozilla ships their own, IE uses Windows’ root store, etc.
Root store processes
* Every root store vendor has their own process to determine if a CA is added or not
* A CA’s Certification Policy Statements (CPS) are assessed
* Mozilla: open discussion forum (but very few participants)
* Commercial vendors (Microsoft, Apple): little to no openness
Intermediate Certificates
Why do we need intermediate certificates?
Intermediate certs: part of a certificate chain, but neither a root certificate nor an end-entity certificate.
- Protect your main root certificate:
- To delegate signing authority to another organization: sub-CA
Hazards of Sub-CA/Intermediate Certificates
Sub-CA/intermediate certs have the same signing authority as Root CA/root certs:
SSL proxies
Cross Signing: A (Sub-)CA signs a root or signing certificate of another (Sub-)CA
Hazards of Sub-CA/Intermediate Certificates
Sub-CA/intermediate certs have the same signing authority as Root CA/root certs: explain.
- Example: Russian Sub-CA might sign certificate of Ukrainian web site
- DNS restrictions (name spaces a CA is responsible for/allowed to sign) are in the standard
- The restriction must be supported on client-side
- This feature is little used
Hazards of Sub-CA/Intermediate Certificates
SSL proxies
- SSL proxies allow …
- Using SSL proxies, …
- Used by companies in order to ….
- Requires that SSL Proxy can ….
- CAs have issued intermediate CA certificates for ….
- Worst: the holder of the sub-CA is …
- Since outing of first such CA, Mozilla requires …
the transparent rewriting of certificate chains – a classic Man-in-the-middle attack
end-to-end protected traffic can be monitored
avert industrial espionage, etc. (but also by state level attackers)
“on the fly” issue valid (but actually forged) certificates of visited websites
companies that operate a SSL proxy
suddenly as powerful as all CAs in the root store
practice to be disclosed, and stopped
Hazards of Sub-CA/Intermediate Certificates
Cross Signing: A (Sub-)CA signs a root or signing certificate of another (Sub-)CA
- Cross signing is able to subvert control of the root store vendor: exemplify.
- In a business-to-business model, this makes sense:
why?
- A special case of intermediate cert
- Example: Entrust (US CA) has signed CNNIC (Chinese CA) long before CNNIC became part of the root store in Mozilla
- CNNIC-issued certificates suddenly became valid
- For the WWW, it completely breaks the root store model
- Two businesses wishing to cooperate cross-sign each other
- Makes it easy to design business processes that access each others’ resources via SSL/TLS
Browser (Client) Root Stores
Remember:
* Your browser or your OS chooses the ‘trusted CAs’. Not you.
* All CAs have equal signing authority (there are efforts to change this)
* Any CA may issue a certificate for any domain.
* DNS path restrictions are a possibility; must be set by the CA in their signing cert
* A globally operating CA cannot feasibly set such restrictions in their root cert
The weakest CA determines the strength of the whole PKI. This is also true if the CA is a sub-CA.
