7 ms·

PKI for busy people

369 points by crehn 8y ago

cwingrav 8y ago
The author of this needs to write a few more on other topics. The succinctness and simplicity (i.e. minimum bits) is a nice change from so many documentation sites. Can Amazon get him to rewrite their documentation?
- Edmond 8y ago
  I suspect it only seems succinct because you're familiar with the details...I like it too for that reason. However for anyone who doesn't have the requisite background it will just be abstract and impenetrable.
  - penguin_booze 8y ago
    Not quite - the links are a useful starting point rather than waving hands, saying 'just google it'.
  - chrismeller 8y ago
    I somewhat agree. I feel like this is a nice glossary that I could hand my boss so he would understand what we’re talking about and stop asking what each one is, but he still wouldn’t really “get” the process for any of the examples. If it tried to explain the full process you’re now diving into the explanations of GPG and buying SSL certs, etc and that feels like their eyes would simply glaze over. I would like to see a tad more separation between the types of PKI (specifically GPG vs TLS type clarity).
leowoo91 8y ago
PKI stands for "Public Key Infrastructure" in the article, I thought it would be about performance key indicators.
- cpach 8y ago
  You’re probably thinking of KPI, Key Performance Indicators.
  - 420codebro 8y ago
    Make sure your TCAs properly reflect your KPIs otherwise your MBOs are gonna be hosed.
  - leowoo91 8y ago
    Right, thank you for heads up.
- rmwaite 8y ago
  I’ve always heard Key Performance Indicators (KPI)
kgoutham93 8y ago
> Since binary data can be a pain to transmit, it’s often further encoded into PEM. PEM is essentially just Base64-encoded DER. Why's binary data a pain to transmit and how does base64 encoding help with that?
- munchbunny 8y ago
  There are usually far more ways to move text around than arbitrary binary bits, such as copy-pasting in terminals and web forms. It also lets you embed certificates in formats that don't normally support literal binary data, such as JSON.
  - mdaniel 8y ago
    To add to this already good explanation, it's my understanding that base64 and the MIME packaging scheme were invented because many early Internet protocols made a distinction between text mode and binary mode due to the majority of the protocol framing being text. You can thank them for that textual decision(?) when you're debugging SMTP with a copy of netcat, but it means that a PDF attachment needs to be encoded to travel over email. To bring this conversation back to PKI, base64 encoding means you can embed the GPG signature of your email body in the text itself, without having to deal with attachments like S/MIME does
- CaliforniaKarl 8y ago
  PEM format also adds the "----- BEGIN …" header/footer around the base64-encoded contents, which helps humans identify what the blob is.
nlawalker 8y ago
Is there something like this specifically for certificates that goes into a little more technical detail? Every description I've ever read of certificates doesn't go much further than what's in this article ("a name and public key bound by a signature"). I've never really been able to get my head around things like when and how a certificate also contains a private key (and when that private key is "exportable"), what all the "key usages" are and where they get their strange identifiers from (and how those things are actually enforced and used), etc. EDIT: I should have kept reading, the linked Wikipedia articles on X.509, ASN.1, DER and PEM in the next section appear to be about what I'm looking for. I suppose I've just always been confused by all the formality and the number of specifications about different things.
- Boulth 8y ago
  Pasting the cert here https://lapo.it/asn1js/ https://lapo.it/asn1js/ can give a lot of pointers to what is in there.
- rbarroso 8y ago
  @nlawalker its quite verbose and long (like most RFCs) but you have all the information you may need about X.509 certificates's format on its RFC: https://tools.ietf.org/html/rfc5280 https://tools.ietf.org/html/rfc5280
- malingo 8y ago
  This article has some good depth; it was posted on HN a few months ago. https://smallstep.com/blog/everything-pki.html https://smallstep.com/blog/everything-pki.html
  - mdaniel 8y ago
    Wow, that is a crazy good article. I aspire to be able to write that clearly about such a complex and messy topic. And, it did its job as a promotional piece because TIL about Smallstep
