Naming and certificates
Identifiers correspond to principals– Must uniquely identify the principal– (Real) names alone are not enough!
E.g., X.509 certificates
Distinguished names identify a principal– Series of fields, each with key and value
• E.g. /O=University of Maryland/OU=College Park/OU=Computer Science/CN=J. Katz
• “O” - organization; “OU” - organizational unit; “CN” = common name
Certificates
Certification authorities vouch for the identity of the principal to whom a certificate is issued
CA authentication policy determines the level of authentication needed to identify the principal before the certificate is issued
CA issuance policy describes the principals to whom the CA will issue certificates
A single CA can “act” as multiple CAs, each with their own policies…
Example: Verisign (1996)
Three levels of authentication– Verification of valid email address– Verification of name/address– Background check
Different authentication policies; same issuance policy (individuals)
Another issuance policy was for issuing certificates to web servers
Certificate infrastructure
Hierarchical structure of CAs – Nodes correspond to CAs– Children of a CA are constrained by the
policies of their parents
Conflicts
What if a single CA issues certificates under different policies?
What if a CA issues a certificate tied to an email address, but the owner of this address changes?
What if two CAs have the same dist. name?
What if two different CAs issue certificates for the same distinguished name (to different principals)?
Easy solution
For organizational certificates, the last type of conflict can be prevented by incorporating CA name into distinguished name
Does not solve the other problems, in general…
Handling conflicts Conflict detection database…
Before a PCA may issue a certificate to a CA, it checks for a conflict in the database– Sends a hash of the CAs dist. name, the CAs
public key, and the dist. name of the PCA
If first two fields conflict with a database entry, the two PCAs must resolve the conflict
Note that this only ensures uniqueness of (DN, PK) pairs
Handling conflicts (in action)
Two CAs with same dist. name?– Will have different public keys…
Same CA with two different policies?– Will use different public keys for each
What does identity mean?
Ultimately, identity is proved using physical means– Driver’s license, fingerprints, etc.
If these are compromised, then certificates are irrelevant!– Certificate is just a binding between external
identity and (DN, PK)
PKI components
CAs…
Repository for retrieving certificates
Revocation method
Method for evaluating a chain based on known “trust anchors”
(Orthogonal issue: how are the keys of the trust anchors distributed?)
Some terminology
If A signs a certificate for B’s name/key, then A is the issuer and B is the subject
If A wants to find a path to B’s key, then B is the target and A is the verifier
A trust anchor is a public key that the verifier trusts to sign certificates (typically known to the verifier through some out-of-band mechanism)
Trust models
Define how a verifier chooses trust anchors, and what certification paths create a legal chain from trust anchor to target
Trust
How much to trust a particular certificate?
Based on:– CA authentication policy– Rigor with which policy is followed– Assumptions inherent in the policy
Example…
Certificate issued based on a passport
Assumptions:– Passport not forged– Passport issued to the right person– Person presenting passport is the right person– CA actually checked the passport when issuing
the certificate
Monopoly model
A single CA certifies everyone
Drawbacks– Single point of failure– Not very convenient– Complete monopoly…
Pure monopoly not used in practice
Monopoly + RAs…
The CA can appoint RAs
RAs check identities and vouch for keys, but the CA does all actual signing– Certainly more convenient– Not necessarily more secure
(Note: RAs can be integrated into other models as well)
Monopoly + delegated CAs
As seen in class last time…
CA can issue certificates to other CAs– Vouch for their key and also their
trustworthiness as a CA– Delegated CA can sign certificates itself
(Note: delegation can be incorporated into other models as well)
Oligarchy
Multiple trust anchors– E.g., multiple keys pre-configured in software– User can add/remove trust anchors
Issues:– Less resistant to compromise!– Who says the user trusts the trust anchors?– Can user be tricked into adding or using a
“bad” anchor?
Anarchy model
Users responsible for defining the trust anchors they want to use
Drawbacks– Scalability?– How much trust to place in a certificate chain