Failure of PKI in messaging

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com