Re: Public Key Infrastructure: An Artifact...
On Mon, Nov 27, 2000 at 10:58:23AM -0800, [EMAIL PROTECTED] wrote: Hi Lynn! problem is that consumer don't normally know that they want to check on a particular merchant's CRL entry until they realize that they want to go to that merchant site. in general, the consumer's aren't going to want keep a local (usenet) database of all CRL entries (however they are distributed) ... so it is more likely the ISP would have to keep all the entries ... pushed into a database ... and let the consumer do an online database lookup of the CRL entries (effectively the local ISP is keeping cached copy of all entries ... and uses usenet as the distribution infrastructure). sometimes, usenet can take several hrs to a day to propogate ... so the person may still want to do an online transaction against the agency that issued a certificate In which case, the local ISP would be considered a "stand-in" ... maintaining a negative file ... and returning positive answers if there isn't a match in the negative file for the online transaction ... in which case the consumer may still want to do another online transactions against the master file (located somewhere in the internet). Given that online transactions are being performed ... then it may even be more straightforward to use domain name infrastructure to manage distribution and management of cached entries. It has a somewhat better online transaction semantics than usenet (already). However, since this is turning into online transaction infrastructure ... it is then possible to eliminate both the certificates and CRLs totally and just use the straight-foward domain name infrastructure. However, caching the revocation data (which DNS would do nicely) means that there needs to be some way for the relying parties to authenticate the cached revocation data. They could authenticate the DNS cache, but that means trusting all those DNS servers. More practically the DNS cache servers could authenticate the data as coming from a trusted DNS server (which is how DNSSEC works now I beleive). But that forces the relying parties to trust that the DNS server that they're getting the revocation data from has done the authentication. And it still doesn't address the issue of Mallet operating an evil DNS-CRL cache which sends out bogus revocation data. It also requires the DNS caches to do the public-key crypto. But, there's a solution- if the DNS servers and caches are sending out revocation data which is signed by the real authority for revocation data (whoever that may be for the application), and the relying parties do the verification, then there's no security problem with the intermediate DNS servers/caches. So, IMHO, signed CRLs serve a purpose. I agree that a cache system like DNS would be nice for CRL distribution but I think that a usenet-type system would be good enough in practice. I don't think that propagation delays are that big a problem in practical use for TLS sites. A CRL would only be issued if a merchant has shown some amount of bad behaviour, or if there's been a key compromise. For bad behaviour, there would likely be some sort of process involved in issuing the CRL- one single report of merchant fraud would not cause an issuer to revoke a cert instantly. So if a merchant goes "bad", there's likely to be quite a delay before they're revoked- notices, appeals, etc. A few hours taken in the distribution of the CRL once the issuer's completed the process isn't going to make the problem noticeably worse. It'd be nice to have instant CRL distribution for key compromise, but most sites will have been running with the compromised key for some time before it's detected. If a site really cares about security after a key compromise, it could just go get a new cert and use that (after fixing the problem that caused the compromise of course). -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.comPGP keyid:E03F65E5
Re: Public Key Infrastructure: An Artifact...
Basically cetificates are an implementation of R/O partial replicated distributed data that were intended to address availability of information in a predominately offline environment. In the SSL server certificates, distribution of CRLs tend to create a problem for consumers because they aren't likely to want to see 99.% of the CRLs distributed and/or they aren't online at the time the CRLs are distributed (and/or if done via email would create a horrible spam issue ... every possible consumer in the world receiving email CRLs from every possile SSL server certificate issuing CA). The other solution is to go online and do real-time checks ... but doing real-time checks invalidates basic design decision trade-offs associated with choosing a R/O partial replicated distributed data implementation in the first place. A number of other efforts have looked at the trade-offs associated with large distributed data implementations and have made various different implementation decisions based on different criteria requirements. Some of the partially replicated data implementations have gone to the trouble if 1) truely offline, R/O replicated data that has low change frequency, and possible adverse effects of dealing with stale data is non-existent or 2) support R/W partial replicated distributed data with various dictionary implemenations keeping track of the "current" R/W owner. However, in the case of both having R/O replicated distributed data and also requiring online access ... creates a situation where the R/O replicated distributed data implementation is redundant and superfulous (except in some scenerios where the packet of R/O replicated distributed data is significantly larger than the transaction to check on its staleness ... aka multi-megabyte documents might be an example). It isn't that you can't have perfect R/O replicated distributed data implementation if there is also concurrent real-time access to the original data ... but that usually invalidates the design decisions trade-offs that justified having a R/O replicated distributed data implemenation in the first place. The degree of redundancy and superfulous becomes more significant as outlined in the SSL server certificate case ... where 1) in large part SSL server certificates are justified to address integrity weaknesses in the domain name infrastructure, 2) SSL server certificate issuing agencies are dependent on the domain name infrastructure as the authoritative source associated with proofing information for issuing an SSL server certificate, 3) correcting integrity weaknesses in the domain name infrastructure (needed by the SSL server certrificate issuing agencies) by registering public keys with domains names, 4) said registered public keys can both a) eliminate integrity weaknesses justifying SSL server certificates and b) be distributed as part of domain name server real time request to the client ... which then can be used in a much more efficient SSL protocol implemenation. A possibly better phrase is that in a large number of cases revokation isn't practical w/o real-time access to the original data ... but real-time access to the original data obsoletes the need for revokation (by obsoleting the necessity for R/O partial data replication which might require revokation). The issue in many scenerios isn't that revokation can't work ... it can work if you have real time access to the original data ... which obsoletes the requirement for R/O partial data replication which in turn obsoletes the requirement for revoking R/O partial data replication. The ideal solution for revokation is somehting of a catch-22 ... the ideal solution for revokation also removes the requirement for revokation (somewhat analogous to the catch-22 for solving the problem that SSL server certificate issuing agencies have with domain name server infrastructure integrity issues ... the solution is also the seed for obsoleting the need for issuing SSL server certificates). Mark Scherling [EMAIL PROTECTED] on 11/23/2000 09:24:51 AM To: Bram Cohen [EMAIL PROTECTED] cc: Lynn Wheeler/CA/FDMS/FDC@FDC, "Arnold G. Reinhold" [EMAIL PROTECTED], Ben Laurie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Public Key Infrastructure: An Artifact... I would like to get further information as to why you don't think revocation does not work? I'll admit that in the case of the revocation of Sun's certificates, it was very apparent that the notification process was weak. The other piece, the browser checking of expired/revoked certificates is non-existent but if you properly set up your application, it "should" check the revocation status of both the CA certificate and the subscriber's certificate. Your thoughts? Bram Cohen wrote: On Wed, 22 Nov 2000 [EMAIL PROTECTED] wrote: the other scenerio that some certificatio
Re: Public Key Infrastructure: An Artifact...
[EMAIL PROTECTED] writes: The other solution is to go online and do real-time checks ... but doing real-time checks invalidates basic design decision trade-offs associated with choosing a R/O partial replicated distributed data implementation in the first place. Have you looked at the design of SPKI CRLs? I think there are possibilities in there that address the difficulties you raise. -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: Public Key Infrastructure: An Artifact...
At 11:40 AM -0800 11/20/00, Ray Dillinger wrote:
On Mon, 20 Nov 2000 [EMAIL PROTECTED] 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.)
Re: Public Key Infrastructure: An Artifact...
On Sun, 19 Nov 2000 [EMAIL PROTECTED] wrote: When the user goes to www.amazon.com, they get a plaintext http redirect to amazon.hackeddomain.com, which does check. Still confused... The original connection to www.amazon.com is an SSL connection, right? We are following an https: URL? (Otherwise, SSL would not even come into the picture.) No, the attacker interferes with the very first connect to www.amazon.com, probably at the DNS level, and that's almost always done plaintext. -Bram Cohen
Re: Public Key Infrastructure: An Artifact...
On Thu, Nov 16, 2000 at 03:53:28PM -0800, Ed Gerck wrote: http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html Public Key Infrastructure: An Artifact Ill-Fitted to the Needs of the Information Society Abstract It has been conventional wisdom that, for e-commerce to fulfill its potential, each party to a transaction must be confident in the identity of the others. This is the law for commerce, except for cash transactions of non-controlled goods. Firearm sales usually require proof of identity (at least) even for a cash transaction. That's a matter of state law - Federal law doesn't (yet) regulate firearm transactions between two residents of the same state where neither is licensed federally as a firearms dealer, so long as the firearms themselves aren't specially controlled (like Class 3 full-auto weapons, or short- barreled rifles/shotguns, etc). Nevertheless, the main point above is wrong, too - commercial law certainly does NOT require parties to be confident about the identity of counterparties. In most circumstances, identity is irrelevant; and even in disputed transactions, it's very rare that identity becomes crucial. Further, the identity of counterparties isn't fixed or decided at the time a contract is formed - one or more of the participants may later want to correct, amend, or restate the contractual listing of the parties, to include or exclude parties who are thought to have greater or fewer assets, or greater or lesser culpability, in order to enhance their chances for successful litigation. There's a persistent superstition among technologists who do ecommerce work that knowing someone's identity is necessary or sufficient to successfully litigate against them - neither side of that assumption is true. It can be the hardest thing in the world to successfully serve a summons and complain on a well-known party - cf. the ligitation against the Scientology head, whose name escapes me at the moment. On the other hand, big companies angry about message-board postings have been filing complaints very successfully against unknown (or pseudonymously named) entities, much to the aggravation of people who believe that their marginally greater understanding of technology makes them somehow unreachable or unaccountable. Even assuming that someone is successfully served with a complaint, that's a long way from winning a lawsuit, which is a long way from collecting on a judgement. Traditional non-legal means of enforcing contracts - like adding the person to a blacklist of "naughty debtors" doesn't depend on any sort of proof of identity or proof that a contract ever existed, or was breached - it's easy (if you're a commercial entity of at least moderate size) to add people you believe owe you money to the credit reporting agencies' databases, whether your target is an individual or a business. The reporting agencies require no proof at all - they'll accept the creditors' representations about the alleged debt, and proceed from there. Identity - and complicated theoretical proofs of identity - are not especially important in commercial law or litigation. It's relatively easy to follow the paths of money and/or goods in commercial transactions - and where it's not, the likelihood of recovery is slim even if the counterparty is well-identified, so litigation is unlikely. Identity does have the advantage of being a very familiar idea, so it's easy to generate and keep certificates about it, which give counterparties a nice warm feeling that they're doing something about the risks they face in a transaction. That feeling is unrelated to what's actually happening, but it does serve to lubricate the wheels of commerce. -- Greg Broiles [EMAIL PROTECTED] PO Box 897 Oakland CA 94604
Re: Public Key Infrastructure: An Artifact...
Greg Broiles wrote: On Thu, Nov 16, 2000 at 03:53:28PM -0800, Ed Gerck wrote: http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html Public Key Infrastructure: An Artifact Ill-Fitted to the Needs of the Information Society Abstract It has been conventional wisdom that, for e-commerce to fulfill its potential, each party to a transaction must be confident in the identity of the others. This is the law for commerce, except for cash transactions of non-controlled goods. Firearm sales usually require proof of identity (at least) even for a cash transaction. That's a matter of state law - Federal law doesn't (yet) regulate firearm transactions between two residents of the same state where neither is licensed federally as a firearms dealer, so long as the firearms themselves aren't specially controlled (like Class 3 full-auto weapons, or short- barreled rifles/shotguns, etc). That is why I wote "usually" -- it may vary. Nevertheless, the main point above is wrong, too - commercial law certainly does NOT require parties to be confident about the identity of counterparties. So, you think that credit-cards deals would not need names or any real-life id, just assets? Surely, the merchant gets paid regardless, even if you use a false name. But this is not the end of id fraud. The bank still goes after the money...and uses the law against fraudulent practices to enforce the cardholder agreement, or criminal statues. If Mr. X uses his wife's credit-card, Mr. X is technically committing id fraud, and wire-fraud. Of course it works most of the time... But when it does not, and someone comes enforcing, someone will ask, did you Mr X, uses Mrs X's credit-card, and represent yourself thereby as Mrs X? Cheers, Ed Gerck
Re: Public Key Infrastructure: An Artifact...
Of course not. Unilateral offers can be made to a defined class of persons and accepted by action thereon. An old principle, but valid still. MacN On Thu, 16 Nov 2000, Greg Broiles wrote: It has been conventional wisdom that, for e-commerce to fulfill its potential, each party to a transaction must be confident in the identity of the others.
Re: Public Key Infrastructure: An Artifact...
Mac Norton wrote: Of course not. Unilateral offers can be made to a defined class of persons and accepted by action thereon. An old principle, but valid still. Yes but the problem faced by e-commerce is what happens when it fails. So, while I agree with you that it is not true that "for e-commerce to fulfill its potential each party to a transaction must be confident in the identity of the others", the practice in e-commerce is that security is based on breaking your privacy! And this is not only in terms of credit checks but also in covert background checks teaming up with law enforcement (as candidly admitted by eBay management in a meeting in DC some months ago). Cheers, Ed Gerck MacN On Thu, 16 Nov 2000, Greg Broiles wrote: It has been conventional wisdom that, for e-commerce to fulfill its potential, each party to a transaction must be confident in the identity of the others.
Re: Public Key Infrastructure: An Artifact...
On Thu, Nov 16, 2000 at 08:11:25PM -0600, Mac Norton wrote: Of course not. Unilateral offers can be made to a defined class of persons and accepted by action thereon. An old principle, but valid still. MacN On Thu, 16 Nov 2000, Greg Broiles wrote: It has been conventional wisdom that, for e-commerce to fulfill its potential, each party to a transaction must be confident in the identity of the others. The quoted text isn't mine - but, to further expand on Mac's comments, it's not even necessary that the offeror's identity be clear to potential acceptors. It's quite likely that many people and organizations are wrong about the assumptions they make about identity - you may think you've bought fast-food from McTacoKing, but it turns you you purchased food from an out-of-state corporation that's a franchisee of another out-of-a-different-state corporation who licenses out their recipes and trademarks to different people. This ambiguity may go both directions - the local McTacoKing may purchase services (like, say, carpet cleaning, or drain cleaning) from yet another locally-held but distantly-registered corporation who's just a franchisee/licensee of widely-recognized trademarks in those fields. It's easy to be sloppy and say that transaction represents a contract between McTacoKing and DrainSuckers - but that's not true at all. It's rare for people to even bother asking about niceties like business form (corporation vs. LLC vs. partnership vs. whatever), much less actually bother to figure out whether what's represented is really true - nobody bothers to call the Secretary of State and ask if the business called "X, Inc." really is a corporation, really is registered, really does have officers, etc., until people start using the words "million" or "billion". Trillions of dollars in small transactions take place without any attention at all paid to identity, in a legally significant sense - people do pay attention to trademarks, but those have only a slight relationship to the legal entitites involved. Even moderately sized-organizations find it useful to divide their operations into a number of legal entities, which may have common owners or have parent/subsidiary relationships - but invariably they hide that complexity behind a nice shiny trademark, because it's just distracting for people to think that "barnesandnoble.com" isn't really the same company as the people who run the bookstore down the street - or that the UPS who ships the books that the online entity sells you isn't the same UPS who sells the online entity the insurance on the safe delivery of that package. It's distracting to think that the entity which places a taxicab company ad in the yellow pages (which have the same logo as the local phone company, but are actually a separate corporation) isn't paid for by the corporation which owns the taxi which drives customers around, which isn't the same as the person who's driving, and may not even be the same company as the one which holds the taxi medallion. And who wants to think about the (lack of) identity between different banks and insurance companies who operate under the same trademarks and in the same office space? If you've got a savings account in a Bank of America branch in California and a checking account in a Bank of America branch in Oregon and a mutual fund account in a Bank of America branch in Oregon, how many different entities have you opened accounts with? 1? Bzzt! 3, or at least that was true before Congress clobbered the Glass-Stegall Act last year. Does that bother the people who cheerfully issue domain names and X.509 certs to various of these different entities? Nope. Does it bother consumers? Nope. Nobody cares, just like nobody cares that individual identities are pretty fluid, too, given that one name can be reused across many different meat things, and a single meat thing may, perfectly legally, use a number of different identies. The relationship between meat-world entities (including their cousins, the entities created by registration with governments or by mutual agreement of participants) and text strings like "John Smith" or "Bill Clinton" or "Bank of America" is not one-to-one but many-to-many, and that's not going to change. The legal system is accustomed to this ambiguity, and deals with it as necessary. Efforts to "fix" this and force people or corporations to identify in some enforceable way the underlying legal entities involved in a transaction are doomed to failure. The flexibility inherent in the ambiguity is important to getting things done - it's not a bug, it's a feature. -- Greg Broiles [EMAIL PROTECTED] PO Box 897 Oakland CA 94604
Re: Public Key Infrastructure: An Artifact...
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote: Bram Cohen writes: In the vast majority of cases, preventing man in the middle attacks is a waste of time. In the sense that, in the vast majority of communications, there is no man in the middle attack being mounted? Yes. Couldn't the same thing be said of cryptography, since in the vast majority of cases there is no eavesdropping? Yes, but it's a less vast majority than the ones for which man in the middle is happening. The point in both cases is that if you construct a protocol which has weaknesses, eventually people may begin to exploit them. And if you build a protocol which is a pain to use, noone will use it. -Bram Cohen
Re: Public Key Infrastructure: An Artifact...
As an aside ... AADS (http://www.garlic.com/~lynn/ ) relies on existing business processes that provide secure bindings in account records ... just adding public key digital signature to existing authentication processes for non-face-to-face and/or face-to-face transactions (i.e. the meaning of what is in the account bindings continues to be what the business processes have defined those meanings to be). existing e-commerce is straight forward because it operates almost totally within existing account-based business processes ... and the business transactions tend to include more complex bindings from the acocunt records (than just authentication) ... things like real-time credit-limit, open-to-buy, running totals, month-to-date and/or year-to-date activity, etc. the original PKI target from the early '80s for offline email authentication was a problem since it mostly any kind of authentication binding processes. "R. A. Hettinga" [EMAIL PROTECTED] on 11/11/2000 11:25:35 AM Please respond to "R. A. Hettinga" [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Digital Bearer Settlement List [EMAIL PROTECTED] cc:(bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Public Key Infrastructure: An Artifact... http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html Public Key Infrastructure: An Artifact Ill-Fitted to the Needs of the Information Society Abstract It has been conventional wisdom that, for e-commerce to fulfill its potential, each party to a transaction must be confident in the identity of the others. Digital signature technology, based on public key cryptography, has been claimed as the means whereby this can be achieved. Digital signatures do little, however, unless a substantial infrastructure is in place to provide a basis for believing that the signature means something of significance to the relying party. Conventional, hierarchical PKI, built around the ISO standard X.509, has been, and will continue to be, a substantial failure. This paper examines that form of PKI architecture, and concludes that it is a very poor fit to the real needs of cyberspace participants. The reasons are its inherently hierarchical and authoritarian nature, the unreasonable presumptions it makes about the security of private keys, a range of other technical defects, confusions about what it is that a certificate actually authenticates, and its inherent privacy-invasiveness. Alternatives are identified. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' For help on using this list (especially unsubscribing), send a message to "[EMAIL PROTECTED]" with one line of text: "help".
