Nelson B wrote:
Ian G wrote:
My perspective on this is taken from years of doing
issuance contracts in an unregulated field. The
What is an issuance contract? (just curious)
A contract for issuance of value. There is a contract
underlying Paypal's money for example, but they way
they do things is pretty ropey, they change their
contract every time some old lady phones up and
complains. E-gold is another issuance, and famously,
in late 2000, they changed their contract of issuance
from "you own the gold" to "you don't own the gold..."
In brief, take a contract, stick a few program-readable
terms in there, cleartext sign it, and then hash it. The
hash becomes the identifier for the units of issue, and
the accounting system manages hashs. By this means,
people have issued dollars, gold and other units, and
then run payment systems denominated in these units.
The benefit of doing it this way is that the contract
is fairly shared between the user and the issuer, and
the issuer can't arbitrarily change the contract without
breaking the accounting and every payment that was
ever made. The hash for my dollar contract is:
SHA:e3b445c2a6d82df81ef46b54d386da23ce8f3775
and that SHA1 hash is bound into every signed payment
and signed receipt, so the contract is set in stone.
http://www.webfunds.org/ricardo/contracts/systemics/
http://www.webfunds.org/ricardo/contracts/webfunds/
Is a couple of pages of issuance contracts. The second
group are 'toys' and the first group are 'real' But the
same rule applies; if you hold some units of the toy
contracts, the issuers are bound to follow them. If
you mail them you'll find they take their responsibilities
seriously, I hope :-)
In order to address this, I developed a simple rule:
tell the truth. Everything that was written into a
contract should be the truth. The digital signature
should attest to that.
So as long as whatever is in that cert is the truth,
I don't see an issue. That's just me, tho!
Ian, You're the anti-phisher guy. I would expect you to want
certs to contain more info to help fight phishing. Just how does
a cert that contains only CN=pay.pal.com help avoid phishing?
The only value in a cert is provided by the CAs
willingness to sign it. If the CA signs on a
CN=pay.pal.com then that's the only value
that is there!
It matters not whether the additional info is
in there. There could be addresses, phone
numbers, there could be corporate numbers
and even the attorney's name. But in the real
world of hard and crooked commerce, the
question is not what info is there, but what
the CA was willing to sign off on.
In this sense, forcing more information into
the cert actually does the reverse of what you
want; it creates a false sense of security based
on the presence of additional uncertain info.
Making rules and insisting on CAs following
standards raises costs for honest cert owners,
and it lowers security for honest relying parties,
*if* they are fooled by the extra info.
The most important thing is *which CA*. After
that, the 2nd most important thing is which
root cert was used, because that tells the user
what level of assurance that CA was promising.
Finally, once the user establishes the reliability
of the cert, she can factor that in to whether
she hands over her credit card to no-risk-porn.com
as signed by the Gambino CA, or whether she
decides to go with something signed off on by
VeriSign or QuoVadis or etc etc.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
