6 Public Key Infrastructure 6.1 Certificates Structure of an X.509 certificate X.500 Distinguished Name and X.509v3 subjectalternativename

Transcription

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 (<KEYGEN> 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 1

2 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. 3

4 4

5 5

6 6

7 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 address) and the public key. So when Carol receives an 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,. 8

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. 9

10 10

11 11

12 12

13 13

14 Netscape s <KEYGEN> tag Netscape, Mozilla and Firefox support a <KEYGEN> 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. 14

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. 15

16 Cisco s Simple Certificate Enrollment Protocol 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). 16

17 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. 18

19 19

20 20

21 21

22 Online Certificate Status Protocol (OCSP) The OCSP protocol is defined by RFC 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: 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. 22

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. 23

24 24

25 25

26 26

27 27

28 28