How does SSL/TLS PKI work?

Question

We have lots of questions that address portions of SSL/TLS as it relates to PKI, but none of them seem to bring everything together. A canonical answer that we can point people to I think would be quite helpful.

• We have How Does SSL/TLS Work? which will give a nice basis, and does contain a section on client certificates. It should be read before trying to understand PKI.
• We have A Different Approach to PKI which explains some problems with the overall ideas of PKI.
• There is How does SSL client authentication work?, which is a fairly terrible question and answer. Easy explanation of SSL client certificates for a developer is a bit better, but leaves something to be desired.
• There are quite a few question and answers on actually implementing a PKI, but that's a bit out of the scope of this question.

I think the main questions to be answered that seem to be the source of some confusion among posters (All with respect to SSL/TLS):

1. What is the difference between Public Key Infrastructure and Public Key Cryptography? How are they related?
2. What is the main use case for PKI?
3. How are client certificates used in PKI?
4. What is a Certificate Authority's role in PKI?

Answer 1

Public Key Cryptography designates the class of cryptographic algorithms that includes asymmetric encryption (and its cousin key exchange) and digital signatures. In these algorithms, there are two operations that correspond to each other (encrypt -> decrypt, or sign -> verify) with the characteristic that one of the operations can be done by everybody while the other is mathematically restricted to the owner of a specific secret. The public operation (encrypting a message, verifying a signature) uses a public parameter called a public key; the corresponding private operation (decrypting that which was encrypted, signing that which can be verified) uses a corresponding private parameter called a private key. The public and private key come from a common underlying mathematical object, and are called together a public/private key pair. The magic of asymmetric cryptography is that while the public and private parts of a key pair correspond to each other, the public part can be made, indeed, public, and this does not reveal the private part. A private key can be computed from a public key only through a computation that is way too expensive to be envisioned with existing technology.

To make the story short, if you know the public key of some entity (a server, a human user...) then you can establish a secured data tunnel with that entity (e.g. with SSL/TLS in a connected context, or encrypting emails with S/MIME).

The problem, now, is one of key distribution. When you want to connect to a server called www.example.com, how do you make sure that the public key you are about to use really belongs to that server ? By "belong", we mean that the corresponding private key is under control of that server (and nobody else).

Public Key Infrastructures are a solution for that problem. Basically:

• The goal of a PKI is to provide to users some verifiable guarantee as to the ownership of public keys.
• The means of a PKI are digital signatures.

In that sense, a PKI is a support system for usage of public key cryptography, and it itself uses public key cryptography.

The core concept of a PKI is that of a certificate. A certificate contains an identity (say, a server name) and a public key, which is purported to belong to the designated entity (that named server). The whole is signed by a Certification Authority. The CA is supposed to "make sure" in some way that the public key is really owned by the named entity, and then issues (i.e. signs) the certificate; the CA also has its own public/private key pair. That way, users (say, Web browsers) that see the certificate and know the CA public key can verify the signature on the certificate, thus gain confidence in the certificate contents, and that way learn the mapping between the designated entity (the server whose name is in the certificate) and its public key.

Take five minutes to grasp the fine details of that mechanism. A signature, by itself, does not make something trustworthy. When a message M is signed and the signature is successfully verified with public key K_p, then cryptography tells you that the message M is exactly as it was, down to the last bit, when the owner of the corresponding private key K_s computed that signature. This does not automatically tell you that the contents of M are true. What the certificate does is that it moves the key distribution problem: initially your problem was that of knowing the server's public key; now it is one of knowing the CA's public key, with the additional issue that you also have to trust that CA.

How can PKI help, then ? The important point is about numbers. A given CA may issue certificates for millions of servers. Thus, by action of the CA, the key distribution problem has been modified in two ways:

• From "knowing the public keys of hundreds of millions of server certificates", it has been reduced to "knowing the public keys of a thousand or so of CA".

• Conversely, an additional trust requirement has arisen: you not only need to know the CA keys, but also you need to trust them: the CA must be honest (it won't knowingly sign a certificate with a wrong name/key association) and also competent (it won't unknowingly sign a certificate with a fake name/key association).

