Re: Public Key Infrastructure: An Artifact...
as pure asside ... any SSL server certificate signed by any CA in my browswer's
CA list is acceptable.
for list of current valid signing CA's in a typical browswer see:
http://www.garlic.com/~lynn/aepay4.htm#comcert14
http://www.garlic.com/~lynn/aepay4.htm#comcert16
my broswer makes no distinction on which CA signed what ... and/or even what
they signed. If I get
a certificate signed by any CA in my browswers list that says foo.bar ... and I
think i'm connecting
to foo.bar ... then the SSL connection will go thru.
given that the supposed justification for SSL certificates is weaknesses in the
domain name infrastructure integrity ... and they beef up the domain name
infrastructure integrity (in part so that SSL certificate issuing operations ...
like any from the above list ... can rely on domain names not having been
hijacked) ... then it eliminates that as a business case & justification for SSL
certificates.
There are a lot of short-comings of the existing SSL certificate infrastructure.
To a large extent, most PKI definitions are purely hypothetical (there is the
line someplace, in theory there is no difference between theory and practice,
but in practice there is) ... trivial example is that most PKI definitions
include things like CRLs for dealing with revoked or compromised
certificates/private keys ... and yet the SSL infrastructure doesn't have any of
that in it (even tho client checking of server SSL domain certificates accounts
for 99.999999% of all such PKI operations that occur in the world today).
Ben Laurie
On Mon, 20 Nov 2000 Lynn.Wheeler@firstdata.com wrote:
as pure asside ... any SSL server certificate signed by any CA in my browswer's CA list is acceptable.
my broswer makes no distinction on which CA signed what ... and/or even what they signed. If I get a certificate signed by any CA in my browswers list that says foo.bar ...
I think that one of the major problems with PKI is the "binary-ness" of it. Everything gets shoveled into "acceptable" or "not acceptable" at the end of the process, but I don't think it's appropriate in trust decisions to have stuff shoveled into "acceptable" and "not acceptable" piles at the very beginning. We can't give a numeric score to the degree of trust we place in a CA. There's no protocol for exchanging information about breaches in trust regarding particular certs, so we can't have a policy for auto-updating our trust model. If I get a spoofed cert from a CA, and notice it, I ought to be able to downgrade the trust in that CA - without necessarily removing ALL trust in that CA. Furthermore, my system ought to pass along the news about the spoofed cert, along with the signature that proves it came from that CA, so that other systems can do the same. "Gossip" is really the only way a robust trust model can work. systems have to at least be ABLE to notify and inform one another when there's a breach of trust involving a CA, and different people have to be able to set the threshold for trust at different points. Bear
At 11:40 AM -0800 11/20/00, Ray Dillinger wrote:
On Mon, 20 Nov 2000 Lynn.Wheeler@firstdata.com wrote:
as pure asside ... any SSL server certificate signed by any CA in my browswer's CA list is acceptable.
my broswer makes no distinction on which CA signed what ... and/or even what they signed. If I get a certificate signed by any CA in my browswers list that says foo.bar ...
I think that one of the major problems with PKI is the "binary-ness" of it. Everything gets shoveled into "acceptable" or "not acceptable" at the end of the process, but I don't think it's appropriate in trust decisions to have stuff shoveled into "acceptable" and "not acceptable" piles at the very beginning.
We can't give a numeric score to the degree of trust we place in a CA. There's no protocol for exchanging information about breaches in trust regarding particular certs, so we can't have a policy for auto-updating our trust model.
These problems with binary trust in hierarchical models ("trust this cert because the highest node said to trust it") have been dealt with many, many times. Cf. my own articles on probabalistic networks, belief networks, and Dempster-Shafer measures of belief. I don't even see how thoughtful people can continue to believe this is still a debatable issue. Those pushing X.509 and similar hierarchical systems have their own statist axes to grind...and they like the commission they get off of each of the King's certs. --Tim May -- (This .sig file has not been significantly changed since 1992. As the election debacle unfolds, it is time to prepare a new one. Stay tuned.)
So what is the acceptable threshold of errors? 1 in a 1000000? What if that 1 is the invalid certificate that allows your bank account to be compromised. CA's should either be 100% or 0% trustworthy. I do agree that there needs to be a protocol to allow CA's to compare databases of certificates for mismatches etc that might reveal an attempt at publishing a fraudulent certificate. Gripp -----Original Message----- From: owner-cryptography@c2.net [mailto:owner-cryptography@c2.net]On Behalf Of Ray Dillinger Sent: Monday, November 20, 2000 11:41 AM Cc: cryptography@c2.net; cypherpunks@cyberpass.net Subject: Re: Public Key Infrastructure: An Artifact... On Mon, 20 Nov 2000 Lynn.Wheeler@firstdata.com wrote:
as pure asside ... any SSL server certificate signed by any CA in my browswer's CA list is acceptable.
my broswer makes no distinction on which CA signed what ... and/or even what they signed. If I get a certificate signed by any CA in my browswers list that says foo.bar ...
I think that one of the major problems with PKI is the "binary-ness" of it. Everything gets shoveled into "acceptable" or "not acceptable" at the end of the process, but I don't think it's appropriate in trust decisions to have stuff shoveled into "acceptable" and "not acceptable" piles at the very beginning. We can't give a numeric score to the degree of trust we place in a CA. There's no protocol for exchanging information about breaches in trust regarding particular certs, so we can't have a policy for auto-updating our trust model. If I get a spoofed cert from a CA, and notice it, I ought to be able to downgrade the trust in that CA - without necessarily removing ALL trust in that CA. Furthermore, my system ought to pass along the news about the spoofed cert, along with the signature that proves it came from that CA, so that other systems can do the same. "Gossip" is really the only way a robust trust model can work. systems have to at least be ABLE to notify and inform one another when there's a breach of trust involving a CA, and different people have to be able to set the threshold for trust at different points. Bear
On Mon, 20 Nov 2000 Lynn.Wheeler@firstdata.com wrote:
as pure asside ... any SSL server certificate signed by any CA in my browswer's CA list is acceptable.
for list of current valid signing CA's in a typical browswer see:
http://www.garlic.com/~lynn/aepay4.htm#comcert14 http://www.garlic.com/~lynn/aepay4.htm#comcert16
This is mistifying to me - there are apparently enough in there that it *should* be possible for someone to purchase one or a few and start offering an alternate source of certs. Or has Verisign gone and purchased all of them already? What would happen if one of those private keys were found and made public? I suspect there would be a lot of lawyers and suing and claims of trade secrets made, with significant intimidation of anyone who dared make a cert for themselves rather than paying for one the way the good lord intended. It would, of course, result in no practical loss of security whatsoever, since man in the middle attacks never happen.
given that the supposed justification for SSL certificates is weaknesses in the domain name infrastructure integrity ... and they beef up the domain name infrastructure integrity (in part so that SSL certificate issuing operations ... like any from the above list ... can rely on domain names not having been hijacked) ... then it eliminates that as a business case & justification for SSL certificates.
Yes, getting the public key of the domain as part of the DNS lookup is better engineering all around. It would also be nicer for services like Akamai which spew out different IPs and for the same domain name, and are currently forced to use the exact same private key in every one of those machines.
There are a lot of short-comings of the existing SSL certificate infrastructure. To a large extent, most PKI definitions are purely hypothetical (there is the line someplace, in theory there is no difference between theory and practice, but in practice there is) ... trivial example is that most PKI definitions include things like CRLs for dealing with revoked or compromised certificates/private keys ... and yet the SSL infrastructure doesn't have any of that in it (even tho client checking of server SSL domain certificates accounts for 99.999999% of all such PKI operations that occur in the world today).
Revocation just plain doesn't work. The only practical solution is online verification. -Bram Cohen
On Mon, 20 Nov 2000 cgripp@axcelerant.com wrote:
So what is the acceptable threshold of errors? 1 in a 1000000? What if that 1 is the invalid certificate that allows your bank account to be compromised. CA's should either be 100% or 0% trustworthy. I do agree that there needs to be a protocol to allow CA's to compare databases of certificates for mismatches etc that might reveal an attempt at publishing a fraudulent certificate.
Gripp
For a CA, I'd say 1 in 10^7 requests, tops, would be an acceptable rate of getting spoofed. But if it were for a transaction I was really paranoid about, I might require an error rate of 1 in 10^10 or less. Modulo standard statistical methods regarding sample sizes, of course -- a new CA that's never been spoofed but has only served 10^8 requests, should be regarded as a hell of a lot less reliable than a cert that's gotten spoofed 1000 times out of 10^11 requests, just because of sample sizes and number of significant figures involved. But my point is we don't even have a protocol for swapping and updating information about CA's reliability rates, so there's no way to even *assess* the reliability of our current CA's. We just assume that they are trustworthy, and sometimes we are wrong. They don't actually check much before they issue a cert. Also, they don't really have a way of revoking their certs, so once they realize they've been spoofed they can't really correct it very easily -- the spoofing site can go on presenting its spoofed cert for a full year in most cases before it expires and if the client doesn't contact the CA's keyserver directly the client will never know. I agree with you that CA's should be 100 percent trustworthy. Pigs should be able to fly, too. Bear
participants (5)
-
Bram Cohen -
cgripp＠axcelerant.com -
Lynn.Wheeler＠firstdata.com -
Ray Dillinger -
Tim May