John Curran wrote:

At 10:06 AM -0400 9/5/07, Joe Maimon wrote:

...

80 years for the root, 4096bit key 35 years for the policy, 4096bit key 15 years for the issuing, ?bit key <=5 years for the issued certificates.

Good idea? Bad Idea? Comments?

Joe -

What's the implications of a single issued certificate being cracked, and again for one of the root/policy/issuing set?

There's quite a bit of speedy hardware out there today (particularly if you count things like repurposed video processors) and 5 years is a *very* long time in our industry. You can actually hunt down the CPS for most public CA's, and I think you'll find that they put up with the "loads of fun every 11 months or so..."

However, for them the implications of a compromised issued cert is potential customer liability, and for an the issuing certificate or above is basically loss of their confidence in their entire business of being a CA. You have to assess the implications based on the expected certificate use for your CA.

Hope this helps, /John

Sounds like what you are saying is that creating validity periods based on expected cracking time is an excerise in futility then. I dont see verisign roots expiring every five years.

On Wed, 5 Sep 2007, John Curran wrote:

...

I dont see verisign roots expiring every five years.

I believe that they're on 30 years or so for the root CA certificates, and shorter periods for the intermediates.

Commercial PKI expiration times are mostly based on how frequently you must pay the CA more money whether or not the certificate's private key was compromised. If a commercial PKI charges you $500 each year to renew a certificate, instead of $500 every two years, the commercial PKI has doubled its revenue. You could always revoke a certificate's private keys sooner in the event its key is compromised. In the event a certificate is compromised Certificate Revokation Lists (CRL) lifetimes, not the certificate's lifetime, determines how big the exposure window for a compromised certificate. If you re-issue (and check) CRL's daily for 10 year certificates, your exposure is a day, not 10 years. In the event a CA is compromised, how quickly you can revoke the CA's trust, not the CA's certificate lifetime determines the exposure window. Commercial CA roots changed to very long life times not because they are more "secure" (insert hand-waving about bits and signing ceremony) but because of the pain of frequently updating them. If you can remove a CA's root from your trust hierarchy within a day for a 100 year CA root, your exposure is a day, not 100 years. The "valid dates" in the certificates are pretty much a red-herring; because the actual threat analysis should really be based on other factors. Most certificate private keys are compromised not because someone figured out how to brute-force the multi-thousand bit keys, but because the computer and all the private keys it could access were compromised by random bits of malware.

private reply... I'm sitting in a building with bunches of root CA's... At 1:22 PM -0400 9/5/07, Sean Donelan wrote:

On Wed, 5 Sep 2007, John Curran wrote:

...

...

I dont see verisign roots expiring every five years.

I believe that they're on 30 years or so for the root CA certificates, and shorter periods for the intermediates.

Commercial PKI expiration times are mostly based on how frequently you must pay the CA more money whether or not the certificate's private key was compromised. If a commercial PKI charges you $500 each year to renew a certificate, instead of $500 every two years, the commercial PKI has doubled its revenue.

I was referring to the root CA certificate, not the ones downsteam issued to customers. All of verisgn's roots (class 1,2,3,4) expire in 2036.

You could always revoke a certificate's private keys sooner in the event its key is compromised.

In the event a certificate is compromised Certificate Revokation Lists (CRL) lifetimes, not the certificate's lifetime, determines how big the exposure window for a compromised certificate.

If you re-issue (and check) CRL's daily for 10 year certificates, your exposure is a day, not 10 years.

In the event a CA is compromised, how quickly you can revoke the CA's trust, not the CA's certificate lifetime determines the exposure window.

Absolutely, if you knew of the compromise. Frankly, if someone succeeded in brute force attack, they'd likely be very careful about how to use the result to avoid detection and maximine return.

Commercial CA roots changed to very long life times not because they are more "secure" (insert hand-waving about bits and signing ceremony) but because of the pain of frequently updating them.

Get a competent staff. It's not that hard.

If you can remove a CA's root from your trust hierarchy within a day for a 100 year CA root, your exposure is a day, not 100 years.

The "valid dates" in the certificates are pretty much a red-herring; because the actual threat analysis should really be based on other factors. Most certificate private keys are compromised not because someone figured out how to brute-force the multi-thousand bit keys, but because the computer and all the private keys it could access were compromised by random bits of malware.

Anyone running with a commercial root server online shouldn't be operating a CA. /John

On Wed, 5 Sep 2007, Chris Marlatt wrote:

...

If you re-issue (and check) CRL's daily for 10 year certificates, your exposure is a day, not 10 years.

Isn't this making the assumption that you know there has been a compromise? With the certificate expiring at a shorter interval you're guaranteed that the exposure is a shorter period of time regardless whether you know the certificate is compromised or not. This however also assumes that the method "they" used to compromise the old certificate cannot be used again to compromise the new one in a similar fashion.

