On Wed, 05 Sep 2007 10:06:10 -0400 Joe Maimon <jmaimon@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 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, http://www.cs.columbia.edu/~smb