Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This is possibly a stupid question but, how does SSL relate to the Public Key Infrastructure?

Cheers, J

share|improve this question
3  
I would try security.stackexchange.com first, because here its off topic –  TheLQ Jan 11 '11 at 13:12
add comment

3 Answers

SSL and TLS (the newer version of the standard) is one of many transport mechanisms that allows PKI to work over the network (originally, there was X.500). I'll be using TLS for the remainder of the answer. It's outside the scope of this forum to describe PKI in full. The exact handshake is like a ballroom dance. Essentially TLS defines the framework for the server and client to identify themselves and agree on an encryption standard and key. It is this identification process that makes PKI possible through TLS.

I'm assuming you are familiar with public and private keys as well as certificates. Everything past this point assumes familiarity with those terms and concepts. Also note that TLS has several encryption and encoding standards, and not all of them support PKI. Typically, both the client and server will need signed X.509 certificates to identify themselves.

Both the server and the client have identities. In a typical online retail situation, the only entity that is really important is the server. The clients have to have confidence that they are interacting with the server they intended to. Just about all retail servers that use SSL/TLS have a certificate, which is a signed public key that advertises the signature authority.

With PKI, the server also needs to know if the client has permission to access the server. The public client certs are signed by a trust authority that is known to the server (i.e. the server has the public key for the trust authority and validates certificates against that trust cert).

The TLS wikipedia article has the exchange for the three types of handshakes (simple, client-authenticated, and session resume). The handshake that makes PKI possible is the client authenticated handshake. A really simplified version of the handshake is below:

Client -> Hi! Can we talk? I know XYZ and PDQ standards

Server -> Wazzup? Let's use PDQ. Oh, and here's my Creds (credentials)... What's yours?

Client -> Kool, I know you. Here's my creds. You know it's me from now on.

Server -> Sweet, you check out. You know it's me from now on.

Wikipedia has a lot less slang, but this is the basics of how PKI works over TLS. The client needs to be confident that it has the right server, and the server needs to be confident the client is who they say they are.


Important note: The effectiveness of the key exchange depends entirely on how the keys are managed. This means the policies and procedures for identifying that a client's key is in fact tied to that client is not sound, neither will the PKI be robust. Additionally, if the trust authority's private key is known by a number of people, or is unencrypted, then that trust authority cannot be trusted. The same with the client private key. TLS handles the Public Key part, but the Infrastructure is all in how you manage the keys that cooperate in this whole exchange.

share|improve this answer
    
"SSL and TLS (the newer version of the standard) is the transport mechanism that allows PKI to work over the network" . This is exactly the other way around. PKI can live without SSL, but SSL can hardly live without (at least parts of) PKI. –  Eugene Mayevski 'EldoS Corp Jan 11 '11 at 18:04
1  
The key word is transport mechanism. In short TLS lives inside the larger concept of PKI, rather than PKI living inside TLS. Does the note at the bottom serve to clarify things, or make it worse? –  Berin Loritsch Jan 11 '11 at 18:11
    
not at all. Certificate-based PKI (i.e. what we call PKI today) has it's roots in X.500, which existed long before SSL existed (first version of X.509 appeared in 1988, while SSL appeared in mid-90's). As I said, PKI can live fine without SSL/TLS, so "the transport mechanism that allows PKI ..." is a very narrow description. Regarding your note: there exist cipher suites of SSL/TLS that don't use X.509 certificates (PSK, OpenPGP etc.), so even your note is partial. I am sorry for saying this, but some learning is needed. –  Eugene Mayevski 'EldoS Corp Jan 11 '11 at 19:34
    
It's more that I omitted too much. In a forum like this the best you can hope for is a simple understanding of the concepts. The OP's question pertained to SSL/TLS and PKI. For most folks, SSL/TLS and PKI seem to be synonomous. I can edit the answer to make this more clear. –  Berin Loritsch Jan 11 '11 at 20:17
    
I've edited my answer so that hopefully it is clearer about the scope of the answer. Please let me know if there are any more serious omissions. I'm just trying to provide a jumping off point for further study. –  Berin Loritsch Jan 11 '11 at 20:27
add comment

In brief: SSL makes use of PKI in operations.

This includes use of asymmetric cryptographic algorithms and public and private keys, contained and associated with X.509 certificates, which are one of the most important parts of PKI. Now, SSL validates the certificates, and during validation it uses several PKI protocols and standards (CRLs, OCSP requests etc).

share|improve this answer
add comment

From wikipedia:

Public Key Infrastructure (PKI) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates

SSL is short for Secure Socket Layer. It is a standard for secure communication implemented in software. It uses and distributes certificates.

A typical application of SSL is sending and receiving email.

share|improve this answer
    
SSH does not run on SSL. Check the RFC. –  Paul Nathan Jan 11 '11 at 18:48
    
@Paul Nathan: Fair enough. Which rfc? –  Matt Ellen Jan 11 '11 at 19:03
    
4252: The Secure Shell Protocol. –  Paul Nathan Jan 11 '11 at 21:16
    
@Paul Nathan: I'd rather point him to RFC 4253, from § 6.3 onwards. –  jweyrich Jan 12 '11 at 2:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.