- tialaramex 8y ago
  > when and how a certificate also contains a private key (and when that private key is "exportable") There is a file format called PKCS #12 which lets you bundle things together. It is very common, particularly on Windows systems, to see this format used with files (often names ending .PFX) to bundle together a _certificate_ and a _private key_. This is presumably "convenient" in some sense, but since the security requirements for these two things are utterly different (a certificate is a public document that can be shown to anyone, a private key must not be seen by anybody else) it's a hazard in practice. It's especially problematic that the resulting bundle (which you mustn't show to anybody) is often labelled a "certificate" when by far the more important thing inside it is a private key... The same bundling idea can be done in PEM (the big blobs of Base 64 encoded stuff more often seen in Unix systems) by just concatenating a private key PEM to a certificate PEM. But at least if you look at it in a text editor you can see what somebody did, whereas in PFX it's a bit opaque without specialist tools. Bundling these two things together most often happens in the context where somebody _else_ makes your key (and issues you a certificate). This is bad practice, not only is it patronising ("Poor dear don't understand crypto, we'll just give them the keys ready made") but it means the end user is vulnerable to copies kept nefariously or by accident. Avoid. Certificate Authorities are prohibited from doing this for certificates in the Web PKI ("SSL certificates") but their resellers often still offer it as a "service". Say no. In fact try "Hell no".
chrisweekly 8y ago
This is an excellent summary. Helpful to have such a clear and concise overview to share as a reference when working with clients with varying levels of understanding. Bravo, and thank you!
AnonC 8y ago
> Root certificates are trusted and stored locally. They’re usually shipped along the OS. They're also shipped with the browser, as is the case with Firefox. They may also be shipped with applications (some versions of Visual Studio seem to have their own certificate store).
- Spivak 8y ago
  They're also shipped with application runtimes in the case of Java.
- crehn 8y ago
  Thanks! Added browsers as an example.
hannob 8y ago
The part about signatures is not really correct. It says: " To sign a message, encrypt it with the private key To verify a signature, decrypt it with the public key and make sure it matches the message" This is only half true for one algorithm: RSA. But even there it's only true for something called "Textbook RSA", which is an insecure variant of RSA nobody should be using. It's not true for any real algorithm. I'm really not a fan of such sloppy "I want to explain it easy" crypto introductions that are simply not correct. (Also found it odd that he uses "Verisign" as an example for a CA. Verisign has been bought by Symantec and Symantec was distrusted by browsers recently, so it's as dead as it can be.)
- cheez 8y ago
  I presume what you're saying is that there is a whole set of missing verification additions, but if not, what are you referring to for textbook RSA being insecure?
  - kelnage 8y ago
    Textbook RSA is not secure, as there’s no element of randomness in the encryption, rendering it susceptible to chosen ciphertext attacks. RSA+OAEP includes randomness and also protects again vulnerability such as certain plaintexts always having the same encryption regardless of key.
    - nodamage 8y ago
      Does this only apply to encryption or also signatures?
      - dfox 8y ago
        It applies to both, albeit with slightly different practical implications.
  - GordonS 8y ago
    Not the OP, but I presume they meant RSA can only be used to encrypt really short messages. More typically to sign a message, RSA is used to sign a hash of the message.
ct520 8y ago
Interesting.. Wait till you get validating cert chain without the carts issuing cert. following AIA fun stuff the things cert issuers can return
ggm 8y ago
Seems a bit over-brief in some ways, hashing needs a little more. But overall, this is very useful. It gave me some confidence over slidepacks I've done as basic introductions, but rather then spin my own I'd like to point to words like this which are both curated and reviewed. So. .. thanks!
deleted 8y ago
[deleted]
gerdesj 8y ago
A certificate is a name and public key bound by a signature. It identifies the owner of a public key. A certificate identifies a name. The signee is called a certificate authority (CA). The CA is often some big company, like VeriSign. With internal PKI, it can be any entity that nodes have been configured to trust. A CA authenticates the identity claimed by a certificate. A CA’s certificate can be signed by another CA, and so on. The last certificate in the chain is called a root certificate. Root certificates are trusted and stored locally. They’re usually shipped along the OS. There can be a chain of trust whereby one CA authenticates the next. Its a tricky subject and I don't think it is really possible to get too far beyond "give me £100 for this SSL certificate" ... "because" ... sigh [fill in your own SSL related conversations with your PHB stupidity here]
runiq 8y ago
While it's great to have resources like this, I feel that this should come with a giant disclaimer at the top, reading something like: >WARNING: This is just the tip of the iceberg. Also, ice is generally slippery. If your crypto knowledge amounts to the stuff presented here, stick to known, battle-tested implementations.
seertaak 8y ago
This was incredibly useful, many thanks for posting. In particular I was really confused about the difference between ".der" files and ".pem" files. The concise, pithy, style makes reading very easy.

