Legal force of authentication codes
Ross Anderson
authentication codes and the like will have evidential force, but so
far there has been a shortage of precedent.
However Mr Justice Waller has handed down judgment in a case in which
conspirators within the Bank of Tokyo sent out a fraudulent letter of
credit for $5,000,000. This was wrongly confirmed in a tested telex,
`authenticated by a secret electronic code recognisable to the
intended recipient'.
The judge held that the sender was in breach of its duty of care and
liable in negligent misstatement. He allowed an application for
damages by Sudwestdeutsche Landesbank Girozentrale.
The recipient of such an instruction could have performance unless it
had shown wilful blindness in failing to investigate matters - in
other words, there should have been a want of probity rather than mere
negligence.
This may be good news for vendors of public key crypto. There are
fuller details in the Times, 15 April 1995, page 31 (Law Report).
Ross
Colin James III
recent UK case law: international banking _is_ based on US banking
rules. Hence any UK-venue case law is most probrably egregious.
James R Ebright
As a former Geschaftsfurher, I was told telexes have long been ruled as
legal binding contracts in Europe (or Germany and the UK, at least).
This is quite untrue in the US where a real ink-based signature is almost
always required...however...
I believe an earlier thread said two states now accepted cryptographically
based signatures as binding. Contracts thus executed in those states would
be valid in all states due to reciprocity.
--
A/~~\A 'moo2u from osu' Jim Ebright e-mail: ebr...@bronze.coil.com
((0 0))_______ "'Eternal Vigilance Is The Price of Liberty' used to mean
\ / the \ we watched the government - not the other way around."
(--)\ OSU | - Bill Stewart, AT&T
Thad Smith
rj...@cl.cam.ac.uk (Ross Anderson) wrote:
> However Mr Justice Waller has handed down judgment in a case in which
> conspirators within the Bank of Tokyo sent out a fraudulent letter of
> credit for $5,000,000. This was wrongly confirmed in a tested telex,
> `authenticated by a secret electronic code recognisable to the
> intended recipient'.
What is a "tested" telex?
> The judge held that the sender was in breach of its duty of care and
> liable in negligent misstatement. He allowed an application for
> damages by Sudwestdeutsche Landesbank Girozentrale.
By sender, do you mean the Bank, or the conspirators, whom you say
sent the LOC?
> The recipient of such an instruction could have performance unless it
> had shown wilful blindness in failing to investigate matters - in
> other words, there should have been a want of probity rather than mere
> negligence.
What instruction? I thought an LOC was a guarantee that the money was
available, not instruction, and the the confirmation was more
information, not instruction.
What performance? What does a "want of probity" mean? There should
have been a want of probity on whose part in order for what to occur
or be true?
I'm not a lawyer, nor savvy in high finance. Further explanation
would be helpful.
--
Thad Smith ---------------\ T3 Systems - embedded software development
Thad...@acm.org \"A lot of kisses and you'll be surprised"
PGP key: finger th...@csn.net \--Box of candy kisses with prize, 1957
----------------------------------------------------------------------
Keith Wyatt
>authentication codes and the like will have evidential force, but so
>far there has been a shortage of precedent.
>
>conspirators within the Bank of Tokyo sent out a fraudulent letter of
>credit for $5,000,000. This was wrongly confirmed in a tested telex,
>`authenticated by a secret electronic code recognisable to the
>intended recipient'.
>
>liable in negligent misstatement. He allowed an application for
>damages by Sudwestdeutsche Landesbank Girozentrale.
>
>had shown wilful blindness in failing to investigate matters - in
>other words, there should have been a want of probity rather than mere
>negligence.
>
>fuller details in the Times, 15 April 1995, page 31 (Law Report).
>
>Ross
>
you can delete the signature file and never be proven that you E-mailed the
message. While banks have a regulated system, internet users don't.
Keith
___________________________________________________________________________
|Keith W. Veteran, US ARMY 101st Airborne 1985 |
|Internet:wyaN...@delphi.com 3rd Infantry Div. 86-89 (USAEUR) |
|Packet:N6JPA@w6vio.#soca.ca.usa.na PGP Key available on request. |
|San Luis Obispo, California USA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|__________________________________________________________________________|
|
William Unruh
>The problem with electronic signatures that are used by individuals is that
>you can delete the signature file and never be proven that you E-mailed the
>message. While banks have a regulated system, internet users don't.
Well your public key is presumably on file, and the person your are
communicatong presumably has some evidence that it really is your public
key. One he has that there is not much you can do, except try to
repudiate the public key.
--
Bill Unruh
un...@physics.ubc.ca
Adrian Kennard
Yes, but even with PGP, a public key does not have to be from 'you'. The
best you get is that there is a chain of people whoe have entered in to PGP
that the key they 'trust' the person who authenticated the key they sent.
Typically though public keys are just emailed, and not authenticated based
on personal knowledge.
There is nothing to stop me making a public key in your name, distributing
it via various sources, and sending out email pretending to be you, and then
deleting all records of the key at my end.
I suppose PGP does allow some tracing of how the key got where it did, and
who authenticated it - but it doesn't include all of the email headers
involved (if any), so .......
Now if banks were prepared to hold public keys on file and distribute them,
only authenticating them for their account holders when personally in the
bank and known to staff (overkill!) then you might have a chance (assuming
banks are honest <-:) if you got the key from the bank and authenticated by
them.
--
Adrian, at home... (my views and opinions, of course, E&OE)
Eric Moore
> There has been a lot of talk about whether digital signatures, message
> authentication codes and the like will have evidential force, but so
> far there has been a shortage of precedent.
I'll come out of the closet, er--vault. I'm a banker and familiar with
Reg. 4a. in the UCC and other fun EFT questions.
> However Mr Justice Waller has handed down judgment in a case in which
> conspirators within the Bank of Tokyo sent out a fraudulent letter of
> credit for $5,000,000. This was wrongly confirmed in a tested telex,
> `authenticated by a secret electronic code recognisable to the
> intended recipient'.
There is nothing surprising here. If the industry depends up "tested" or
authenticated messages, then it is the obligation of the sending bank to
maintain proper controls over its algorithms and test (or session) keys.
Also, the two banks had a contract with each other. (see below) Also,
the "confirmed" L/C is similar to an irrevocable guarantee provided by
BoT.
FYI - A "tested" Telex is a precursor to today's S.W.I.F.T. system. Two
banks agree to send and receive electronic messages, and to act upon the
instructions contained in the messages. (A formal, "bilateral," contract
exists between the two banks. ) Each bank sends to the corresponding
bank a secret algorithm and base/one-time key(s). (Less than 10 years
ago, it was possible to break test keys by inspection! Now things are a
bit tighter. ) Typically, the test was as simple as the (Julian value
date+amount)/base key and using only the first four numbers in the
dividend.
>
> The judge held that the sender was in breach of its duty of care and
> liable in negligent misstatement. He allowed an application for
> damages by Sudwestdeutsche Landesbank Girozentrale.
Soy-tainlee!
>
> The recipient of such an instruction could have performance unless it
> had shown wilful blindness in failing to investigate matters - in
> other words, there should have been a want of probity rather than mere
> negligence.
>
No - UCC (in the U.S.), contract law, and industy practices.
> This may be good news for vendors of public key crypto. There are
> fuller details in the Times, 15 April 1995, page 31 (Law Report).
Explaining public key cyrpto to banks will be like selling ice makers in
Antarctica. When it comes to technology (despite all the technology
propaganda 'au contaire') bank managers are cemented in 3270 emulation and
pensions. EM
--
-----------------------------------------------------------------------------
| Eric Moore | emo...@gate.net |
| Miami, Florida | |
|===========================================================================|
|"...Come back to Miami! We weren't really shooting at YOU!" |
--------------------------------------------------------****-----------------
Larry Kilgallen
> William Unruh wrote:
>
>> wyan...@delphi.com (Keith Wyatt) writes:
>> >The problem with electronic signatures that are used by individuals is that
>> >you can delete the signature file and never be proven that you E-mailed the
>> >message. While banks have a regulated system, internet users don't.
>>
>> Well your public key is presumably on file, and the person your are
>> communicatong presumably has some evidence that it really is your public
>> key. One he has that there is not much you can do, except try to
>> repudiate the public key.
>
> Yes, but even with PGP, a public key does not have to be from 'you'. The
> best you get is that there is a chain of people whoe have entered in to PGP
> that the key they 'trust' the person who authenticated the key they sent.
> Typically though public keys are just emailed, and not authenticated based
> on personal knowledge.
Non-repudiation is an area of differences where PEM has a clear advantage
over PGP. While PGP may be convenient for personal transactions, business
contracts require a system involving a Certification Authority.
Larry Kilgallen
LJK Software
James R Ebright
Larry Kilgallen <kilg...@eisner.decus.org> wrote:
>Non-repudiation is an area of differences where PEM has a clear advantage
>over PGP. While PGP may be convenient for personal transactions, business
>contracts require a system involving a Certification Authority.
While PEM may be better than PGP, in this context PGP is just as good
as what is in current usage today in business... there is no central
Certification Authority for signatures (ink type)...just levels of trust
established by other people (often witnesses or notaries). Signing a key
is very similar.
Jiri Baum
> In article <1995Apr24.165442.9720@eisner>,
> Larry Kilgallen <kilg...@eisner.decus.org> wrote:
> >Non-repudiation is an area of differences where PEM has a clear advantage
> >over PGP. While PGP may be convenient for personal transactions, business
> >contracts require a system involving a Certification Authority.
> While PEM may be better than PGP, in this context PGP is just as good
... [as for ink-based sigs] ...
There is also nothing stopping anyone becoming a Certification Authority.
For example, SLED would probably qualify. Others could spring up
(eg one in each country). PGP is just as good as PEM.
That is the beauty of PGP, that it's structure allows any model of trust.
This includes both a grass-roots web, and a bu"rocratic centrale.
Hope that makes sense... (followups to a.s.pgp only)
Jiri
--
<ji...@cs.monash.edu.au> <ji...@melb.dialix.oz.au> PGP 463A14D5
You know you've been hacking too long when...
you use \LATEX{} in a hand-written letter\footnote{or on the phone}.
D. J. Bernstein
> over PGP. While PGP may be convenient for personal transactions, business
> contracts require a system involving a Certification Authority.
This is nonsense. First, PGP's trust model _includes_ PEM's trust model
as a special case; PGP is perfectly capable of handling ``certification
authorities.'' Second, these ``authorities'' are a waste of time and
money. They are not required for contracts or for anything else.
---Dan
Paul Rubin
D. J. Bernstein <d...@silverton.berkeley.edu> wrote:
>This is nonsense. First, PGP's trust model _includes_ PEM's trust model
>as a special case; PGP is perfectly capable of handling ``certification
>authorities.'' Second, these ``authorities'' are a waste of time and
>money. They are not required for contracts or for anything else.
Second claim is incorrect. Many important documents have
to be notarized as well as signed. A notary is a certification
authority.
nick_szabo
>A notary is a certification authority.
Not even close. Notaries witness the actual autographing[1] of a document.
In other words, they serve the role of verifying that a specific person made
a specific autograph, on a specific document, at a specific time.
This is very different from the alleged role of "certification authorities"
(CAs) and the "PGP web of trust", to "prove identity". In fact they do no
such thing. Rather a certficate _proves that a claim was made_ by a
CA at some time in the past. The (implicit) claim is that a particular
key belonged to a particular person at that time. That key is not
biometric like an autograph, and can thus be transferred at any time.
Furthermore, false claims can be made by a CA about what keys an end-user
has held, and the end-user can be stuck with absolutely zero evidence of CA
fraud; nor does the CA have any way of proving that their claim is correct
if an end-user challenges it. It is extremely difficult, on the other
hand, for notary publics to forge autographs and expect to get away with it
often enough to maintain their professional reputations.
Both the PGP web of trust and X.509 models suffer from fundamental flaws.
A single rooted heirarchy assumes a mythological beast called a universally
trusted entity. Heirarchies in general create rigid structures that don't
fit the way knowledge about keys and keyholders, and incentives
to accurately reflect that knowledge, are distributed among people in the real
world. PGP, on the other hand, does not even distinguish between the
quite distinct claims "This key belongs to Alice" and "Alice can be trusted
to certify keys correctly." It's quite possible certify that Alice
held a key, without believing anything about the trustworthiness of
any claims Alice might make, but the PGP web of trust does not allow
for this. As Hal Finney puts it, there is little transitivity: seeing
Alice's key certified by Bob, whom I know and trust, tells me
little about whether Alice's certification of Charlie's key is correct.
It does tell me that I know to blame Alice if her claim turns out
to be wrong; although it's far from clear that Alice has any legal
liability.
Because the claim was only made in the past, both PGP and X.509 allows
the end user to plausible deny that they "signed"[1] a document;
and conversely if one's key is surreptitiously stolen, or for other reasons
no revocation action is taken, there is no way to prove that one did not
"sign" the documenent digitally "signed" with the stolen key. Finally,
there is no widely accepted legal agreement on what is specifically being
claimed when one "certifies" a key, nor is there any built-in or widely used
mechanism for describing the actual claim one is making. Real world CAs
have a nasty habit of disclaiming liability for their mistakes, or for the
misunderstandings that will arise out of the often vague and sloppy,
sometimes implicit claims they make. Finally, there are a wide variety of
other claims one might make about a key, such as "this key belongs to an
office", "this key belongs to a server", "this keyholder has a
good credit rating", "use this key to decrypt your new copy of Microsquish
Expel", "this key is good for 100 MB of downloads from our web server", etc.
which are facilitated by neither X.509 nor the PGP web of trust.
My own suggestion is that we know too little about the best uses
of public-key cryptography to establish such fixed methods with
such narrow semantics. I suggest a mechanism which modifies the
PGP web of trust to create arbitrary certificate with a form
roughly as follows:
Key about which a claim is being made
type of claim, in some standard one-line format (like MIME types)
Plain text description of claim
Timestamp
digitally "signed", Alice's key
In other words, all claims about keys should be _explicit_, readily known
from reading the certificate itself, and no kind of claim should
be arbitrarily excluded by the mechanism. The legal force of the
claim can be based on the text itself, rather than overstated,
obscure, and often implicit interpretations about what "certifying" is
supposed to mean. Standard kinds of claims will emerge, including perhaps
more transitive "good judge of judgement" certificates
for which chain-following software can be written, and non-transitive
"is-a-person" credentials directly "bound" to traditional notarized
identification by a physical notarization protocol that includes
both autographs and digital "signatures". More likely, new and more
useful kinds of certificates will evolve. These standards should be
allowed to emerge out of the wide varieties of possible end uses, much
like case law has matured over time, rather than being dictated by our
current very inexperienced understanding.
Meanwhile, Internet users can communicate the integrity of a key reasonably
well by tying it to a persistent pattern of behavior: for example
posts in a persistent style from a persistent e-mail address,
persistence of a key unchallenged on a key server, etc.
This is the most practical and widely used way by which PGP
users gain confidence in public keys, and it does not require
the web of trust.
Notes:
[1] Much confusion arises from calling reverse public key encryptions
of hashes digital "signatures". As there is no biometric, it is vastly
different from an autograph; more akin to a stamp or seal.
Nick Szabo
sz...@netcom.com
http://www.digicash.com/~nick/
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.1
mQCNAy9wYzAAAAEEAMaP1xpCnkIe/2UC2M7EJPMjSUF5BzJb3OCEROr00AzXplPY
UrpKRaNu42Oh6G3q8RcTWCZ1qZXbZelDTMTFyCL23gs+hHB8suKuAlleqELSGr4m
9mkoMBGzKh5xuUJQYG+rtdJCm3tSijCHxZZtHsVmZUsaK4RrNiCygoHHhZGFAAUR
tB1OaWNrIFN6YWJvIDxzemFib0BuZXRjb20uY29tPg==
=ZEvk
-----END PGP PUBLIC KEY BLOCK-----
Bryce Wilcox
<Nick Szabo> wrote:
<snip>
This is an excellent idea, Nick, and well-stated too! I have a couple of
questions:
1. PGP as-is could be used for this flexible-certificate scheme, right?
I mean, if you send me some e-mail with my public key and the words "Bryce
is a great guy and I urge the reader to buy him lunch.", and you sign it
with your private key, then I will happily keep a copy of it on hand to
show to other people.
2. Where does the time-stamp field come from? Seems like a bit's difference
in the time-stamp field could mean a million dollars or an irreplaceable
reputation. How about multiple time-stamps from various time-stamp-servers?
Thanks for your thoughtful ideas.
D. J. Bernstein
> authority.
The function of a notary is entirely different from the function of a
certification authority. Besides, think back to the last time you used a
notary (if ever): is that something you would have done electronically?
---Dan
William J. Evans
=== Nothing above this line is part of the message. ===
g...@sydney.sterling.com (Greg ROSE) wrote:
:In article <phrD7z...@netcom.com>, Paul Rubin <p...@netcom.com> wrote:
:>In article <1995May222....@silverton.berkeley.edu>,
:>D. J. Bernstein <d...@silverton.berkeley.edu> wrote:
:>>This is nonsense. First, PGP's trust model _includes_ PEM's trust model
:>>as a special case; PGP is perfectly capable of handling ``certification
:>>authorities.'' Second, these ``authorities'' are a waste of time and
:>>money. They are not required for contracts or for anything else.
:>
:>Second claim is incorrect. Many important documents have
:>to be notarized as well as signed. A notary is a certification
:>authority.
:
:That statement is incorrect in a fundamental way.
:A notary (or a Justice of the Peace in the state
:of New South Wales, of which I am one) is
:certifying the *act of signing* and not the
:*identity* of the signator. A perfect stranger can
:walk up to me and ask that I witness their
:signature, and I will, so long as I watch them
:sign.
My mileage varies. In California one must present some form of positive
identification to the notary public; the notary public not only witnesses
the signature, but attests that he or she took reasonable care to
ascertain the identity of the signator.
Signatures Follow. (tm)
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBL6jVye7FqQNEGv6lAQGKHAQAt148w3sh58mKGkIErreo8eS1x23yq8MI
r29KYHl4PmOPjb4L5DEmolbG0NCdW96wq2z183RrswkqYGu0F9ahaGsusqsZI67U
NVWfkFJUyC/BfCYVFHqAw4fO2f+I0cVn81nEf+hAU664yqONS7U8d3uowgfo+9HX
vvTqiUtAgdE=
=4Zh3
-----END PGP SIGNATURE-----
--
Bill Evans P.O. Box 4829 Irvine, CA 92716 (714)551-2766 _ /| ACK!
Email-To: w...@acm.org -- PGP encrypted mail preferred. -- \`o_O' /
Finger w...@netcom.com for public key (and Geek code). =( )=
PGPprint: FB D0 1C 1D EF DC 26 BA B3 9E 84 0B 40 D6 59 9C U
Greg ROSE
>In article <1995May222....@silverton.berkeley.edu>,
>D. J. Bernstein <d...@silverton.berkeley.edu> wrote:
>>This is nonsense. First, PGP's trust model _includes_ PEM's trust model
>>as a special case; PGP is perfectly capable of handling ``certification
>>authorities.'' Second, these ``authorities'' are a waste of time and
>>money. They are not required for contracts or for anything else.
>
>Second claim is incorrect. Many important documents have
>to be notarized as well as signed. A notary is a certification
>authority.
That statement is incorrect in a fundamental way.
A notary (or a Justice of the Peace in the state
of New South Wales, of which I am one) is
certifying the *act of signing* and not the
*identity* of the signator. A perfect stranger can
walk up to me and ask that I witness their
signature, and I will, so long as I watch them
sign. When I was sworn in the Judge spent quite a
bit of time pointing out that such a situation, if
the signature happens to be a forgery, is not my
fault or worry.
Digitally speaking, a notary service just takes a
hash of a document+signature, and issues a
certificate saying that said document+signature
was presented at such-and-so a time for
notarisation. I do not think this forms a
"certification authority". I am perfectly willing
to carry out this service for people today,
although I have no idea of what the legal
implications would be in New South Wales
(elsewhere, I'm just me).
--
Greg Rose INTERNET: greg...@sydney.sterling.com
Sterling Software VOICE: +61-2-975 4777 FAX: +61-2-975 2921
28 Rodborough Rd. 35 0A 79 7D 5E 21 8D 47 E3 53 75 66 AC FB D9 45
French's Forest co-mod sci.crypt.research
NSW 2086 Australia. USENIX Director.
Greg ROSE
replies, but Nick's posting didn't have a valid
address in it.
In article <3o89f9$l...@news.euro.net>, <Nick Szabo> wrote:
>... PGP, on the other hand, does not even distinguish between the
>quite distinct claims "This key belongs to Alice" and "Alice can be trusted
>to certify keys correctly." It's quite possible certify that Alice
>held a key, without believing anything about the trustworthiness of
>any claims Alice might make, but the PGP web of trust does not allow
>for this.
I think you are very incorrect in your statement
that PGP doesn't differentiate between believing
that a key belongs to an individual, and
associating integrity with that individual's
signature.
All the keys on a public key ring have two figures
associated with them -- a level of belief in the
key itself, and a level of trust in the integrity
of the key's owner. For an arbitrary key that you
add to the keyring, these are both set to "I
Dunno". However, when PGP detects a signature on
the new key from a person whose signing integrity
is fully trusted, or a configurable number of
partially trusted signatures, the belief in the
association between the key and the user is set to
"I know this person".
AT THAT POINT, the keyring's owner is asked to
assign a level of belief in that individual's
INTEGRITY TO INTRODUCE OTHER PEOPLE. You can
assign four levels, basically full trust, partial
trust, no trust, and "I Still Dunno".
I admit that many PGP users just equate an
intoduction with belief that the person can then
further introduce, but that is their problem for
abusing the system -- they typed "1" in answer to
a very clear question. This information is not
transitive, it comes directly and only from the
owner of the keyring.
So, properly used, PGP does make the distinction
you deny, and it makes it very clearly. If there
is any fault, it lies with the users.
Francis Litterio
> PGP, on the other hand, does not even distinguish between the
> quite distinct claims "This key belongs to Alice" and "Alice can be trusted
> to certify keys correctly."
This is incorrect. Type "pgp -kc", and look at the two columns
labelled "Trust" and "Validity". For each userid on each key, those
two values are stored independantly in your keyring (and they are
never extracted with a key -- they are for your use only).
> It's quite possible certify that Alice
> held a key, without believing anything about the trustworthiness of
> any claims Alice might make, but the PGP web of trust does not allow
> for this.
It sounds to me like you've never used PGP to sign someone's public
key. Even if you have, here's a reminder of how it goes:
% pgp -ks alice
Looking for key for user 'alice':
Key for user ID: Alice Nobody <al...@nowhere.com>
384-bit key, Key ID C40F0E01, created 1995/05/05
Key fingerprint = 8B F6 10 DF 5E CF 43 7A 21 01 E4 E1 D8 7A E5 61
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above public key actually belongs to the user specified by the
above user ID (y/N)? y
You need a pass phrase to unlock your RSA secret key.
Key for user ID "Francis P. Litterio, Jr. <fr...@centerline.com>"
Enter pass phrase:
Key signature certificate added.
Make a determination in your own mind whether this key actually
belongs to the person whom you think it belongs to, based on available
evidence. If you think it does, then based on your estimate of
that person's integrity and competence in key management, answer
the following question:
Would you trust "Alice Nobody <al...@nowhere.com>"
to act as an introducer and certify other people's public keys to you?
(1=I don't know. 2=No. 3=Usually. 4=Yes, always.) ? 2
--
Francis Litterio fr...@centerline.com
02 37 DF 6C 66 43 CD 2C http://draco.centerline.com:8080/~franl/
10 C8 B5 8B 57 34 F3 21 PGP-encrypted email preferred
"Those that give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin (1773)
Dave Tweten
>PGP, on the other hand, does not even distinguish between the
>quite distinct claims "This key belongs to Alice" and "Alice can be trusted
>to certify keys correctly." It's quite possible certify that Alice
>held a key, without believing anything about the trustworthiness of
>any claims Alice might make, but the PGP web of trust does not allow
>for this.
I'm not sure what PGP you're using, but the one I use (MIT 2.6.2)
explicitly allows this. In fact, that's all it allows. A
certification on Alice's key says exactly that the certifier believes
Alice was the sole effective holder of the private part of that key
when the certification was given. It says nothing whatsoever about
Alice's trustworthyness as a certifier.
>As Hal Finney puts it, there is little transitivity: seeing
>Alice's key certified by Bob, whom I know and trust, tells me
>little about whether Alice's certification of Charlie's key is
>correct.
PGP is more explicit than that. Bob's certification tells you
_nothing_ "about whether Alice's certification of Charlie's key is
correct." PGP leaves the responsibility of deciding whether to trust
Alice as an introducer entirely up to you. Your public key ring has
information for each key, indicating
1. That it's your own key (you trust yourself, don't you?), or
2. That the presumed holder of that key is so trusted to certify
other keys that no confirmation is necessary, or
3. That the presumed holder of that key is trusted to certify
other keys with the concurrence of some number of others, or
4. That the presumed holder of that key is not trusted to certify
keys at all.
This classification of certifiers is entirely under your control as a
PGP user. Incidently, the "number of others" is also up to you. Your
web of trust extends only as far as "presumed holders" of keys can be
certified, or to a setable maximum depth, whichever is less.
PGP's certifications act like a California Notory Public
certification, only attached to the signature instead of the document.
It doesn't say that the certifier believes that the signer is a
trustworthy person. It says exactly that the certifier has checked
and believes the identity claimed in the signature.
--
Dave Tweten, M/S 258-5 | PGP key fingerprint = | twe...@nas.nasa.gov
NASA Ames Research Center | 41 B0 89 0A 8F 94 6C 59 | (415) 604-4416
Moffett Field, CA 94035-1000 | 7C 80 10 20 25 C7 2F E6 | FAX: (415) 604-4377
Larry Kilgallen
> authorities.'' Second, these ``authorities'' are a waste of time and
> money. They are not required for contracts or for anything else.
While that is an interesting assertation, I would rather
hear it from a banker who is willing to put her organization's
assets on the line.
The last banker I heard on the subject thought the existing certification
authority hierarchies were too weak because the entity at the top of
the hierarchy did not have sufficient assets to sue over the largest
transaction involved. The current stance of that bank is to avoid
trusting public key.
Larry Kilgallen
Hal
I think the point that Nick was making is that while PGP does allow
individuals to personally and privately decide whom they will trust as
introducers, it includes no mechanism to share that information. If
Alice has signed the keys of lowlife Bud and honest Bob, there is no way
for her to publicly endorse Bob as a signer.
If I don't know either of Bud or Bob, but I know and trust Alice, there
might be situations in which this kind of information would be useful.
As it is, if I want to communicate with x...@sydney.sterling.com, and he
has his key signed by a dozen people, I better know one of those people,
either personally or by reputation. Otherwise I have no basis to know
how reliable they are as signers. It might be useful if there were a
(shall we say) "web of trust" between xyz and me, where I trust Alice,
who trusts Bob, who trusts... until we get to one of xyz's signers.
Granted, there are problems with this. There might be social pressures
on Alice to endorse Bud as a signer (he's her boss). And the longer the
chain gets the greater the chance that error will creep in. But if the
chain is not too long and people do try to keep their endorsements honest
(not endorsing weak people like Alice who give in to their bosses) then
this could provide useful information and create a true web of trust.
Hal Finney
Jim Grubs, W8GRT
w...@netcom.com (William J. Evans) writes:
> My mileage varies. In California one must present some form of positive
> identification to the notary public; the notary public not only witnesses
> the signature, but attests that he or she took reasonable care to
> ascertain the identity of the signator.
Same in Ohio. Moreover, I have noticed that they have begun asking questions
to be sure you know what you're signing. I'm not certain whether it's
required.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: http://norden1.com/~jim/sylvania.html
iQCVAwUBL6vhtt74r4kaz3mVAQHn/AQAp/xMMugrBxDdD3ICf5T3SHQ5TXHSjPu+
e9InHRnQ4cW0oFFI72afHvasBu8oV3B2qzyLRG182vbJsAtQoLqyT2ul5A5SbQ4I
zYGCdXOzLBi+DC6VuJGiT2jRSKBN6H//5Lr9JZ4jdL+XdURaenn8Z//brc3MO6Df
Zs0NDH+LJ6c=
=u4bI
-----END PGP SIGNATURE-----
D. J. Bernstein
Larry Kilgallen <kilg...@eisner.decus.org> wrote:
> The last banker I heard on the subject thought the existing certification
> authority hierarchies were too weak because the entity at the top of
> the hierarchy did not have sufficient assets to sue over the largest
> transaction involved. The current stance of that bank is to avoid
> trusting public key.
What a ridiculous position. Who does the bank sue _now_ if they're
defrauded over the phone?
---Dan
Jiri Baum
> [misc.legal trimmed]
... If
> Alice has signed the keys of lowlife Bud and honest Bob, there is no way
> for her to publicly endorse Bob as a signer.
"When all communication fails, try words." Alice can sign a plain English
statement. Bob puts it in his finger/web page/CV. No problem.
In the old days, it used to be known as "letter of introduction".
The trouble with automating this is that trust is a strange beast
which isn't always easy to define (especially with transitivity).
For instance, Alice might think Bob can be trusted to sign keys, but
not to judge whether others are to be trusted.
Hope that makes sense...
Jiri.
Francis Litterio
> ... If
> > Alice has signed the keys of lowlife Bud and honest Bob, there is no way
> > for her to publicly endorse Bob as a signer.
>
> "When all communication fails, try words." Alice can sign a plain English
> statement. Bob puts it in his finger/web page/CV. No problem.
> In the old days, it used to be known as "letter of introduction".
>
> The trouble with automating this is that trust is a strange beast
> which isn't always easy to define (especially with transitivity).
>
> For instance, Alice might think Bob can be trusted to sign keys, but
> not to judge whether others are to be trusted.
I don't see what you're getting at. What does it mean in terms of PGP
key management for Alice to "think Bob can be trusted to ... judge
whether others are to be trusted"?
Are you saying that PGP should allow Bob's Trust Parameters to be
exported to Alice's keyring automatically? If so, I disagree.
Daniel W. Connolly
fr...@centerline.com (Francis Litterio) wrote:
> don't see what you're getting at. What does it mean in terms of PGP
>key management for Alice to "think Bob can be trusted to ... judge
>whether others are to be trusted"?
>
>Are you saying that PGP should allow Bob's Trust Parameters to be
>exported to Alice's keyring automatically? If so, I disagree.
I think this demonstrates a number of points. First we have two separate
concerns here, the issue of limiting trust credentials within certificates and
that of keeping trust paths secret.
The first of these is vital if we want a system that progresses beyond PGP. PGP
is fine for mail but inadequate for electronic contract negotiation, multiparty
transferes and other exotica. PGP is superior to PEM because the certificates
contain more information than the binary authentic/not authentic system of
X-509 and PEM.
For contracts we need to have limits of liability built into certificates. Just
as your VISA card has a complex web of trust assertions associated with it
those assertions must be incorporated into the various certificates that define
the electronic analogue of that system. So a certificate may have a statement
"not vaid for more than $100". Lose your private key? If the certificate has
limited lability then you are covered. Many organisations will want to
incorporate statemnts like "This is not a contract" into certificates for their
minions. counersignature requirements etc must also be expressed.
The RSA extended certificates standard PKCS #6 looks like a good way to
incorporate such assertions. There are good cases to be made for both natural
language and machine interpretable encodings. for such attributes.
The preservation of anonymity of trust credentials is complex but can be
acheived to a degree. I would see this as a suitable task for trust broking
agents which would provide a service determining a path of trust for various
purposes. It is not necessary for the parties to disclose their entire trust
criteria, just as it is not necessary for an army to disclose its entire order
of battle to deter an aggressor with a show of strength.
Some information will have to be disclosed, if only that there is an intention
to enter into some form of contract. There are various levels of safeguard that
may or may not be relevant. Are the parties prepared to incur a delay to allow
use of certain traffic analysis avoidance strategies?
I'm currently working on this scheme. If anyone has any comments please contact
me at <hal...@w3.org>
Phill.
Daniel W. Connolly
Peter D. Junger
: w...@netcom.com (William J. Evans) writes:
: > My mileage varies. In California one must present some form of positive
: > identification to the notary public; the notary public not only witnesses
: > the signature, but attests that he or she took reasonable care to
: > ascertain the identity of the signator.
: Same in Ohio. Moreover, I have noticed that they have begun asking questions
: to be sure you know what you're signing. I'm not certain whether it's
: required.
The problem here is that there are (in most of the United States) two
different acts that are often called ``notarization'', the first is simply
where one swears to the truth of some affidavit before a notary or some other
officer entitled to take oaths. This does not require the notary to know
who the affiant is. The second act is when someone ``acknowledges'' before
a notary that he has executed a document as ``his own act and deed.'' This
second act requires the notary to know the person making the acknowledgment.
Thus in New York, for example, the form of an acknowledgment goes something
like this:
On this _____ day of _______, 19__, personally appeared before me
________, known to me and known to me to be the person who signed
the foregoing insturment, and acknowledged that he executed the
same as his own act and deed.
The use of acknowlegments may be limited to the United States and
other jurisdictions that have recording acts. I know from experience that
acknowlegments are not recognized by lawyers in the British West Indies.
In the first type of act of notarization, the notary merely certifies
that the affiant swore the statement was true. In the second type the
notary actually vouches that the person making the acknowledgment was who
he claims to be.
I hope that this helps clarify things a bit.
--
Peter D. Junger -- Case Western Reserve Univ. Law School
Home: jun...@pdj2-ra.f-remote.cwru.edu (preferred)
Office: jun...@samsara.law.cwru.edu
NOTE: jun...@pdj2-slip.dialin.cwru.edu NO LONGER EXISTS
Phillip M. Hallam-Baker
>Non-repudiation is an area of differences where PEM has a clear advantage
>over PGP. While PGP may be convenient for personal transactions, business
>contracts require a system involving a Certification Authority.
No, this is not the case. In fact a hierarchy is worse in many ways. What is
required is for each party to be able to precisely define what their
commitments are. This is independent of any hierarchial organisation of the
certificates.
Neither PEM nor PGP are sufficient in this respect.
Phill
Larry Kilgallen
> p...@netcom.com (Paul Rubin) writes:
>
>>A notary is a certification authority.
>
> Not even close. Notaries witness the actual autographing[1] of a document.
> In other words, they serve the role of verifying that a specific person made
> a specific autograph, on a specific document, at a specific time.
> This is very different from the alleged role of "certification authorities"
> (CAs) and the "PGP web of trust", to "prove identity". In fact they do no
> such thing. Rather a certficate _proves that a claim was made_ by a
> CA at some time in the past. The (implicit) claim is that a particular
> key belonged to a particular person at that time. That key is not
> biometric like an autograph, and can thus be transferred at any time.
> Furthermore, false claims can be made by a CA about what keys an end-user
> has held, and the end-user can be stuck with absolutely zero evidence of CA
> fraud; nor does the CA have any way of proving that their claim is correct
> if an end-user challenges it.
By subscribing to a particular certification hierarchy (root key), a CA
agrees to abide by the rules of that hierarchy. Some of those rules can
go to the agreement which must be made by an individual certified by the
CA. Rules can cover speed of revocation notification, degree of affiliation,
and even the technology used. The basic RSA commercial hierarchy requires
CAs use a hardware device with multiple physicial keys for activation. It
is quite reasonable that some other hierarchy might require end-user private
keys be stored in hardware tokens such that it can never be duplicated.
Another possibility for hierarchy rules is to specify the penalties for
violating them. Perhaps not what you had in mind for internet email, but
viable for banks dealing wiht national banks.
Note that proposals for the next version of X.509 add extensions to
allow for cryptographic certification by a CA of the rules governing
a certificate.
> Because the claim was only made in the past, both PGP and X.509 allows
> the end user to plausible deny that they "signed"[1] a document;
> and conversely if one's key is surreptitiously stolen, or for other reasons
> no revocation action is taken, there is no way to prove that one did not
> "sign" the documenent digitally "signed" with the stolen key.
For a hierarchy which requires prompt reporting of theft, the user has
no excuse for not reporting a detected theft. With hardware tokens,
duplication of the private key is not possible. Token defenses
against guessing attacks are quite adequate now (bad guesses cause
token amnesia). Attacks to learn passwords in advance of stealing
tokens are still viable, but some obvious hardware steps can be taken
if a market develops for defenses against that level of attack.
> [1] Much confusion arises from calling reverse public key encryptions
> of hashes digital "signatures". As there is no biometric, it is vastly
> different from an autograph; more akin to a stamp or seal.
But there is the "something you know" used to unlock the key -- not
possible with historic stamps or seals. The result is much more
strongly attached to an individual (even if by PKCS #5 for software-only
implementations), and a whole lot more reliably verified than ink signatures.
Larry Kilgallen
Larry Kilgallen
> w...@netcom.com (William J. Evans) writes:
>
>> My mileage varies. In California one must present some form of positive
>> identification to the notary public; the notary public not only witnesses
>> the signature, but attests that he or she took reasonable care to
>> ascertain the identity of the signator.
>
> Same in Ohio. Moreover, I have noticed that they have begun asking questions
> to be sure you know what you're signing. I'm not certain whether it's
> required.
In Massachusetts, the notary states that they know the individual to
be who they claim to be. The major additional statement they ask from
the individual is a statement that the document is being signed of their
own free will and without duress (there is legal language which I do not
remember). The notary does _not_ look at the contents of the document,
and some even cover it up with a piece of paper to make that clear.
It is possible to add additional requirements. To get an unaffiliated
(residential) key in the RSA Commercial Hierarchy, such as for the Apple
Macintosh, the notary must state the three forms of identification used,
and only certain ones qualify.
On the other hand, basing that whole design on the US Notary system,
RSA and Apple found when they delivered to Japan that there is no such
thing as a Notary. Your mileage in various states may vary, but outside
the US it will certainly vary.
Larry Kilgallen
LJK Software
Larry Kilgallen
Banks currently rely on secret-key cryptography with individual bilateral
agreements. There is an ANSI standard.
Larry Kilgallen
D. J. Bernstein
Well, yes, and they'd be much less vulnerable to internal fraud if they
used a layer of public-key cryptography too. But that's a side issue.
Your banker apparently envisions some situation where he'd be suing a
certification ``authority.'' This makes no sense to me. In what
situation would any bank want to use, let alone trust, the information
from such an ``authority''? Public-key cryptography certainly protects
bank-customer communication much more effectively than state ID cards
and social security numbers. Why should it lead to any lawsuits?
---Dan
Larry Kilgallen
> The RSA extended certificates standard PKCS #6 looks like a good way to
> incorporate such assertions. There are good cases to be made for both natural
> language and machine interpretable encodings. for such attributes.
A representative of RSA Data Security Incorporated stated at the January
1995 RSA conference that they expect PKCS #6 to become irrelevant if the
proposed changed to X.509 (providing more flexible extensibility) become
approved.
Larry Kilgallen
LJK Software
Larry Kilgallen
> Your banker apparently envisions some situation where he'd be suing a
> certification ``authority.'' This makes no sense to me. In what
> situation would any bank want to use, let alone trust, the information
> from such an ``authority''? Public-key cryptography certainly protects
> bank-customer communication much more effectively than state ID cards
> and social security numbers. Why should it lead to any lawsuits?
Presumably they would sue over a certificate which was falsely signed
as having been that of organization such-and-such.
Whether it makes sense to you, or whether it makes sense to me, is
quite immaterial. The reality is that it makes sense to the banker.
So if the question is "Why aren't banks using public key?", that is
the answer from the crypto specialist for at least one large bank
(presumably reflecting management priorities).
Larry Kilgallen