Iang, you missed commenting on this flamebait in Diffie's comments:
"When you look at today's security threats, what worries you the most?
Diffie: The spread of Windows systems into critical infrastructure is most concerning. If our infrastructure comes under attack, this could lead to serious failures. I'm talking about the world infrastructure. We're so intertwined when you consider things like banking, airlines and government. A big attack could happen, there would be serious global consequence and you would have a very hard time telling where it's coming from. If you had an event that affected air traffic and power it would be a very uncomfortable world to live in."
Couldn't be a better reason why http://www.rayservers.com/ exists. Sorry for the shameless plug, but it has been my opinion for a long time that Windows is unfit for business. It requires careful lock down to even be allowed as a desktop environment...
Posted by rayservers at April 24, 2005 12:59 PMthere is my standard refrain ... there are asymmetric cryptograph technology, publi/private key business process, and trusted third party certification authority business process.
normal business process/contracts have relying party paying (and/or with contracts) with certification authorities.
in the TTP business model ... the key owners are paying the TTP/CAs and not the relying parties ... even tho it is the relying parties that are depending on the TTP/CA activity. As a result there is no contractual and/or other legal obligation that the TTP/CA has done anyhting for the relying party.
an issue with most TTP/CA business model is that it is inconsistant with most standard business operations (i.e. the people dependent on TTP/CA operation, aren't paying for TTP/CA operation).
Of course the other issue is with the digital certificates which were devised as a solution for the offline email model of the late 70s and early 80s ... sepcifically where the receiving party had no previour contact and/or communication with the sending party ... and had no other means of establishing the bonifides of the sender in real time. This target environment was never very significant to begin with and has gotten much smaller in the interim.
various and sundry posts about SSL certs
http://www.garlic.com/~lynn/subpubkey.html#sslcert
misc. posts about certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#certless
recent thread in comp.security.misc on "what is a Certificate"
http://www.garlic.com/~lynn/2005g.html#0
http://www.garlic.com/~lynn/2005g.html#1
http://www.garlic.com/~lynn/2005g.html#3
Two quick comments: First, I'm not clear on what Whitfield Diffie means by "It's fundamentally a capital development problem." Is he implying that the fundamental problem is that people aren't spending enough on PKI products and services? If so, then my response would be that businesses don't generally do capital investments unless they have a clear goal in mind and some sort of reasonably justifiable ROI estimate. I presume that if businesses aren't spending on PKI currently it's because neither of those factors is present.
Second, regarding Diffie's comment "The [US] government uses quite a bit of [PKI]." This is certainly true, as I well know from being personally involved in this while at Netscape. However I think government use of PKI is a special case. First, government agencies don't worry that much about ROI. Second, the major US goverment PKI deployment is in DoD, and arguably in that deployment PKI was not the be-all and end-all, but rather was piggybacked on an effort to standardize ID cards across DoD (fragmentation of DoD ID systems being a real problem, historically), with those cards then also being used as a convenient vehicle to support standardized facility access, certificate-based authentication, etc. (Google for "Common Access Card" for more information on this program.)
I forgot to add a minor correction: I have corresponded with the Konqueror folks about their using the Mozilla CA list and policy as a guide to what they do. However I have never had discussions with anyone from Opera; if they do indeed intend to leverage the Mozilla CA list and policy then that's news to me.
Posted by Frank Hecker at April 24, 2005 09:14 PMA point frequently raised is that digital certificates were designed for offline operational environment where the relying party had no prior experience with the individual and no recourse to timely information about the individual ... aka a digital signsture could be presented along with a digital certificate ... the relying party could validate the digital signature with the public key from the digital certificate and then rely on whatever other contents of the digital certificate to determine the next course of action (permissions, authorization, etc).
In an online system (as opposed to an offline paradigm), some sort of online account would contain information as to permissions and authorizations as well as a copy of the public key (as well as potentally other information, included aggregated information, like current account balance). In an online system, instead of relying on the contents of a stale, static digital certificate ... the relying party would rely on some real-time, online information.
An example is door badge access systems (whether or not implementing asymmetric key cryptograph technology). The old-fashion and/or low-value infrastructurese have relied on authentication and permissions purely being determined by the local door mechanics w/o any recourse to any online, real-time information (i.e. you have an employee badge that indicates you are probably a valid employee ... and therefor can gain entrance ... where the door doesn't actually care which specific employee you might actually be).
More modern systems, especially when anything of value is involved have typically moved to online, real-time systems where authentication and permissions provide determination (as well as logging and potentially activity pattern analysis). An example, for situations of value, not only does the access control system want to know that you may be a valid employee ... but have a real-time audit trail of which valid employee ... and furthremore be able to update the online permissions database in real time ... potentially revoking permissions. However, when you have online, real-time information, then information from a stale, static certificate becomes redundant and superfluous.
Posted by Lynn Wheeler at April 25, 2005 12:22 AMHola !
> A running joke is that whatever year we're in is "The Year of PKI,"
>meaning the technology has yet to live up to its hype. ..
I don't know if I follow this mate...
public keys are used on - to begin with - ordinary SSL web pages right ?
ie, every time in your life, three times an hour, you go to a https web page -- that is "PKI" - right?
ie, every single https transaction that is done on the web, every single use of a credit card, every single online stock trade, porno viewing, online casino action, every time someone looks at their bank balance, every transaction amazon and every online retailer has ever made, every egold spend ever etc etc --
every single such event, is, a use of "PKI"
Is that right -- or am I mixed up?
If so -- how could it possibly be any more successful than it is ???
I don't get that !
Jape,
well, yes, but only superficially so. What Diffie is talking about is the pervasive use of PKI as a sort of fundamental layer in well developed applications. There are none of those to discuss, for very good reasons - PKI sucks when it comes to the actual engineering.
Secure browsing is the canonical example; but even there on anything other than the number of ecommerce transactions, it is a failure. Nobody can use it without going through lots of hoops, you will recall your own experiences with putting 1mdc into the SSL world - it took what? a year for you to get around to putting the cert into place? And, who would care if your cert got switched off? You've only got it there because if you didn't people would go "tut, tut..." (although by now you might be getting to the point of worrying about sniffing attacks on passwords, but bear in mind that these are easily defeated by non-PKI means).
SSL should just switch on and run. Certs should be created and used on the fly, and migrate up through confidence by use of CAs. None of this is done; a much better example of the failure of PKI is S/MIME which is in every graphical email client, but is never used. Why? Because it uses PKI which comes with all this paper baggage that breaks email's concepts totally.
Posted by Iang at April 25, 2005 08:15 AMindeed, the only reason I bothered, was because of the existence of http://geotrust.com/ .. you know, they destroyed all that "checking" idiocy and "now anyone can get a cert". (they're big "security check" is they send an email, or some such)
> And, who would care if your cert got
>switched off? You've only got it there because if you didn't people
>would go "tut, tut..."
No, that's not the reason. (My reason as an operator is even WORSE for PKI !)
I want encrypted communications. I couldn't give a fart about the idiotic "trust" aspect of certs, which is laughable.
Thus -- it is true that you can just roll your own cert and use that, right. That works perfectly, of course.
BUT, the only downside is that in browsers, that sets off a ludicrous "not from a trusted issuing authority!"
This is a non-starter on a consumer site, as, obviously, 99% of people have a low IQ and can't handle confusions like that, on top of having to dial a modem, etc.
So, in the current milieu you do indeed need a "proper" cert.
Again, the "geotrust" people seem to have totally broken down all this nonsense, via their wink-wink authorization strategy ... thank goodness. Hence, I got a geotrust cert.
(I think the INFORMATIOn in it is specifically nonsensical, to make fun of the whole process, which is funny!)
>(although by now you might be getting to the point of worrying about
>sniffing attacks on
>passwords, but bear in mind that these are easily defeated by non-PKI means).
>
>SSL should just switch on and run. Certs should be created and used
>on the fly,
Yes, I utterly and totally agree with you 5000%. (thats a lot of agreement!)
I totally understand now .............
thanks for clearing me up !
Posted by JP! at April 25, 2005 01:12 PMwe had worked on the original e-commerce implementation with this small client/server startup in menlo park who wanted to be able to do payment transactions. in the year we worked with them, they moved from menlo park to mountain view and changed their name from mosaic to .... a couple past postings
http://www.garlic/~lynn/aadsm5.htm#asrn2
http://www.garlic/~lynn/aadsm5.htm#asrn3
total trivia question ... who already owned their new name and gave it up so they could use it for their new name?
in any case, here is recent posting about widespread e-commerce vulnerability as SSL is commonly used
http://www.garlic.com/~lynn/2005g.html#1
the original idea was you typed something in and it was cross-checked to be the same domain name provided in a (validated) digital certificate provided by the webserver you are talking to.
however, most e-commerce sites found SSL overhead to be too expensive ... so they only used SSL for the "payment" portion of the shopping experience. You get to the check-out step ... and you hit a "payment" button (where you don't actually type in something) and it invokes SSL. Since the website (you are talking to) is providing both the URL (as part of the button) and the SSL certificate .... don't you think that if they were fraudulent ... they would make sure that the URL generated by the "payment" button matches the domain name in the SSL certificate (that they also provide)?
Crooks can obtain perfectly valid domain names ... and the only real requirement for a SSL domain name certificate is that you own the domain name that the SSL certificate is being requested for. Know all you have to do is a little DNS poisoning to point clients at a fraudulent website (during the process that isn't protected by SSL).
That is a separate kind of vulnerability ... from that of domain name hijacking ... where the crook convinces the domain name infrastructure that there is a new domain name owner. Then the crook applies for a SSL domain name certificate ... and since they match what is on file for the domain name ownership ... a new SSL domain name certificate is issued to the wrong entity.
In the first case, they get a valid domain name and a valid SSL certificate for that domain ... and then do a little DNS poisoning to redirect clients to their fraudulent website where SSL isn't invoked until payment phase ... and it is invoked by a payment button that supplies the domain name that will match the certificate provided.
In the second case, the crook hijacks the domain name and gets a new SSL certificate for that domain.
misc & sundry other posts about SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
PKI has both marketing and technical meanings.
The technical meaning is Public Key Infrastructure. I define this to mean the infrastructure (i.e. supporting institutions, services and technology) necessary for public key cryptography to work in a particular application. For applications like making e-commerce purchases without allowing people to sniff your credit card numbers, the X.509 CA PKI works reasonably well. For applications like secure email it is not so convenient, and something like the PGP Web Of Trust works better. Yes, I see the WOT as a PKI, by definition.
Some applications can do fine with unauthenticated DH agreement, and they don't need much if any PKI. SSH adds a cache for recent keys, and the only problem is that it trains people to ignore key-change warnings, so the cache doesn't work as well in practice as it does in theory.
From the marketing perspective, PKI usually means X.509 client certificates in a corporate or institutional environment. This has been successful in some narrow deployments, and probably Diffie is predicting that it will eventually come into more widespread use.
Posted by Cypherpunk at April 27, 2005 01:54 PM