PKI operators anyone?
Steven M. Bellovin
smb at cs.columbia.edu
Wed Sep 5 19:29:36 UTC 2007
On Wed, 05 Sep 2007 10:06:10 -0400
Joe Maimon <jmaimon at ttec.com> wrote:
> 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
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
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
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, http://www.cs.columbia.edu/~smb
More information about the NANOG