Client Certificate UI for Chrome?

[Anne & Lynn Wheeler]

On 08/06/09 07:33, James A. Donald wrote:
> The fundamental problem with certificates is getting them.

digital certificate design point supposedly was the dial-up email of the early 80s,
dial-up, exchange email, hang-up ... and then faced with how to deal with first
time email from complete stranger. basically electronic analog for letters of
credit/introduction from sailing ship days.

in the 90s, because of numerous privacy and liability issues ... there
was some number of "relying-party only" certificates; individual registered
their public key with the institution, institution then created a digital
certificate with the public key, archived it, and returned a copy to the
individual. the individual, in communication with the institution would
digitally sign the communication and then append the digital certificate.
However, it was trivial to prove that the institution/relying-party already
had a copy of the information ... and the appended digital certificate
was redundant and superfluous. misc. past posts discussion relying-party only
digital certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

furthermore, major foreys into this sector were by financial institutions
for the purpose of payment transactions. a complicating factor ... besides
the digital certificates being redundant and superfluous ... they added
a 100 times payload size bloat to the typical payment transactions. misc.
past posts
http://www.garlic.com/~lynn/subpubkey.html#bloat

there was a financial standards effort that looked at possibly doing
"compressed" digital certificates (trying to achieve only ten times bloat)
... eliminating redundant fields and information already in the possession
of the individual's financial institution. we showed that the individual's
financial institution already had superset of the information in the
digital certificate ... so it was possible to compress digital certificates
to zero bytes ... and then mandate that financial transactions would always
have zero-byte certificates appended (as opposed to no appended digital
certificate).

Something similar was demonstrated for RADIUS and Kerberos ... registering
a public key in lieu of password ... some past references
http://www.garlic.com/~lynn/subpubkey.html#radius
and
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and also something similar for registering public key with domain
name registration with domain name infrastructure ... for use in
lieu of SSL digital certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

that left institutions and relying party with no-value business processes
as digital certificate opportunities ... i.e. no-value transactions where
the relying party couldn't justify the cost of their own entity repository
and/or justify the cost of doing an online transactions to obtain such entity
information ... and of course ... the original design point, the "offline
email" scenario with first time communication with complete strangers.

One of the problems with no-value market segment is that it is hard for
institutions and individuals to justify paying for things without
any value ... and therefor it is hard to find entities looking
at selling things for nothing.

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar1970

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