Failure of PKI in messaging

[Anne & Lynn Wheeler]

Ian G wrote:
> Actually, there are many problems.  If you ask the low-level crypto 
> guys, they say that the HI is the problem.  If you ask the HI guys, they 
> say that the PKI concept is the problem.  If you ask the PKI people, 
> they say the users are not playing the game, and if you ask the users 
> they say the deployment is broken ...  Everyone has got someone else to 
> blame.
> 
> They are all right, in some sense.  The PKI concepts need loosening up, 
> emails should be digsig'd for authentication (**), and the HI should 
> start to look at what those digsigs could be used for.
> 
> But, until someone breaks the deadly embrace, nothing is going to 
> happen.  That's what James is alluding to:  what part can we fix, and 
> will it help the others to move?
> 
> iang
> 
> ** I didn't say digital signing ... that's another problem that needs 
> fixing before it is safe to use, from the "ask the lawyers" basket.

looking at the ssl domain name certificate uptake scenario ... there was
a combination of things ... lots of publicity so that consumers perceived it providing
some benefit, merchants perceiving that the consumers would feel better about
it ... and therefor (for merchants) that it was worthwhile to shell out the money ... and
lots of financial interests providing for publicity and support to have
it ubiquitously deployed (to encourage merchants to shell out the money).
lots of past posts mentioning the whole ssl domain name certificate 
scenario
http://www.garlic.com/~lynn/subpubkey.html#sslcert

part of the problem was that the PKI financial model is out of kilter with
standard business practices. nominally a relying party has some sort of
relationship with the certification authority (i.e. what they are
relying on) and there is exchange of value between the two parties.

In the standard PKI model, there frequently is absolutely no relationship
between the relying party and the certifying agency. The "owner" of the
digital certificate is paying the certifying agency ... not the relying
party ... so there is typically no exchange of value between the
certifying agency and the relying party ... and therefor the 
relying party has no foundation for actually relying on the certifying 
agency.

In early 90s ... there was some attempt to sidestep the lack of business
foundation for PKI ... by defining X.509 identity certificates, frequently 
grossly overloaded with personal information and then getting gov. regulations 
mandating the certificates. There were also attempts to up the anty
with semantic confusion attempting to equate "digital signatures"
with "human signatures". misc. past posts about helping word
smith various electronic signature legislation and/or the wide
divide between "digital" and "human" signatures.
http://www.garlic.com/~lynn/subpubkey.html#signature

Remember that the (late 80s and) early 90s (with the attempts at ISO x.509 identity
certificates) was also in the period when you saw various institutions
and govs. mandating the elimination of the internet and its replacement
with ISO (OSI model) networking standards.

one might even contend that in the ssl domain name certificate scenario ...
that once all the hype and publicity is stripped away ... that a fundamental
issue is that the "relying party" has absolutely no recourse with regard
to the certifying agency when things go wrong (which would exist in normal
business relationship between two parties). That the "padlock" symbol
is purely a representation of the hype and publicity ... and not a fundamental
business foundation.

recent thread about one of the major, fundamental justifications for ssl domain name
certificates ... countermeasure to man-in-the-middle attacks ... and not being
very effective
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL

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