"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 [EMAIL PROTECTED]