Since this is true across all authentication systems, why not have the same validity periods for passwords, PKI certificates, hardware tokens? If you require people to change passwords every 7 days, because you don't know if the password might have been compromised; shouldn't you also change your PKI certificates every 7 days, and your hardware tokens every 7 days because you don't know whether or not they've been compromised? Maybe PKI certificates should be one-time use only, because you never know if they've been compromised. The validity period should be an output of your administrative procedures and risk assessment (really risk acceptance); not an input.

bmanning@vacation.karoshi.com wrote:

...

...

I dont see verisign roots expiring every five years. I believe that they're on 30 years or so for the root CA certificates, and shorter periods for the intermediates.

/John

it was explained to me that the expiry date is after 2038

The verisign root CA public certs I have in my keyring that expire more than 10 years from now expire either 08/01/2028 or 07/16/2036 which is well before 03:14:07 UTC jan 19 2038. Since my arch uses a signed 64bit int for time_t I'm assuming calculations beyond that magic number won't be an issue for validating the contents of my keyring.

--bill

Erik Amundson wrote:

Validity periods aside, we have experimented quite a bit with putting certs on everything we possibly can, and we've found that there are a whole lot of products that can't handle root key sizes above 2048, some can't even handle anything larger than 1024.

Included in the 'can't handle your root' list are several Cisco products (some products can handle 2048, some 1024, some 4096), and many software products that use an older Java version that has a max of 2048.

This has always raised the question: Why do software authors think to implement PKI, but not think that key sizes will eventually grow over time? Seems very short-sighted to me.

Consider the hardware platforms some of these operations run on... It takes a long time to generate 1024 bit dsa keys on a 20mhz motorola 68020. Using them in a key exchange is also expnsive on such hardware... I think it's a safe assumption that there's some planned obsolence where the software and hardware elements of the platform meet in the cryptogrphic realm.

I guess the option to choose for full interoperability is 1024 keys on all certs, but that is at a sacrifice of security on your higher-level certs...

- Erik Amundson

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Joe Maimon Sent: Wednesday, September 05, 2007 9:06 AM To: North American Networking and Offtopic Gripes List Subject: PKI operators anyone?

MS-PRESS recommended design guidelines for multi-tier PKI systems for validity periods are along the lines of

8 years for the root 4 years for the "policy" 2 years for the "issuing" 1 year for the issued certificate

This is ostensibly due to fears of brute force cracking of the private keys over the root key's validity period.

Accompanied with this recommendation is one for key lengths of

4096 for the root 2048 for the policy 1024 for the issuing and for the issued.

I have found the downside to this: Constant renewals every single year of either minor or major impact.

While MS-AD pki client implementations seem to handle most of the (except for the root) resigning just fine, external implementation struggle with some details, such as "chaining up to the root" trusting (thereby only requiring them to trust the root cert) and such as trusting two different certs (for an issuing CA that gets resigned) but that have the same common name, hence loads of fun every 11 months or so.

I am about to recommend a re implementation along these lines

80 years for the root, 4096bit key 35 years for the policy, 4096bit key 15 years for the issuing, ?bit key <=5 years for the issued certificates.

Good idea? Bad Idea? Comments? Are all pki client implementation in the wild 4096bit compatible?

Thanks in advance,

Joe

On Wed, 05 Sep 2007 15:43:06 -0400 Joe Maimon <jmaimon@ttec.com> wrote:

Steven M. Bellovin wrote:

...

The question about root key lifetime turns not just on the security issues but on how easy it is to change the root key, either routinely or in event of a compromise. To a first approximation, no certificate acceptor *ever* changes its notion of root keys. In that case, the question is how many acceptors you have, what their lifetime is, and how easily you can be one of the rare people who does change the root. That's why browsers have long-lived certificates built in -- that list rarely changes. You suggest an 80-year lifetime for your root key. How many of your current devices do you expect to be using in 80 years? I thought so... Hopefully none, at half-life. Thats the point.

I'd be surprised if very many devices lasted more than 10 years.

...

...

Beyond that, at this point I would not issue any certificates that expire after 03:14:07 UTC on Jan 19, 2038. Doing otherwise is just asking for trouble. The reason is left as an exercise for the reader. This is actually a good point. Epoch rollover? Are you suggesting that any cert set to expire after the epoch may tickle issues now?

I think the odds of trouble are very high. A naive implementation will convert the expiration date to a time_t -- a signed int, as best I can tell, on many platforms -- and compare it to time(NULL). To such code, very long-lived certificates have already expired. (Aside: somewhere at home, I have a T-shirt that says, roughly, "Y2K? No problem. Jan 19, 2038? Help!") I'm sure that some code does it properly today. I'm morally certain that other code doesn't... --Steve Bellovin, http://www.cs.columbia.edu/~smb