The PKI becomes a true infrastructure when recursion is applied: the public keys of CA are themselves stored in certificates signed by some über-CA. This further reduces the number of keys that need to be known a priori by users; and this also increases the trust issue. Indeed, if CA2 signs a certificate for CA1, and CA1 signs a certificate for server S, then the end user who wants to validate that server S must trust CA2 for being honest, and competent, and also for somehow taking care not to issue a certificate to incompetent or dishonest CA. Here:

• CA1 says: "the public key of server S is xxx". CA1 does not say "server S is honest and trustworthy".
• CA2 says: "the public key of CA1 is yyy AND that CA is trustworthy".

If you iterate the process you end up with a handful of root CA (called "trust anchors" in X.509 terminology) that are known a priori by end users (they are included in your OS / browser), and that are considered trustworthy at all meta-levels. I.e. we trust a root CA for properly identifying intermediate CA and for being able to verify their trustworthiness, including their ability to themselves delegate such trustworthiness.

Whether the hundred or so of root CA that Microsoft found fit to include by default in Windows are that much trustworthy is an open question. The whole PKI structure holds due to the following characteristics:

• PKI depth is limited. A certificate chain from a root CA down to an SSL server certificate will include 3 or 4 certificates at most.

• CA are very jealous of their power and won't issue certificates to just any wannabe intermediate CA. Whether that "CA power" is delegated is specified in the certificate. When a CA issues a certificate to a sub-CA, with that specific mark, it does so only within a heavy context (contracts, insurances, audits, and lots of dollars). Ultimately, trust is ensured through fear. Offending CA are severely punished.

• Nobody really has interest in breaking the system, since there is no readily available substitute.

Note that, down the chain, the server S is verified to really own a specific public key, but nobody says that the server is honest. When you connect to https://www.wewillgraballyourmoney.com/ and see the iconic green padlock, the whole PKI guarantees you that you are really talking to that specific server; it does not tell you that sending them your credit card number would be a good idea.

Moreover, all of this is association between the server name as it appears in the target URL and a public key. This does not extend to the name intended by the user, as that name lives only in the user's brain. If the user wants to connect to www.paypal.com but really follows a URL to www.paaypaal.com, then the PKI and the browser will in no way be able to notice that the user really wanted to talk to PayPal, and not another server with a roughly similar (but not identical) name.

---

