3 ms·

Websites require long term certificate retention and every year or two those certificates are replaced just like email PKI keys are in an environment with key m

Websites require long term certificate retention and every year or two those certificates are replaced just like email PKI keys are in an environment with key management. So, long term crypto storage in that regard is equivalent between email and the web. The fact that the PKI keys of TLS are temporary are more out of convenience than security because the client/server have to work out which key set algorithm is agreeable. You don't generally need a certificate in addition to perform key exchange over email, though that is an option, because you either know and trust who you are manually exchanging keys with or the remote user is already trusted because you are both on the same server that is automating the exchange. On the web everything is anonymous so there is no trust without that certificate. If you really want one though modern email clients will allow you to create a personal certificate and digital signature to establish identity. Key exchange isn't meant to provide identity. That is what signed certificates are for. The keys are only there to provide distributed encryption. Most modern email clients will allow you to generate a certificate for your emails with a digital signature. https://en.wikipedia.org/wiki/Digital_signature https://en.wikipedia.org/wiki/Digital_signature

dredmorbius 7y ago
Sorry, what's your source? Your link fails to address your assertion at all. Any website key retention is out of convention rather to ensure data access, and a convention Let's Encrypt is fast upending: The certificate is valid for 90 days, during which renewal can take place at any time. https://en.wikipedia.org/wiki/Let%27s_Encrypt https://en.wikipedia.org/wiki/Let%27s_Encrypt Key exchange is a component of PKI. You either need to know, or be able to request, a given key to validate it, or transmissions based on it. TLS (as SSL before it) relies on certificate authorities (CAs), whose keys 1) are distributed to all major browsers and/or operating systems, and 2) which then vouch for website keys. Other mechanisms (e.g., key pinning) are also used. This model has many critics. PGP (or Gnupg, and alternate implementation) rely, also to various degrees of general criticism, on a web of trust model, in which keys are signed by various other keys, possibly but not necessarily the user's own. Trust is ideally personally verified. It's been observed that this poses scaling issues. Other PKI models have their own approaches to key trust. S/MIME uses CAs similarly to TLS/SSL, for key authentication, but keys themselves must still be retained, and secured, to assure future data access and integrity. SSH effectively relies on TOFU (trust on first use) or OOB (out of band) key distribution -- both of which effectively punt the process. TLS, SSL, and SSH are all session-based (data-in-flight) protocols. PGP and S/MIME are storage-oriented, data-at-rest protocols. My initial comments apply to each.
- austincheney 7y ago
  > Sorry, what's your source? https://en.wikipedia.org/wiki/Transport_Layer_Security#Algorithm https://en.wikipedia.org/wiki/Transport_Layer_Security#Algor... Yes, the Let's Encrypt certificates are valid for only 90 days. > whose keys 1) are distributed to all major browsers and/or operating systems Not exactly. Root certificates are widely distributed to user-agent applications but the actual website certificates are available upon request from visiting the sites. A CA is an issuing authority for certificates. Certificates are not directly a component of encryption, but serve to validate the encryption is trusted. * https://en.wikipedia.org/wiki/Root_certificate https://en.wikipedia.org/wiki/Root_certificate * https://en.wikipedia.org/wiki/Certificate_authority https://en.wikipedia.org/wiki/Certificate_authority * https://en.wikipedia.org/wiki/Public_key_certificate https://en.wikipedia.org/wiki/Public_key_certificate * certificate distribution schemes - https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_compsci134/slides/LEC12-KED.pdf https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_comp...
  - dredmorbius 7y ago
    Again, there's nothing in the Wikipedia link which specifies that site certificates MUST exist for a specific duration. Because there's no such requirement in RFC 8446 4.4.2.2, "Server Certificate Selection": https://tools.ietf.org/html/rfc8446#section-4.4.2.2 https://tools.ietf.org/html/rfc8446#section-4.4.2.2 If you have information otherwise please do us both the favour of quoting the relevant language from an authoritative source directly in your reply. You're also creating a dispute based on a claim I've not made. CA keys being "distributed to all major browsers and/or operating systems", my claim, which you quote, does not preclude other distribution mechanisms. That discussion is unnecessary here. Your understanding, generally, seems in error. Again: TLS sever keys have no minimum duration requirement, as the Let's Encrypt description previously cited makes explicitly clear: "renewal can take place at any time".
    - austincheney 7y ago
      > Again, there's nothing in the Wikipedia link which specifies that site certificates MUST exist for a specific duration. I never said anything like that. Web certificates are around for as long as both the website and CA are willing to service them.
