5 ms·

Having expiring certificates/key rotation might be a net negative: if you keep the private key secure, there is no need to rotate it, and it avoids a lot of has

by devit 6y ago

Having expiring certificates/key rotation might be a net negative: if you keep the private key secure, there is no need to rotate it, and it avoids a lot of hassle. Also, if you have a revocation mechanism, then rotation doesn't add that much for keys that are only used for signing and not for encryption (like the CA keys). Of course in some cases like domains it's necessary since the domain can be transferred, but this is solvable by DNSSEC+DANE.

gregmac 6y ago
It's a good point. At any given time, the key is either compromised or it's not. And you may or may not know either way. If it's compromised, and you know, then it should be revoked -- if your only mechanism to revoke it is waiting some amount of time (several days, months, or even a decade) you have a pretty big problem. If you don't have a way to detect if it's compromised, rotating a precaution almost makes sense -- but then the valid time should be very short. I'm not exactly sure how short, but definitely the decade or two used for CA certs is too long. Make it shorter than a year and automated renewal becomes necessary, but if you have that mechanism why not check for revocations? The only other reason I can think of to expire non-compromised certificates is to force them to be regenerated to use newer signature algorithms, but even that's difficult to predict. We're currently using SHA-2 for PKI, but is that still going to be reasonable in 5, 10 years? Someone could figure out a potential weakness at any time, which would start the move to something else.
- tialaramex 6y ago
  What we're talking about here are trust roots and one of the things people usually get wrong when they try to draw a diagram of how this works is they draw certificates as nodes and then just connect those nodes together with abstract lines. Actually the correct mental model is a graph of public keys and the lines between them (joining two nodes directionally) are the certificates. So although we traditionally handle the root trust set as a bunch of self-signed certificates, those certificates are largely unimportant, what's vital is the public keys baked inside them. As a result what makes older roots obsolete is not a signature algorithm, but the type and size of key chosen when they were created, that key is in a very real sense the root. This AddTrust root for example was 2048-bit RSA. You can use that size of RSA key today for your funny cat video site, no problem, but it's clearly an inadequate choice for a CA root. Fortunately roots like this are gradually expiring. If I figure out how to build a machine that can break 2048-bit RSA keys for $10M per key it makes no sense to target your cat videos. But a CA root is an attractive target. So we'd like to have more margin for the roots not the same or less. Some years ago Mozilla finally prohibited 1024-bit RSA keys in roots. Some of the oldest roots in the business were 1024-bit RSA, which today would not be considered acceptable even on your cat video site, but when those roots were created 1024-bit RSA seemed safe enough. In 5-10 years you'd probably want as much as possible for roots to be the more compact elliptic curve public keys, maybe there will be some better (more secure) curves in use by then, maybe not.
- GoblinSlayer 6y ago
  I'd say sign the next root certificate with previous root key, then you can rotate root key automatically. Browser update works the same way: you download new browser with new root certificate authenticated by previous root key.
  - WorldMaker 6y ago
    Most roots are required to be cross-signed today by all the major browser and OS vendors. What you have is a classic web of trust issue because it's the new key that has the signatures attached so you could take the new key/certificate at its word, but if the problem is the previous root expiring, how do you trust that the new root certificate was signed by the previous root before it expired? You can't trust the now expired root can you? If you restrict it to the subset of time where both roots are unexpired, you have the exact same problem as the intermediate game that the BBC has to play in the article.
    - GoblinSlayer 6y ago
      Same as with the browser update: you receive it before the previous certificate expired.
      - WorldMaker 6y ago
        Most of this article is about the pain caused by that we cannot assume devices will update in years. There's no window you can set for both certificates to be valid side-by-side that will be long enough to update every device. Again, roots are already cross-signed and the article points out they still take 2+ years to pass other validity checks for root adoption. Even if they "virally" propagated in this manner after all those checks passed, there are plenty of devices that are only powered on once a year or less; there are a lot of devices whose support lifetimes for any upgrades at all are less than 2 years (that's a specific call in the article: we need security support lifetimes extended to decades at least, probably). If they propagate "virally" you have a lot of questions of whether or not a device will even see that there is an updated certificate. Not every user or device visits a web page in a certificate chain to any given root routinely much less ever. Comments to this article even point out that there is a semi-viral update process already in place in most browsers called AIA chasing, where certificates may point to URLs to look up their parent authorities, and Mozilla intentionally doesn't AIA chase because it's very definitely a privacy risk, even if you don't agree that it is a security risk (bad certificates sending you to bad URLs). The security risk is why the browsers that do AIA chasing only allow it for intermediate certificates and will not trust new roots found by AIA chasing.
