-
1
6 Public Key Infrastructure
6.1 Certificates
• Structure of an X.509 certificate
• X.500 Distinguished Name and X.509v3
subjectAlternativeName
• Certificate formats (DER, PEM, PKCS #12)
6.2 Certificate Authorities
• PGP web of trust vs. X.509 hierarchical trust chain
• Certificate registration
• Certificate classes
• Trustedroot certification authorities
6.3 Certificate Enrollment
• SPKAC enrollment via browser ( tag)
• PKCS #10 certification request
• Simple certificate enrollment protocol (SCEP)
6.4 Certificate Revocation
• Certificate revocation list (CRL)
• CRL deployment schemes
• Delta CRLs
• Online certificate status protocol (OCSP)
6.5 Certificate Policies
• basicConstraints extension
• keyUsage extension
• extendedKeyUsage extension
-
2
-
3
Structure of an X.509 Certificate
• An X.509v3 certificate consists of three parts:
• A certificate body containing
• a version number (currently v3, v2 and v1 are also
possible)
• a unique serial number assigned by the responsible CA
• a declaration of the signature algorithm to be used to sign
the certificate
• the distinguished name of the CA that issued and signed the
certificate
• the validity period (not valid before / not valid after)
• the subject (user) distinguished name
• the public key of the subject (user)
• any number of optional v2 or v3 extensions, some of them being
very important
• A definition of the signature algorithm used by the CA to sign
the certificate
• The signature guaranteeing the authenticity of the
certificate, consisting of the
hashed certificate body encrypted by the CA‘s private key.
-
4
-
5
-
6
-
7
-
8
Web of Trust
• One possible method of establishing trust in a user‘s public
key is the web of trust
approach employed by the popular Pretty Good Privacy (PGP) mail
encryption and
authentication package. It is typical for closely-knit
communities like e.g. people
working on a large software project or special interest groups
that a personal link can
be established between any two people in the community using a
relatively small
number of „hops“ on the basis of common friends.
Can Carol trust Alice ?
• Can Carol trust Alice if she has never met her before?
Probably yes, because Alice
has a good friend called Bob, who works together with Dave, who
in turn is a friend of
Carol‘s. So using three „hops“ a link between Carol and Alice
can be established.
How is the „Web of Trust“ principle applied to public key
certificates?
• In a web of trust every participant asks her friends to sign
the hash of her
user certificate containing the user ID (e.g. an e-mail address)
and the public key.
• So when Carol receives an e-mail signed by Alice, she gets
Alice‘s certificate from a
public directory and sees that it has been signed by Bob. Next
she fetches Bob‘s
certificate and sees that it has been signed by Dave. Again she
asks for Dave‘s
certificate and sees that she herself has signed Dave‘s
certificate. The chain has
now been completed and trust has been established.
Scalability of the Web of Trust
• As mentioned above, a web of trust approach is appropriate for
relatively compact
user communities. The method does not scale very well when
millions of people must
be authenticated. The average number of hops rises and with them
the number of
certificate look-up. Also the longer a trust chain gets, the
less trustworthy it becomes.
Don‘t trust authorities!
• The big advantage of a web of trust among peers is that no
central authority is
required that could become corrupted,.
-
9
Hierarchical Trust Chains
• At the moment it looks like if a second trust model based on
certification authorities
and hierarchical trust chains is going to establish itself for
large scale certificate
usage and deployment.
Root Certification Authorities - Root CA
• At the top of the hierachical trust chain are a few Root
Certification Authorities which
are well known and which intrinsically must be trusted. Each
Root CA publishes a
Certifcate Practice Statement (CPS) defining on what policies
user or server
certificates are issued, how they are managed and how they can
be revoked.
• Examples of well-known Root CAs are Verisign, RSA, Baltimore,
Entrust, Thawte,
Deutsche Telekom.
Intermediate Certification Authorities - Intermediate CA
• Root CAs can directly issue user certificates. This is usually
done in the case of
private individuals who apply directly for a certificate.
• For large or medium organisations it is much more flexible to
set up a certification
authority of their own, so that they can issue and revoke
certificates for their staff
themselves. The certificate of this so called Intermediate
Certification Authority
which is used to sign staff certificates, is in turn issued and
signed by a generally
trusted Root CA.
• In principle an arbitrary number of hierarchy levels could be
implemented, but
usually there are not more than two or three hops from a user
certificate to root CA
certificate at the top of the trust chain.
-
10
-
11
-
12
-
13
-
14
Netscape‘s tag
• Netscape, Mozilla and Firefox support a tag which when placed
in a form
prompts the browser to generate a 1024 bit (medium grade) or
2048 bit (high grade)
RSA key pair and store it in the browser‘s internal security
database.
• A „Signed Public Key and Challenge“ (SPKAC) is sent via a POST
request to the
certification authority‘s HTTP server. When the signed X.509
certificate is ready,
it can be imported into the browser via a HTTP request.
-
15
Structure of PKCS #10 Certification Request
• A PKCS #10 certification request consists of three parts:
• A certificationRequestInfo object containing
• a version number (currently v1)
• the subject (user) distinguished name
• the public key of the subject (user)
• an optional extensionReq attribute defining any number of
X509.v3 extensions
that the requestor wants to be included in the certificate.
• an challengePassword attribute containing a secret challenge
password that can be
used by the requestor to revoke the certificate with the CA.
• A definition of the signature algorithm used by requestor to
sign the request
• The signature guaranteeing the authenticity of the request,
consisting of the
hashed certificationRequestInfo object encrypted by the
requestor‘s private key.
-
16
Cisco‘s Simple Certificate Enrollment Protocol
•
http://www.ietf.org/internet-drafts/draft-nourse-scep-11.txt
• The client (requestor) creates an RSA key pair and forms a
PKCS #10 request.
• Signed and encrypted PKCS #7 envelopes are used to transport
SCEP requests
and replies securely.
• Authentication of the client is done automatically based on a
pre-shared secrets
or manually some other means of communication (e.g. spelling the
key‘s fingerprint
over the phone).
-
17
-
18
Structure of an X.509 CRL
• An X.509v1 or v2 CRL consists of three parts:
• A CRL body containing
• a version number (v1 and v2)
• a declaration of the signature algorithm to be used to sign
the CRL
• the distinguished name of the CA that issued and signed the
CRL
• the date the CRL was created
• the date the next CRL update will be released
• a list of revoked certificates
• the serial number of the revoked certificate
• the date the certificate was revoked
• optional crlEntryExtensions, e.g. allowing to specify a
revocation reason
• A definition of the signature algorithm used by the CA to sign
the CRL
• The signature guaranteeing the authenticity of the CRL,
consisting of the
hashed certificate body encrypted by the CA‘s private key.
-
19
-
20
-
21
-
22
Online Certificate Status Protocol (OCSP)
• The OCSP protocol is defined by RFC 2560.
• OCSP is based on a request/reply scheme and uses HTTP as a
transport medium.
OCSP servers
• OCSP servers deliver on-line certificate status information on
behalf of one or several certification authorities (CAs).
• The certificate status information on the OCSP servers must be
frequently updated by the CA, usually by sending a certificate
revocation list (CRL) signed by the CA or by secured access to the
CA's master data base.
Finding OCSP servers
• A convenient means to locate OCSP servers is to put the
following X.509v.3 extension into the end entity certificates:
authorityInfoAccess =
OCSP;URI:http://ocsp.strongswan.org:8880
OCSP servers with self-signed certificates
• As part of an public-key based authentication protocol Antje
sends her certificate to Bob. After successful verification of the
CA's signature Bob sends a request to the OCSP server, asking for
the actual status of Antje's certificate. The certificate in
question is unambiguously identfied by the name of the issuing CA
and the unique serial number. In order to control the access to the
OCSP server, the OCSP request can by optionally signed by the
requestor.
• The OCSP response returns the certificate status which can
take on one of the following values: good, revoked or unknown.
• The OCSP response is signed by the OCSP server. Often a
self-signed OCSP signing certificate is used, that in order to
establish trust must be distributed to clients in a secure way and
stored locally.
-
23
OCSP servers with delegated trust
• A certification authority (CA) can delegate the revocation
service to an OCSP server
by issuing a special OCSP signing certificate for this server.
An OCSP signing
certificate contains the following X.509v3 extension
extendedKeyUsage = OCSPSigner
Because the OCSP certificate is signed by the CA, any client
accepting this CA
will put automatically trust into the OCSP certificate. And due
to the embedded
OCSPSigner extendedKeyUsage field, a client will accept that the
OCSP server
sending this certificate is authorized to offer revocation
services for the CA in question.
• Usually an OCSP server with delegated trust automatically
deploys its certificate by
appending it to the OCSP reply.
-
24
-
25
-
26
-
27
-
28