A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Anne & Lynn Wheeler]

Steven M. Bellovin wrote:
> "Unusual CA"?  I'm not sure what a *usual* CA is.
> 
> Just for fun, I opened up the CA list that came with my copy of 
> Firefox.  There are no fewer than 40 different entities listed, many of 
> whom have more than one certificate.  I personally know less than half 
> of them to be trustworthy -- and that's assuming that, say, Thawte, 
> Thawte Consulting, and Thawte Consulting cc are all the same company 
> and I can count that as three different ones.  I had no idea that that 
> the U.S. Postal Service had a CA that was trusted by my browser -- and 
> I dare say that many non-Americans wouldn't trust it at all, on the 
> assumption that it would do whatever the U.S. government told it to do. 

cylink had the contract ... bea had subcontract. usps was going to do 
some sort of in-person verification before issuing the certificate ... 
along the lines of US passports.
http://www.gcn.com/17_24/news/33918-1.html

this dates back to the days when the CA industry was floating business 
cases that there was going to be $100/annum x.509 identity certificate 
for every person in the country (the $20b/annum gift to the CA industry 
story).

there was some rumor that if the gov. wouldn't cough up the $20b/annum, 
then the financial industry was just chopping at the bit to turn over 
$20b/annum to certification authorities. there is a story from the 
period about an offer to a financial institution that if they would 
transmit a copy of the master account database of tens of millions of 
customers to the certification authority ... the certification authority 
would re-arrange the bits in each database entry into this magic format 
called a certificate and return the re-arranged magic bits to the 
financial institution at a mere $100/database entry (nominally overnight 
... but possibly actually several days, maybe only earning the CA a 
measely $1b/day of work).

this overlapped with the realization that identity certificates were 
composed at some point in the past w/o any knowledge of just what 
identity information any future relying parties might require .... as a 
result there was one strategy that it would be necessary to overload all 
identity certificate with every possibly piece of identity information 
so as to cover all possible requirements possibly needed by future 
unknown relying parties.

at the same time, the financial industry was realizing that identity 
certificates represented huge privacy and liability exposures ... and so 
you started to see retrenching by various parties (particularly the 
financial industry) to relying-party-only certificates. misc. past posts 
about relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo

The problem lurking in the background is that fundamentally, the 
certificate design-point is an offline paradigm in a situation where the 
relying-party has absolutely no recourse for obtaining information about 
the origin of the digital signature (so is reduced to operating with a 
letter-of-credit paradigm from the sailing ship era).

This fact was well highlighted in digitally signed payment scenario. A 
bank customer was issued a relying-party-only certificate by their 
financial institution (after registering their public key in the 
financial institution's account record). The customer would then create 
a payment authorization message, digitally sign the message and then 
transmit the message, the digital signature and the bank's 
relying-party-only certificate back to the bank. Since the bank already 
has the customer's public key on file, the first thing it does is 
discard the transmitted certificate and verifies the digital signature 
with the on-file public key.

Another minor annoyance was that typical digital certificate was 
nominally two orders of magnitude (one hundred times) larger than the 
typical 8583 payment message. So not only were the relying-party-only 
certificates redundant and superfluous ... its only apparent purpose was 
to increase transmission payload bloat by a factor of 100 times.

some past posts about browser trusted public key lists:
http://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort 
Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort 
Certificates
http://www.garlic.com/~lynn/2003l.html#27 RSA vs AES



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com