[13679] in cryptography@c2.net mail archive
Re: An attack on paypal
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Thu Jun 19 11:14:55 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 19 Jun 2003 08:56:50 -0600
To: iang@systemics.com
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <3EF100A6.13B64216@systemics.com>
At 08:15 PM 6/18/2003 -0400, Ian Grigg wrote:
>Certificate caching is a far more powerful idea
>than, say, CA-signed certs. If it were added
>to browsers, and servers initialised with self-
>signed certs, then the security of the net would
>go up immensely. Integrated with some of the
>ideas that people have suggested concerning WoT,
>publically distributed certs, and individualised
>displays (amounting to local secrets keyed on the
>cert), we could actually start to see people using
>secured browsing when they wanted to rather than
>when they were forced to.
typically certificates have had two characteristics .... 1) asn.1 encoding
for network interoperability distribution and 2) trusted third party
binding of some information to the public key
self-signed certificate caching is really loading public key into a locally
maintained table.
in principal there is no need to maintain asn.1 encoding format in a
locally maintained table since it eliminates having to decode it on every
use .... and the asn.1 encoding is only useful if you 1) are planning on
redistributing somebody else's public key and 2) need the original bit
format for validating the self-signed signature. The validating of the
self-signed signature can be done on initially acquiring the certificate
.... and then it can be decoded, and the decoded values loaded into the
table. the table/database just becomes entries of public keys and the
associated attributes (which might be a combination of the original plus
any additional that you might want to add along the way).
in that sense it becomes more of authentication management .... along the
lines of kerberos, radius, and/or the AAA RFCs, aka
authentication, authorization, and accounting.
in previous posts about BBB, it is possible that it would be used in
combination with online trusted references .... i.e. analogous to real-time
call to BBB and obtaining referrels and any complaint information ... and
then possibly remembering it by recording it in the table (aka online trust
propogation as opposed to the offline trust propogation represented by TTP
certificates).
Part of the issue with the offline TTP stale, static certificate model was
that it periodically tried to overload the contents of the certificate ....
trying to justify the expense of the ceritifcate to the public key owner
.... but having little or no idea what might be the future requirements of
a broad range of relying parties. A locally maintained relying-party
table/database would allow the relying party to dynamically adapt the trust
characteristics that they were interested in.
Decoding the self-signed certificate before loading into the local table
.... helps highlight that the recorded trust characteristics don't have to
be restricted to just those that happen to exist in the stale, static
certificate (created at some time in the past by entities that had no
anticipation regarding your specific trust requirements).
past discussions of online & offline trust propogation:
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
http://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital
signature
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#4 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure:
An Artifact...
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft
jumped in 2002
http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from
usenet group
http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
