PKI operators anyone?

Mailman List Mirror (Read Only)
1

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

2

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

3

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.

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

4

John Curran wrote:

5

Sounds like what you are saying is that creating validity periods based on expected cracking time is an excerise in futility then.

No, what I'm saying is that the cracking time likely shorter than
we imagine, and an 80 year root and 15 year issuing certificate
expiration may be considered optimistic by some. Again, it also
depends on what exactly is the consequences of success versus
the maintenance headache.

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

6

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.

7

Stupid question - what percent of deployed software actually does CRLs
correctly?

8

private reply... I'm sitting in a building with bunches of root CA's...

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

9

Sean Donelan 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.

Regards,
  Chris

10

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.

11

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.

12

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.

I think that "brute force" can be ruled out as a threat. There are
other concerns, however.

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.

First -- there is no one right answer. You've got to balance security,
threats, and operational reality. Underlying it all is the question of
what the certificates are for, and what the consequences are if one is
compromised. (I should add that I have no idea what a "policy" or an
"issuing" certificate are. In many situations, two levels instead of
four are perfectly acceptable; again, that depends on your operational
model.)

A certificate serves many different purposes. If the certificate is
used for access control, the issue is whether or not it can be
compromised within its lifetime. If the certificate is used for
signing something, it may need to have a much longer secure lifetime --
for how many years is it necessary to validate the signature? Imagine
a digitally-signed, 30-year mortgage. The signature may need to be
verifiable, by a third party, 30 years hence. Other factors that need
to be considered are the availability and usability of CRLs and the
like.

The real threat to most certificates is compromise of the private key
due to host security failures. This is less of an issue for
hardware-based key-holders (i.e., smart cards), though there are still
risks -- can the attacker induce the smart card to sign the wrong
thing? Also, if your smart card has to keep secrets from the owner --
think of digital cash cards -- you have to worry about physical attacks
(differential power analysis, scanning electron microscopes, etc.) by
the owner.

That said, there has been noticeable progress in factoring. 1024-bit
keys are probably in reach of serious enemies now. I've switched to
2048-bit keys for personal stuff -- not because I perceive a serious
threat, but because I can afford to do the encryptions and
verifications. For key length, the question is "how much security can
you afford"? I can afford more than 1024-bit. The state of hash
function knowledge also worries me -- do we really know enough about
hash function design to be sure that, say, SHA-256 will be
collision-resistant in 30 years?

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...

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.

So -- I haven't answered your questions at all. Instead, I've asked
questions of my own.

    --Steve Bellovin, Steven M. Bellovin

13

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.

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?

14

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, Steven M. Bellovin

15

"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"

Don't forget that Microsoft would like you to buy their OS once every five years or so, not every 80 years.

4 tiers is a bit much; three would work fine in most organizations. IMHO 10/5/3/1 is OK, 10/5/2 for three tier. Issuing certs to clients can be automated via GPO and zero client downtime. It is the renewal upstream to the root CAs by the subordinates which can casue issues and downtimes if not properly managed.

Edward Ray

16

>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

--bill

17

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.

18

This is true, however I find no excuse when the issue is in completely
server-client based Wintel software. Yeah, that's right Java and Cisco
ACS, I'm taking a shot at you!

In that situation you could at least offer a patch or update or registry
hack or kludge or something to make it work. I'm sure my 2.4Ghz Intel
processor in my PC and server can handle many certificates of big key
size.

Erik Amundson