The main use case for a PKI is distributing public keys for lots of entities. In the case of Web browsers and SSL, the browser user must be able to check that the server he tries to talk to is indeed the one he believes it to be; this must work for hundreds of millions of servers, some of which having come to existence after the browser was written and deployed. Reducing that problem to knowing a hundred root CA keys makes it manageable, since one can indeed include a hundred public keys in a Web browser (that's a million times easier than including a hundred million public keys in a Web browser).

Client certificates are a SSL-specific feature. In all of the above we talked about a SSL client (Web browser) trying to authenticate a SSL server (Web server with HTTPS). SSL additionally supports the other direction: a SSL server who wants to make sure that it talks to a specific, named client. The same mechanism can be used, with certificates.

An important point to notice is that the server certificate and the client certificate live in different worlds. The server certificate is validated by the client. The client certificate is validated by the server. Both validations are independent of each other; they are performed by distinct entities, and may use distinct root CA.

The main reason why SSL servers have certificates is because clients cannot possibly know beforehand the public keys of all servers: there are too many of them, and new ones are created with every passing minute. On the other hand, when a server wants to authenticate a client, this is because that client is a registered user. Usually, servers know all their users, which is why most can use a simpler password-based authentication mechanism. SSL client certificates are thus rather rare in practice, because the main advantage of certificates (authenticating entities without prior knowledge) is not a feature that most servers want.

Answer 2

What is the difference between Public Key Infrastructure and Public Key Cryptography? How are they related?

I think the difference between Public-key infrastructure and Public-key cryptography is pretty clear from their Wikipedia definitions (quoted after the tldr). TLDR: Public key cryptography is another name for asymmetric algorithms, while PKI is an infrastructure which solves one of the key problems with public key cryptography.

Public-key cryptography: (aka asymmetric cryptography) is a class of cartographic protocols based on algorithms that require two separate keys, one of which is secret (or private) and one of which is public. The most common uses include: Public-key encryption (message is encrypted with a recipient's public key) and Digital Signatures (message is signed with the sender's private key and can be verified by anyone who has access to the sender's public key). It is a technique that enables users to securely communicate on an insecure public network, and reliably verify the identity of user via digital signatures.

Public-key infrastructure: is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. That is, it involves managing Public-key cryptography, but is not just limited to that.

In order to understand the relation, one must understand the central problem with the Public-key cryptography, which is: confidence/proof that a particular public key is authentic, in that it is correct and belongs to the person or entity claimed, and has not been tampered with or replaced by a malicious third party. Public-key infrastructure is one of the approaches to this problem. It tends to solve the problem by introducing the concept of Certificate Authorities aka trusted third parties, to certify the ownership of key pairs. Another approach to this problem is something called Web of Trust, which decentralizes such authentication of public keys by a central mechanism, and substitutes individual endorsements of the link between user and public key.

What is the main use case for PKI?

The most common use case for PKI, that I can think of, is (from the wikipedia article): to bind public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique within each CA domain. The third-party validation authority (VA) can provide this information on behalf of the CA. The binding is established through the registration and issuance process. Depending on the assurance level of the binding, this may be carried out by software at a CA or under human supervision. The PKI role that assures this binding is called the registration authority (RA). The RA is responsible for accepting requests for digital certificates and authenticating the person or organization making the request.

This use case can be applied in a variety of scenarios such as (again, form wikipedia article):

• Encryption and/or sender authentication of e-mail messages (e.g., using OpenPGP or S/MIME)
• Encryption and/or authentication of documents (e.g., the XML Signature or XML Encryption standards if documents are encoded as XML)
• Authentication of users to applications (e.g., smart card logon, client authentication with SSL)
• Bootstrapping secure communication protocols, such as Internet key exchange (IKE) and SSL.

How are client certificates used in PKI?

This really depends on the specific use case scenario mentioned above. The client certificates might be used differently in different scenarios, but they all serve the same purpose: to verify that a particular public key belongs to a certain entity (client/server/user).

For example: SSL/TLS supports client side certificates. This use case has been covered in this answer by Thomas Pornin. The advantages/disadvantages of using client certificates for authentication have also been covered by this answer by Bruno.

What is a Certificate Authority's role in PKI?

The best answer to this can be found in the quoted wikipedia article (yet again):

The primary role of the CA is to digitally sign and publish the public key bound to a given user. This is done using the CA's own private key, so that trust in the user key relies on one's trust in the validity of the CA's key. When the CA is a third party separate from the user and the system, then it is called the Registration Authority (RA), which may or may not be separate from the CA. The key-user binding is established, depending on the level of assurance the binding has, by software or under human supervision.

Answer 3

As an Introduction sentence: PKI(Public Key Infrastructure) and PKC(Public Key Cryptography) with together are considered as PKT (Public Key Technology).

Short answers: for reading the image open it in new window

Now is the time to answer the questions.

      1. What is the difference between Public Key Infrastructure and Public Key Cryptography?

I think the main difference and relation between them has been hidden behind the definitions and history:

• Public Key Cryptography (PKC): Public key (a.k.a. “two key” or “asymmetric”) cryptography was invented by Diffie and Hellman in 1976 and after that other versions like RSA was presented. Unlike secret key (a.k.a. “symmetric”) cryptography, in which the same key K is shared between parties A and B, pairs of corresponding private and public keys for each user allow the unique realization of some operations. Specifically, let the respective private and public keys, privA and pubA, belong to party A. By operating on data with privA, A can digitally sign data that is verifiable by party B (or any other party) operating on the signed data with pubA. Equivalently, party B (or any other party) can encrypt data using pubA, where the encrypted data can only be decrypted with privA. The true power of public key cryptography lies in the possession of a private key, uniquely, by each party. The “demonstration of knowledge” of the private key by operating on data with said key, provides a powerful tool that distinguishes asymmetric cryptography from its secret key counterpart.
• Public Key Infrastructure (PKI): Approximately 22 years ago, the 1993 version of the ISO/IEC CCITT/ITU-T International Standard X.509 began to be disseminated, recognized, and implemented in small-scale environments. Late 1993 and early 1994 was effectively the beginning of PKI (although that acronym had yet to be coined) because that version of the X.509 standard – more than the 1988 version – fleshed out some of the important details of certificates, certification authorities, and related concepts. In those early days, a “PKI” was defined fairly rigidly, although with hindsight we can identify six major components to the definition that are still critical today, three to do with the validity of bindings (authority functions), and three to do with the use of bindings (client functions). With respect to the validity of the binding between a public key and an identifier, what is needed is:
  1. Authority whose responsibility it is to create and destroy these bindings, as required, or aid in related authoritative actions,
  2. Issuance Process for expressing these bindings in a way that can be understood by other parties (i.e., in an agreed syntax) and for making this information available to parties that wish to know it, and
  3. Termination Process for breaking bindings when necessary and making this information available to parties that need to know it.With respect to the use of such bindings, what is needed is:
  4. Anchor Management Process for augmenting or diminishing the set of authority public keys that will serve as roots or trust anchors for the client
  5. Private Key Management Process for ensuring that a client private key can be used for its desired purpose (this can include key pair generation and update, registering and binding an identifier to the corresponding public key, proper protection of the private key while it is valid, and backup & recovery of the private key in case of loss), and
  6. Binding Validation Process for determining when the client should trust that a given public key (retrieved or acquired from some external entity) is authentically associated with a given identifier.

Therefore, according to above explanations, Public key cryptography only supports asymmetric, mathematical operations on data; it does not by itself provide a connection to applications or environments such as e-commerce, e-mail, or the Web. To provide such a connection, several additional pieces are necessary. These additional pieces form the definition of a PKI – an “infrastructure” that makes public key technology available to the applications and environments that wish to use it.

According to this paper some examples of PKI systems with respect to these characteristics are : X.509, PGP, AADS/X9.59, SPKI

                              2. What is the main use case for PKI?

• TLS: According to the book "Cellular Authentication for Mobile and Internet Services" and RFC2246, One of the biggest existing use case for PKI stems from the use of certificates in the Transport Layer Security (TLS) and TLS supports client certificate.
• Code Signing: With the recent widely publicized data breaches, code signing has become one of the more popular use case for PKI. Digital signatures provide both authenticity and integrity of data and messages. The ability to mathematically prove that data has not changed since the specific time that data signing occurred is a very powerful tool. This enables trust in digitally signed documents, programs and other data objects. A software development house should sign their application code so that endusers can verify that the code has not only been distributed by a trusted source, but that the code has not been altered or infected harmfully in any way. The same concept can be applied to digital signatures and is important to managing documents, such as legal papers (contracts, filings, etc.), invoices, and reports.[Ref]

• Intranet SSL, 802.1x Authentication, S/MIME, IPSec, Authenticating Enterprise Users: and according to this paper the security features of PKI are useful in several common use cases in enterprise network environments such as Intranet SSL, 802.1x Authentication, S/MIME, IPSec, Authenticating Enterprise Users.

                         3. How are client certificates used in PKI?
  

• Definition and differences between Client Certificate and SSL Server Certificate show the usage:

• Client Certificate: A transport certificate that can be external partners and internal partner. If the outbound transport is HTTPS and client authentication is required, you will need an SSL Client certificate. In most cases the SSL Client certificate must be signed and issued by a CA (another role of CA). If the certificate is used in a test environment, it can be self-signed. In other words, client certificates, as the name indicates, are used to identify a client or a user and play a vital role in ensuring people are safe on line and are used to identify a client or a user, authenticating the client to the server and establishing precisely who they are. They are meant for authenticating the client to the server. it is not used for encryption or decryption of data, but represents a user identity and provides user authentication functionality.They consist of the public key portion of the certificate and a private key that is held only by the entity to which the certificate is issued. The certification authority may be a well-known public organization that provides certificate services as part of its business, or it could be an internal server that only your company uses. In either case, the client certificate will have certain information that identifies the user either individually or as part of a group. also the server can be configured to do a mapping of the certificate to a user account. This can be either a one-to-one mapping, where the specific certificate is mapped to a single user account, or a many-to-one mapping, where the server uses certain fields in the certificate information to map any matching certificate to a designated user account. When a mapping is used, the certificate allows the user to be granted or denied access to resources as a particular user. When using client certificates in this manner, you do not have to use any other authentication method.
• SSL Server Certificate: are used to identify a server. Typically they are issued to hostnames, which could be a machine name (like “PIIS-SVR01”) or a host-header (like “www.example.com”). SSL server certificates provide encryption and security functionality and Enable SSL server authentication. The CA of the SSL server certificate has to be exchanged among the participants.

The only similarity between them is the keyword “Certificate”. They both contain public and private keys. For that matter, every certificate contains a public and a private key. it is not possible to use a Server Certificate as a Client Certificate or Vice-Versa.

                           4. What is a Certificate Authority's role in PKI?

In the original Diffie and Hellman model, public keys would be retrieved from a secured repository. The security of this repository served to bind the public key to other attributes of the key owner. In support of offline binding production and distribution, Kohnfelder introduced the notion of a certificate(Towards a Practical Public-key Cryptosystem), whereby a public key and an identifier (e.g., a name) were placed in a data structure signed by a Certification Authority (CA) and made available in an unsecured repository.

Therefore as a summary, since no direct trust exists between a data originator and a data recipient, PKI relies on a third party point of trust system where the CA plays the role of trust arbitrator. The CA first establishes the identity of a Public-Private Key owner beyond doubt, then vouches for the owner’s identity by embedding the owner’s Public Key inside of a certificate bearing the CA’s signature. Anyone that trusts this CA can verify the CA’s signature and thereby the identity of the certificate owner.

Answer 4

I designed an image as Short answers of questions: for reading texts of the image open image in new tab

for more details go to my previous answer.

Answer 5

I will answer this in a two-level approach: General term answer and the specific SSL/TLS clarification in blockquotes.

Public Key Cryptography (PKC) solves the problem of securely exchanging information without the need of previously agreeing upon a secret key. To be part of PKC, every agent needs to have a Private Key (which should only be kept by the owner) and a Public Key (which could be share with everyone) where the former decrypts the content encrypted by the latter and vice versa. Therefore, every agent that wants to communicate with Alice in a secure way needs to encrypt* its messages with Alice's Public Key in order to be sure that only Alice (the owner of the Private Key) can read the message.

In SSL/TLS, when establishing a connection, the server sends its certificate (basically the public key with some metadata) and the client uses it to encrypt a symmetrical key which they will use throughout the rest of the conversation. This is done because symmetrical cryptology is quicker than asymmetrical. Afterwards, when the server receives the encrypted symmetrical key, the server uses its Private Key to decrypt it and then use it for the rest of the conversation.

At this point, everything looks plain and easy, however a priori one doesn't have every agent Public Key. So, in order to establish a secure communication with someone, they need to exchange Public Keys first; and this is where PKC weakness lies. How would I know that the Public Key given to me is effectively from who I want to communicate and is not from a Man-in-the-Middle (MITM)?

This is the problem that Public Key Infrastructure (PKI) solves.

Public Key Infrastructure (PKI) consists of adding another person to the conversation. This other agent is the Certificate Authority (CA), who acts as a neutral judge which is trusted by the two other participants of the conversation. This CA (who also has his Public and Private Key) is the one that signs the Public Key of any PKI user after certifying that they are the person they claim to be. Consequently, whenever an agent of the PKI receive a Public Key, they verify if it has been signed by one of his trusted CAs.

Before establishing a SSL/TLS connection, the client needs to be sure that the received certificate is valid. In order to do it the client verifies not only the authenticity of its public key but also other metadata associated with it (to understand this is important to know the contents of a typical digital certificate):

• The signature verifies. This ensures that the certificate was not altered in any way.
• The certificate has not expired. When the certificate is issued by the CA its granted an expiration date.
• The certificate subject matches the host name. The certificate is issued for an specific server. Thus the certificate subject name needs to match the URL the client is trying to connect.
• It has not been revoked. Sometimes certificates can be revoked by their issuers in any case needed (for example, the associate private key has been exposed hence the certificate becomes invalid).
• It was signed by a trusted CA. To prove the certificate authenticity we need to get the CA certificate and verify its trustiness. Nevertheless in PKI there is a concept of Chain of Trust, so the CA certificate could have been issued by another CAs. Therefore we need to get this another CA's certificate and validate it. And so on... Ergo, in order to trust a certificate, we need to navigate all the way up to the Root CA. Finally, if we trust in the Root CA it is safe to say that we trust in the whole chain.

All in all, a PKI is necessary when PKC is being used and all the participants cannot be determined beforehand.

This is why we don't need a CA for the Root CAs. There are only a bunch of them which are already known and trusted by your computer system. They came installed by default in your OS/Browser (or can also be manually installed). However, for the rest of the servers or Intermediate CAs, we can't know their certificates beforehand (due to the fact that there are so many of them) and then we use PKI to verify their authenticity by following the chain of trust until a Root CA (that we could end up trusting or not).

In order to address all your questions, now I will briefly answer about Client certificates. Client certificates are the same as Server certificates. However they are commonly used by servers as a method of client authentication. This type of solution is valid when there are few and known clients of the server.

Answer 6

Until the early 1970's, the only way to encrypt and decrypt messages was using symmetric algorithms, in which the same key is used for both operations. The key has to be exchanged securely by some means before two parties can communicate privately.

Public key cryptography, or asymmetric encryption, is a novel way to encrypt and decrypt messages using two keys - one which is kept secret and one which is shared. Two parties can exchange public keys to communicate securely without ever meeting, even if the connection is monitored.

An analogy to public key encryption is a safe and key. You can send anyone an open safe - your public key - and seal it, and only you can unlock it using your private key. Similarly, in an asymmetric cryptosystem, messages encrypted with a private key can be verified by the corresponding public key to prove authenticity, like a signature.

However, one still needs to verify a public key really belongs to the purported owner. After all, an attacker can modify the connection and insert her own public key in place of the legitimate one.

For instance, the first time you ssh to a new server, your client will ask whether you trust the fingerprint of the server's public key, which you're meant to check from a local terminal. Or the first time you start an OTR conversation, you should verify the others' fingerprint by voice or in person.

Another way is to simply have a designated authority "vouch" for others, know as a public key infrastructure. The public key is included as part of a certificate along with other information such as the issuer name, subject and expiration, then is digitally signed using asymmetric encryption by an authority's private key, or its own private key.

Each operating system and many applications define a list of certificates which are trusted. These are commonly referred to as root certificate authorities. They often delegate to intermediate certificate authorities which sign the certificates of servers and clients in a public key infrastructure.

Client certificates are not so different from server certificates. Servers may requests them to authenticate clients, for example, instead of asking users to type a username and password.

Answer 7

Since we should all be familiar with the layers a la the OSI model: PKI sits atop public key crypto. The public referred to here is a misnomer, in the sense that it does not really mean a generalised audience, but that the keys, or at least the public key, can be in the open, and also by extension able to be freely distributed, though in reality this might not be the case. The public key cryptography in the RFCs, refer specifically to the on disk formats, key ciphers, transfer formats, handshake/transfer protocols.

The infrastructure referred to here and specifically in the RFCs, is the framework by which the keys are handled, distributed, verified by a third party, and generally used in real world environments - the technical aspects anyway, not so much the business part.

Answer 8

Public Key Infrastructure refers to the systems and processes for managing the exchange and validation of security certificates. Public-key cryptography provides the technical parts for the actual encryption/decryption, but PKI is what provides reasonable assurance that the certificate is from a valid and authenticate identity, and "vouches" for trust.

In a simple scenario, you can hand your friend your public key and since he/she is getting it direct from you, it can be trusted. However, when you need to obtain public keys when you can trust all of the intermediary points you need PKI, managed by some trusted third party (we generally trust a given party because we believe they follow certain practices and protections). PKI also simplifies the management from creation through usage, and when needed, revocation. You use a certificate to associate ownership and other data with your public key, such as name type information and expiration date of the certificate.

PKI is generally thought of as being available over the public Internet. But organizations may establish their own internal PKI.

Generally, the idea is that you want to claim things (emails, websites, etc.), or provide reasonable assurance to others that something came from you (TLS certificates) or was made by you (email certificates). So you go to one of these trusted third parties (Certificate Authority aka CA) and provide them (technically the Registration Authority aka RA, but in most cases it feels like the same provider to the end user) proof of a given identity (may be personal or organization). Depending on the type of certificate and the level of assurance, the burden of proof will vary. The mechanics of how the public-private key pair are generated and how the public key is provided to the CA are beyond the scope here and can vary based on situation. Basically, you provide the CA the public key and proof of identity.

What the CA does is cryptographically sign you public key. The assumptions are that your public certificate is only signed by the CA if you provided sufficient proof of identity and that forgery of this signing is very difficult and unlikely. Your system must know a priori about the CA, a list of known, vetted CAs is distributed with most operating systems, you can of course add your own CA if you want. Because your system trusts the CA, you trust the CA. If the CA says it has verified the claimed identity being provided, then your system trusts it (transitive trust- Because I trust the CA, I trust the assertions it makes). Another CA responsibility is revoking a certificate. Your public key is only useful under the condition that your private key is private and generally unknown. While certificates have expiration dates, if your private key is compromised, then you can contact the CA and have them revoke your certificate so that way the stolen, leaked, or otherwise compromised private key will not be used to pretend to be you. When system query the CA, the CA will say, "Yah, I verified that identity and issued the cert, but it's been compromised now, so what I said before no longer holds"

I think I hit all your major points, send me some comments if you want anything explained more. I'll try to add some hyperlinks later.

Answer 9

While I do cite quite a few references the majority of your question(s) are available online. With that said a preferred resource would be to visit the OpenSSL Wiki for usability, attack vectors, algorithms & implementation questions, GAIC for performance, best practices and high level information and NIST for standards regarding the use of PKI as well as Public Key Crypto.

1. What is the difference between Public Key Infrastructure and Public Key Cryptography? How are they related?

• Public Key Cryptography is an asymmetric encryption technique where using a strong PRNG (pseudo random number generator) a private key is created and encoded in either a PKCS#8 or PKCS#12 format using the standard ASN.1 encoding.

  Once a private key is created a public key can then be derived and then sent to a recipient with which encrypted and digitally signed communications can transpire.

• PKI or Public Key Infrastructure is how you can centrally manage a large 'keyring' of keys, x.509 certificates etc. It uses an escrow to place possibly compromised, expired & untrusted keys into an unusable state while preserving them in case decryption of data needs to be done.

  In regards to how they are related; PKI was created to assist in large scale public key deployments where data integrity and centralized administration was necessary.

2. What is the main use case for PKI?

It is used primarily for escrow, key & certificate management.

3. How are client certificates used in PKI?

Client certificates are used for a variety of purposes. Authentication, authorization, verification, signatures etc.

A real world example;

The SPKAC PKCS#1 (Signed public Key and Challenge) can be created within a web browser with the <KeyGen> element.

This coupled with the same information provided when generating a CSR (Certificate Signing Request); i.e. the certificate attributes, can be sent to a CA (certificate authority) for signing then be installed within the client browser certificate store.

Once this process has transpired a web server or other service capable of x.509 client certificate authentication/authorization can then allow access simply by requesting client certificates from the browser certificate store.

4. What is a Certificate Authority's role in PKI?

A certificate authority or CA corresponds to the root certificate used for signing of any x.509 certificate within a certificate chain. Traditionally a root certificate's private key is kept encrypted and offline to prevent access.