Ok let me rephrase my original question: Why would someone trust a cert chain of length 3 less then they would a cert chain of length 2? I see software (like apache) that have a tunable acceptable-cert-chain-length parameter. Why wouldn't you just trust any cert chain length?
cj ----- Original Message ----- From: "Charles Cranston" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 04, 2003 2:32 PM Subject: Re: Certificats : chain > > In practice it's less secure to have a flat hierarchy of > > certs. Having at least three tiers (a root CA used only > > to sign CA certs, subsidiary CAs, and "user" certs) > > allows for managing expiry, etc. without having (manually) to > > confer trust on a new, self-signed cert -- which is > > the most significant security decision one can make in > > PKI. > > > But, as Dennis Miller sez, "I dunno, that's just my opinion, > > I may be wrong." > > > Yeah, my boss has stars in his eyes from the snake oil from the > cren/hepki folks about sealed and escrowed root certificates etc. > > AFAICD the security exposure is about the same until you have a > functional revocation infrastructure in place. For this reason: > > Consider a flat heirarchy > > ARoot > | > v > ACert > > and a non-flat heirarchy > > BRoot > | > v > BInter > | > v > BSigner > | > v > BCert > > (strangely enuf, B is just what our PKI looks like :-) > > the danger is that if the private key for BSigner is compromised > the adversary can sign bogus BCert certificates, just as if the > private key for ARoot is compromised the adversary can sign bogus > ACert certificates. > > What the heirarchy guys will tell you is that in case B you can > just use the private key for BInter to make a new BSigner2 and > you don't have to make every user browser go load a new copy of > BRoot (remember BInter and BSigner are ONLY IN THE SERVERS which > are presumably more controllable and easier to update than sending > all your thousands of users off to get a new BRoot). > > However, unless and until you can revoke BSigner, the adversary > can STILL put up bogus servers with his own bogus BCert certificates. > > I don't see any way around this. Maybe I'm wrong? > > -- > > Charles B. (Ben) Cranston > mailto:[EMAIL PROTECTED] > http://www.wam.umd.edu/~zben > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