ec109685 6y ago
If you aren’t rotating certificates regularly, then when you do need to rotate it, you won’t have a procedure to do so and clients might do things like assume they will never be rotated.

by devit 6y ago

gregmac 6y ago

It's a good point. At any given time, the key is either compromised or it's not. And you may or may not know either way. If it's compromised, and you know, then it should be revoked -- if your only mechanism to revoke it is waiting some amount of time (several days, months, or even a decade) you have a pretty big problem. If you don't have a way to detect if it's compromised, rotating a precaution almost makes sense -- but then the valid time should be very short. I'm not exactly sure how short, but definitely the decade or two used for CA certs is too long. Make it shorter than a year and automated renewal becomes necessary, but if you have that mechanism why not check for revocations? The only other reason I can think of to expire non-compromised certificates is to force them to be regenerated to use newer signature algorithms, but even that's difficult to predict. We're currently using SHA-2 for PKI, but is that still going to be reasonable in 5, 10 years? Someone could figure out a potential weakness at any time, which would start the move to something else.

tialaramex 6y ago
What we're talking about here are trust roots and one of the things people usually get wrong when they try to draw a diagram of how this works is they draw certificates as nodes and then just connect those nodes together with abstract lines. Actually the correct mental model is a graph of public keys and the lines between them (joining two nodes directionally) are the certificates. So although we traditionally handle the root trust set as a bunch of self-signed certificates, those certificates are largely unimportant, what's vital is the public keys baked inside them. As a result what makes older roots obsolete is not a signature algorithm, but the type and size of key chosen when they were created, that key is in a very real sense the root. This AddTrust root for example was 2048-bit RSA. You can use that size of RSA key today for your funny cat video site, no problem, but it's clearly an inadequate choice for a CA root. Fortunately roots like this are gradually expiring. If I figure out how to build a machine that can break 2048-bit RSA keys for $10M per key it makes no sense to target your cat videos. But a CA root is an attractive target. So we'd like to have more margin for the roots not the same or less. Some years ago Mozilla finally prohibited 1024-bit RSA keys in roots. Some of the oldest roots in the business were 1024-bit RSA, which today would not be considered acceptable even on your cat video site, but when those roots were created 1024-bit RSA seemed safe enough. In 5-10 years you'd probably want as much as possible for roots to be the more compact elliptic curve public keys, maybe there will be some better (more secure) curves in use by then, maybe not.
GoblinSlayer 6y ago
I'd say sign the next root certificate with previous root key, then you can rotate root key automatically. Browser update works the same way: you download new browser with new root certificate authenticated by previous root key.
- WorldMaker 6y ago
  Most roots are required to be cross-signed today by all the major browser and OS vendors. What you have is a classic web of trust issue because it's the new key that has the signatures attached so you could take the new key/certificate at its word, but if the problem is the previous root expiring, how do you trust that the new root certificate was signed by the previous root before it expired? You can't trust the now expired root can you? If you restrict it to the subset of time where both roots are unexpired, you have the exact same problem as the intermediate game that the BBC has to play in the article.
  - GoblinSlayer 6y ago
    Same as with the browser update: you receive it before the previous certificate expired.
    - WorldMaker 6y ago
      Most of this article is about the pain caused by that we cannot assume devices will update in years. There's no window you can set for both certificates to be valid side-by-side that will be long enough to update every device. Again, roots are already cross-signed and the article points out they still take 2+ years to pass other validity checks for root adoption. Even if they "virally" propagated in this manner after all those checks passed, there are plenty of devices that are only powered on once a year or less; there are a lot of devices whose support lifetimes for any upgrades at all are less than 2 years (that's a specific call in the article: we need security support lifetimes extended to decades at least, probably). If they propagate "virally" you have a lot of questions of whether or not a device will even see that there is an updated certificate. Not every user or device visits a web page in a certificate chain to any given root routinely much less ever. Comments to this article even point out that there is a semi-viral update process already in place in most browsers called AIA chasing, where certificates may point to URLs to look up their parent authorities, and Mozilla intentionally doesn't AIA chase because it's very definitely a privacy risk, even if you don't agree that it is a security risk (bad certificates sending you to bad URLs). The security risk is why the browsers that do AIA chasing only allow it for intermediate certificates and will not trust new roots found by AIA chasing.

ec109685 6y ago

If you aren’t rotating certificates regularly, then when you do need to rotate it, you won’t have a procedure to do so and clients might do things like assume they will never be rotated.