369 points by crehn 8y ago

The author of this needs to write a few more on other topics. The succinctness and simplicity (i.e. minimum bits) is a nice change from so many documentation sites. Can Amazon get him to rewrite their documentation?

Edmond 8y ago
I suspect it only seems succinct because you're familiar with the details...I like it too for that reason. However for anyone who doesn't have the requisite background it will just be abstract and impenetrable.
- penguin_booze 8y ago
  Not quite - the links are a useful starting point rather than waving hands, saying 'just google it'.
- chrismeller 8y ago
  I somewhat agree. I feel like this is a nice glossary that I could hand my boss so he would understand what we’re talking about and stop asking what each one is, but he still wouldn’t really “get” the process for any of the examples. If it tried to explain the full process you’re now diving into the explanations of GPG and buying SSL certs, etc and that feels like their eyes would simply glaze over. I would like to see a tad more separation between the types of PKI (specifically GPG vs TLS type clarity).

leowoo91 8y ago

PKI stands for "Public Key Infrastructure" in the article, I thought it would be about performance key indicators.

cpach 8y ago
You’re probably thinking of KPI, Key Performance Indicators.
- 420codebro 8y ago
  Make sure your TCAs properly reflect your KPIs otherwise your MBOs are gonna be hosed.
- leowoo91 8y ago
  Right, thank you for heads up.
rmwaite 8y ago
I’ve always heard Key Performance Indicators (KPI)

kgoutham93 8y ago

> Since binary data can be a pain to transmit, it’s often further encoded into PEM. PEM is essentially just Base64-encoded DER. Why's binary data a pain to transmit and how does base64 encoding help with that?

munchbunny 8y ago
There are usually far more ways to move text around than arbitrary binary bits, such as copy-pasting in terminals and web forms. It also lets you embed certificates in formats that don't normally support literal binary data, such as JSON.
- mdaniel 8y ago
  To add to this already good explanation, it's my understanding that base64 and the MIME packaging scheme were invented because many early Internet protocols made a distinction between text mode and binary mode due to the majority of the protocol framing being text. You can thank them for that textual decision(?) when you're debugging SMTP with a copy of netcat, but it means that a PDF attachment needs to be encoded to travel over email. To bring this conversation back to PKI, base64 encoding means you can embed the GPG signature of your email body in the text itself, without having to deal with attachments like S/MIME does
CaliforniaKarl 8y ago
PEM format also adds the "----- BEGIN …" header/footer around the base64-encoded contents, which helps humans identify what the blob is.

nlawalker 8y ago

Is there something like this specifically for certificates that goes into a little more technical detail? Every description I've ever read of certificates doesn't go much further than what's in this article ("a name and public key bound by a signature"). I've never really been able to get my head around things like when and how a certificate also contains a private key (and when that private key is "exportable"), what all the "key usages" are and where they get their strange identifiers from (and how those things are actually enforced and used), etc. EDIT: I should have kept reading, the linked Wikipedia articles on X.509, ASN.1, DER and PEM in the next section appear to be about what I'm looking for. I suppose I've just always been confused by all the formality and the number of specifications about different things.

Boulth 8y ago
Pasting the cert here https://lapo.it/asn1js/ https://lapo.it/asn1js/ can give a lot of pointers to what is in there.
rbarroso 8y ago
@nlawalker its quite verbose and long (like most RFCs) but you have all the information you may need about X.509 certificates's format on its RFC: https://tools.ietf.org/html/rfc5280 https://tools.ietf.org/html/rfc5280
malingo 8y ago
This article has some good depth; it was posted on HN a few months ago. https://smallstep.com/blog/everything-pki.html https://smallstep.com/blog/everything-pki.html
- mdaniel 8y ago
  Wow, that is a crazy good article. I aspire to be able to write that clearly about such a complex and messy topic. And, it did its job as a promotional piece because TIL about Smallstep
