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