wolf550e 7y ago
Best practice is Let's Encrypt 3 month certs and best practice is to only allow TLS cipher suites that provide PFS (which are the only ones allowed for HTTP/2 and the only ones present in TLS1.3), which mean that the private key for the cert is useless as soon as the cert expires and cannot be used for retroactive decryption even while the cert is valid.

dredmorbius 7y ago

Sorry, what's your source? Your link fails to address your assertion at all. Any website key retention is out of convention rather to ensure data access, and a convention Let's Encrypt is fast upending: The certificate is valid for 90 days, during which renewal can take place at any time. https://en.wikipedia.org/wiki/Let%27s_Encrypt https://en.wikipedia.org/wiki/Let%27s_Encrypt Key exchange is a component of PKI. You either need to know, or be able to request, a given key to validate it, or transmissions based on it. TLS (as SSL before it) relies on certificate authorities (CAs), whose keys 1) are distributed to all major browsers and/or operating systems, and 2) which then vouch for website keys. Other mechanisms (e.g., key pinning) are also used. This model has many critics. PGP (or Gnupg, and alternate implementation) rely, also to various degrees of general criticism, on a web of trust model, in which keys are signed by various other keys, possibly but not necessarily the user's own. Trust is ideally personally verified. It's been observed that this poses scaling issues. Other PKI models have their own approaches to key trust. S/MIME uses CAs similarly to TLS/SSL, for key authentication, but keys themselves must still be retained, and secured, to assure future data access and integrity. SSH effectively relies on TOFU (trust on first use) or OOB (out of band) key distribution -- both of which effectively punt the process. TLS, SSL, and SSH are all session-based (data-in-flight) protocols. PGP and S/MIME are storage-oriented, data-at-rest protocols. My initial comments apply to each.

austincheney 7y ago
> Sorry, what's your source? https://en.wikipedia.org/wiki/Transport_Layer_Security#Algorithm https://en.wikipedia.org/wiki/Transport_Layer_Security#Algor... Yes, the Let's Encrypt certificates are valid for only 90 days. > whose keys 1) are distributed to all major browsers and/or operating systems Not exactly. Root certificates are widely distributed to user-agent applications but the actual website certificates are available upon request from visiting the sites. A CA is an issuing authority for certificates. Certificates are not directly a component of encryption, but serve to validate the encryption is trusted. * https://en.wikipedia.org/wiki/Root_certificate https://en.wikipedia.org/wiki/Root_certificate * https://en.wikipedia.org/wiki/Certificate_authority https://en.wikipedia.org/wiki/Certificate_authority * https://en.wikipedia.org/wiki/Public_key_certificate https://en.wikipedia.org/wiki/Public_key_certificate * certificate distribution schemes - https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_compsci134/slides/LEC12-KED.pdf https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_comp...
- dredmorbius 7y ago
  Again, there's nothing in the Wikipedia link which specifies that site certificates MUST exist for a specific duration. Because there's no such requirement in RFC 8446 4.4.2.2, "Server Certificate Selection": https://tools.ietf.org/html/rfc8446#section-4.4.2.2 https://tools.ietf.org/html/rfc8446#section-4.4.2.2 If you have information otherwise please do us both the favour of quoting the relevant language from an authoritative source directly in your reply. You're also creating a dispute based on a claim I've not made. CA keys being "distributed to all major browsers and/or operating systems", my claim, which you quote, does not preclude other distribution mechanisms. That discussion is unnecessary here. Your understanding, generally, seems in error. Again: TLS sever keys have no minimum duration requirement, as the Let's Encrypt description previously cited makes explicitly clear: "renewal can take place at any time".
  - austincheney 7y ago
    > Again, there's nothing in the Wikipedia link which specifies that site certificates MUST exist for a specific duration. I never said anything like that. Web certificates are around for as long as both the website and CA are willing to service them.

wolf550e 7y ago

Best practice is Let's Encrypt 3 month certs and best practice is to only allow TLS cipher suites that provide PFS (which are the only ones allowed for HTTP/2 and the only ones present in TLS1.3), which mean that the private key for the cert is useless as soon as the cert expires and cannot be used for retroactive decryption even while the cert is valid.