Re: A crazy thought?

[Anne & Lynn Wheeler]

Ian G wrote:
What you are suggesting is called Web of Trust (WoT). That's what the 
PGP world does, more or less, and I gather that the SPKI concept 
includes it, too.

However, x.509 does not support it.  There is no easy way to add 
multiple signatures to an x.509 certificate without running into support 
problems (that is, of course you can hack it in, but browsers won't 
understand it, and developers won't support you).

re:
http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
http://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
http://www.garlic.com/~lynn/aadsm27.htm#27 A crazy thought?

actually ... at a very fundamental level both PKI and PGP have nearly identical
business and implementation processes ... the difference is somewhat that the 
PKI operations tend to try and make out that their structure is more formal 
... and therefor should be more trusted.

Both implementations require that the relying-parties have some sort of local
trusted public key repository ... initially populated with some out-of-bad
process. In the SSL PKI scenario ... there tends to be a trusted public key
repository built into each browser distributed ... initially loaded with
possibly 40-50 public keys that you are told that you can trust. In the
"web of trust" scenario ... there tend to be some set of public keys
that are also trusted and have also been acquired in some out-of-band process.

In both scenarios ... the relying-party is expected to "trust" new public keys
that carry digital signatures ... where these digital signatures can be
verified with public keys from their local repository of (already) trusted
public keys (public keys that have typically been distributed/initialized
by some out-of-band process)

It isn't so much that the fundamental processes are different ... it
is more about how tightly controlled and cast in concrete the surrounding
pieces happen to be (aka formalized and not easily changed/adapted).

For totally other drift ... one of the places we came up with requirement
for multiple digital signatures was in the process for x9.59 financial
infrastructure for payment transactions ... i.e. in the mid-90s, the
x9a10 financial standard working group had been given the requirement
to preserve the integrity of the financial infrastructure for all retail
payments
http://www.garlic.com/~lynn/x959.html#x959

x9.59 actually doesn't specify the details of digital signature process ...
but defines the fields necessary for a payment transactions which require
authentication and integrity protection on end-to-end basis. one of the
scenarios is the authentication of the account holder with digital
signature (which also provides payment transaction integrity). one of
the trust issues was that their could be various kinds of exploits
at the originating environment (where the account holder's digital
signature and the transaction was otherwise valid). to increase the
trust (as indication of possible countermeasures against these additional
exploits/vulnerabilities) allowed for the originating environment to
also digitally sign the transaction (as a flavor of "device" authentication,
possibly a point-of-sale terminal or other kind of device that was
used to originate the transaction).

the FSTC electronic check work also allowed for multiple digital signatures
... representing the equivalent of requiring multiple co-signers on
business checks ... i.e. business checks that allow for single signer
if the amount is below some limit ... but requires additional co-signers
for larger amounts.

note that both in the FSTC electronic check and the X9.59 financial
standard scenario, there was some assumption that the basic transaction 
went via normal existing electronic payment networks ... with appended digital
signature(s) ... where the transaction might actually only be encoded
during just the digital signature generation and digital signature verification
processes. recent posts in the encoding thread:
http://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:
http://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats:

also any additional appending of traditional digital certificates to such
operations could represent a factor of 100 times payload and processing
bloat.
http://www.garlic.com/~lynn/subpubkey.html#bloat

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]