Leichter, Jerry wrote:
It's interesting to follow up on this idea, because it shows just how
profound the problem is. Imagine starting a business that ran a PKI
and did business the old way: You would charge someone *presenting*
an alleged certificate for an "OK". The "OK" would, for the fee paid,
provide insurance against the possibility of fraud. (Presumably, the
fee would be based on the size of the insured transaction and level
of experience and trust you have in the signing party.) It's to
your advantage to have many parties whose signatures you vouch for,
since that's what brings you customers; so you probably don't charge
that side of the business - though it helps someone to have a "high
trust" signature, since their customers will like paying a lower
premium to do assured business with them, so you could charge on
that side in some cases. But, unlike the case today, since your
own money is at stake if you vouch for someone untrustworthy, you
can't just go hand certs out to anyone who shows up at your door.
re:
http://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in message
http://www.garlic.com/~lynn/aadsm26.htm#33 Failure of PKI in messaging ...
addenda
note that merchant interchange fee works this way ... i.e. the merchant
wanting to know whether it gets paid when you present your card
recent posts with some interchange fee references
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high
priority for 2007
http://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a
high priority for 2007
http://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a
high priority for 2007
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a
high priority for 2007
doing the original deployment of what currently has come to be called
electronic commerce,
there was some investigation whether the payment infrastructure would issue
certificates
... since they were already certifying merchants for processing of payment
transactions
(and the digital certificates then become representation of that certification).
As mentioned before, merchants were already paying fairly hefting interchange
fee
to effectively insure consumer transactions ... that would have somewhat
boxed-in/capped
fees for ssl domain name certificate operations ... which weren't providing
anything
... other than a lot of publicity and hype convincing public that they should
feel
good about digital certificates ... previously referenced posting in this blog
http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the
minimum liability, the CA trap, the market in browser governance
as i've often mentioned before ... this is probabily why the fed gov. PKI has GSA signing
contracts with certification authorities ... effectively them making them agents of the
federal gov. ... so there is avenue for recourse and business reliance between
the
federal gov as the relying party and the fedreal gov as the certificate issuing
operations
(thru their agents via contractual relationship) ... i.e. effectively a relying party
PKI operations
http://www.garlic.com/~lynn/subpubkey.html#rpo
the argument then is that in an online environment, the relying-party digital
certificates
are redundant and superfluous. The two diminishing market segments are
1) the original design point for digital certificates, situation where the
relying party has no repository of their own regarding prior relationship with
the certified entity and/or have no timely connectivity to a certifying agency
2) no-value operations where the value of the transaction can't justify relying
parties keeping their own records and/or doing a real-time transactions.
both of these remaining PKI market segments are rapidly shrinking as internet
online connectivity becomes ubiquitous and as the costs of dataprocessing and
networking continues to drop.
as mentioned numerous times, in effect, x9.59 financial standard just augmented
existing payment transactions with digital signature for authentication and
integrity. there were no requirement for digital certificates ... for a wide
variety of reasons ... in addition to being redundant and superfluous ... the
digital certificates represented an enormous payload and processing bloat that
providing no fundamental added value
http://www.garlic.com/~lynn/subpubkey.html#bloat
the x9.59 consistent application of digital signature for authentication and
integrity ... w/o requiring any certificates
http://www.garlic.com/~lynn/subpubkey.html#certless
also eliminated simply "knowing" the associated account number as a
vulnerability ... that then eliminates a lot of the risk currently associated with
phishing and data breaches. x9.59 didn't eliminate phishing and data breaches .... it
just eliminated attackers being able to utilize a lot of the acquired information for
fraudulent purposes.
With a pervasive use of SSL in the world today as support for electronic
commerce ... primarily
to hide account numbers during transit thru the internet ... x9.59 basically
eliminates that need .... effectively substituting authentication and integrity
for encryption (used to hide the account number).
So a level set ... rather than asking how to fix PKI for messaging ... since
there are
a lot of process and practices effectively result in its failure ... start at a
simpler
level regarding what are the authentication requirements for messaging. Digital
signatures
and public keys might then be looked at for satisfying those authentication
requirements
... w/o necessarily requiring the heavy-weight bloat and business process
overhead related
to a PKI deployments.
misc. past posts mentioning the GSA PKI scenario where contracts with
certifying authorities
effectively make them agents of the federal gov (creating a recourse and basis for relying)
http://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS,
Outlook
http://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing,
Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and
other dances
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics
from the contracts world
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At
least I hope it's new)
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public
Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without
their private keys)
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
