North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: PKI operators anyone?

  • From: Erik Amundson
  • Date: Thu Sep 06 08:58:19 2007

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


-----Original Message-----
From: Joel Jaeggli [mailto:[email protected]] 
Sent: Wednesday, September 05, 2007 2:29 PM
To: Erik Amundson
Cc: Joe Maimon; North American Networking and Offtopic Gripes List
Subject: Re: PKI operators anyone?

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: [email protected] [mailto:[email protected]] 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
>