tialaramex 8y ago
> when and how a certificate also contains a private key (and when that private key is "exportable") There is a file format called PKCS #12 which lets you bundle things together. It is very common, particularly on Windows systems, to see this format used with files (often names ending .PFX) to bundle together a _certificate_ and a _private key_. This is presumably "convenient" in some sense, but since the security requirements for these two things are utterly different (a certificate is a public document that can be shown to anyone, a private key must not be seen by anybody else) it's a hazard in practice. It's especially problematic that the resulting bundle (which you mustn't show to anybody) is often labelled a "certificate" when by far the more important thing inside it is a private key... The same bundling idea can be done in PEM (the big blobs of Base 64 encoded stuff more often seen in Unix systems) by just concatenating a private key PEM to a certificate PEM. But at least if you look at it in a text editor you can see what somebody did, whereas in PFX it's a bit opaque without specialist tools. Bundling these two things together most often happens in the context where somebody _else_ makes your key (and issues you a certificate). This is bad practice, not only is it patronising ("Poor dear don't understand crypto, we'll just give them the keys ready made") but it means the end user is vulnerable to copies kept nefariously or by accident. Avoid. Certificate Authorities are prohibited from doing this for certificates in the Web PKI ("SSL certificates") but their resellers often still offer it as a "service". Say no. In fact try "Hell no".

chrisweekly 8y ago

This is an excellent summary. Helpful to have such a clear and concise overview to share as a reference when working with clients with varying levels of understanding. Bravo, and thank you!

AnonC 8y ago

> Root certificates are trusted and stored locally. They’re usually shipped along the OS. They're also shipped with the browser, as is the case with Firefox. They may also be shipped with applications (some versions of Visual Studio seem to have their own certificate store).

Spivak 8y ago
They're also shipped with application runtimes in the case of Java.
crehn 8y ago
Thanks! Added browsers as an example.

hannob 8y ago

The part about signatures is not really correct. It says: " To sign a message, encrypt it with the private key To verify a signature, decrypt it with the public key and make sure it matches the message" This is only half true for one algorithm: RSA. But even there it's only true for something called "Textbook RSA", which is an insecure variant of RSA nobody should be using. It's not true for any real algorithm. I'm really not a fan of such sloppy "I want to explain it easy" crypto introductions that are simply not correct. (Also found it odd that he uses "Verisign" as an example for a CA. Verisign has been bought by Symantec and Symantec was distrusted by browsers recently, so it's as dead as it can be.)

cheez 8y ago
I presume what you're saying is that there is a whole set of missing verification additions, but if not, what are you referring to for textbook RSA being insecure?
- kelnage 8y ago
  Textbook RSA is not secure, as there’s no element of randomness in the encryption, rendering it susceptible to chosen ciphertext attacks. RSA+OAEP includes randomness and also protects again vulnerability such as certain plaintexts always having the same encryption regardless of key.
  - nodamage 8y ago
    Does this only apply to encryption or also signatures?
    - dfox 8y ago
      It applies to both, albeit with slightly different practical implications.
- GordonS 8y ago
  Not the OP, but I presume they meant RSA can only be used to encrypt really short messages. More typically to sign a message, RSA is used to sign a hash of the message.

ct520 8y ago

Interesting.. Wait till you get validating cert chain without the carts issuing cert. following AIA fun stuff the things cert issuers can return

ggm 8y ago

Seems a bit over-brief in some ways, hashing needs a little more. But overall, this is very useful. It gave me some confidence over slidepacks I've done as basic introductions, but rather then spin my own I'd like to point to words like this which are both curated and reviewed. So. .. thanks!

deleted 8y ago

[deleted]

gerdesj 8y ago

A certificate is a name and public key bound by a signature. It identifies the owner of a public key. A certificate identifies a name. The signee is called a certificate authority (CA). The CA is often some big company, like VeriSign. With internal PKI, it can be any entity that nodes have been configured to trust. A CA authenticates the identity claimed by a certificate. A CA’s certificate can be signed by another CA, and so on. The last certificate in the chain is called a root certificate. Root certificates are trusted and stored locally. They’re usually shipped along the OS. There can be a chain of trust whereby one CA authenticates the next. Its a tricky subject and I don't think it is really possible to get too far beyond "give me £100 for this SSL certificate" ... "because" ... sigh [fill in your own SSL related conversations with your PHB stupidity here]

runiq 8y ago

While it's great to have resources like this, I feel that this should come with a giant disclaimer at the top, reading something like: >WARNING: This is just the tip of the iceberg. Also, ice is generally slippery. If your crypto knowledge amounts to the stuff presented here, stick to known, battle-tested implementations.

seertaak 8y ago

This was incredibly useful, many thanks for posting. In particular I was really confused about the difference between ".der" files and ".pem" files. The concise, pithy, style makes reading very easy.