Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-03-31 Thread Nicholas Bohm

At 11:42 07/01/2004 -0800, Ed Gerck wrote:
Jerrold Leichter wrote:
 Now that we've trashed non-repudiation ...
Huh? Processes that can be conclusive are useful and do exist, I read
here,
in the legal domain. It may not be so clear how such processes can exist
in
the technical domain and that's why I'm posting ;-)
 just how is it different from authentication?
Using an information theory model, it's clear that authentication needs
one
channel of information (e.g., the CA's public key, the password list) in
addition
to the signal (e.g., a signed message, a username/password entry).
Authentication
rests on the information channel being trusted (i.e., independently
verifiable). In
this model, non-repudiation is different because it needs at least one
additional
out-of-band signal (where authenticated absence of the signal is also
effective).
BTW, that's why digital signatures per se are repudiable -- there's no
second,
out-of-band signal.
An additional technical difference is that authentication promotes
strength of
evidence while non-repudiation promotes lack of repudiation
of evidence.
The latter is intuitively recognized to be stronger because a
single, effective
denial of an act can rebuke any number of strong affirmations.
This also means, intuitively, that another difference exists.
Non-repudiation
should be harder to accomplish than authentication (you want more, you
need
to pay more). However, to the extent that the process *can be*
conclusive,
non-repudiation may be worth it. Imagine the added costs, time and
hassle
(going back to a real-world comparison) if your bank would have to call
you
to confirm payment for every check you sign? This would be the case
if
paying a check could not be cast as a conclusive process for the bank
(i.e.,
without the possibility of an irrebuttable presumption of
payability).
In the UK, but not in other countries, there is a statutory rule which
prevents a bank from debiting a customer's account with a forged cheque
(if you will forgive the British spelling), with only very limited
exceptions. If the customer repudiates a signature, it is for the
bank to prove the genuineness of the signature, or suffer the
loss.
My bank has once or twice telephoned to check the genuineness of an
unusual transaction, though this over a period of many years.
This is not to disagree with your comments, but to observe that existing
paper systems can work satisfactorily without non-repudiation
rules. There are obvious advantages to some parties in such systems
if it adopts a non-repudiation rule, probably matched with corresponding
disadvantages for others. The change from paper to electronic
systems of course also alters the balance of risks and the approach of
banks to non-repudiation rules.
I and colleagues have written about this at:
http://elj.warwick.ac.uk/jilt/00-3/bohm.html
Regards
Nicholas Bohm
Salkyns, Great Canfield,
Takeley, BishopÂ’s Stortford CM22 6SX, UK
Phone01279
871272(+44 1279 871272)
Fax020 7788
2198(+44 20 7788 2198) - please note new
fax number
Mobile07715 419728 (+44 7715 419728)
PGP RSA 1024 bit public key ID: 0x08340015. Fingerprint:
9E 15 FB 2A 54 96 24 37 98 A2 E0 D1 34 13 48 07
PGP DSS/DH 1024/3072 public key ID: 0x899DD7FF. Fingerprint:
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF 


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-09 Thread Anne Lynn Wheeler
At 10:14 AM 1/7/2004 -0500, Jerrold Leichter wrote:
Now that we've trashed non-repudiation ... just how is it different from
authentication?  In both cases, there is a clear technical meaning (though as
with anything in mathematics, when you get right down to it, the details are
complex and may be important):  To produce an authenticator/non-repudiable
signature, you must have access to the secret.  There isn't, at this level,
even any difference between the requirements for the two.  Where we get into
trouble is in attempting to bind the real world to the mathematics.  In each
case, the receiver wants to be able to say:
lets say they are somewhat different threat models (but may have some 
partial overlap).

it would be possible to give a dozen people the same passprhase and have 
some degree of confidence that only the permitted entities entitled to do 
something were authenticated. however, if one of them claimed that they 
didn't do some specific thing ... there would be difficult to differentiate 
between the different entities as to which entity had been authenticated at 
any specific time. some of the best practices security guidelines for 
authentication (like not sharing passwords) have more to do with 
non-repudiation ... than straight authentication.

key-escrow can be considered mandatory for encryption keys under the 
non-single-point-of-failure and availability best practices. At the same 
time there may be mandatory requirements for NOT having key-escrow for 
authentication keys under non-repudiation best practices (even when the 
cryptographic technology is identical ... the issue of key-escrow policy is 
exactly opposite depending on whether the business use is encryption of 
authentication).

a straight-forward authentication issue might be whether a particular 
message originated from a specific entity. That would not necessarily 
include the sense that the entity agreed with the terms and conditions 
described in the body of the message (say a financial transaction). This is 
somewhat akin to various EULA agreements that have people clicking on 
various buttons  which is not an issue of authentication but of 
agreement; aka *repudiation* can include things that are outside the scope 
of authentication (not whether the message originated from me ... but do i 
fully agree with what is included in the body of the message).  neither 
identification nor authentication by itself can necessarily include the 
concept of agreement. repudiation can include a number of items outside the 
sense of identification and authentication (like aggreement).

--
Anne  Lynn Wheelerhttp://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 [EMAIL PROTECTED]


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-09 Thread Jerrold Leichter
| Non-repudiation applied to digital signatures implies that the definition
| states that only one person possibly had possession of the private signing
| key and was conscious about the fact that it was used to sign something.
There is absolutely *no* cryptographic or mathematical content to this
definition!  It could as well apply to key locks, to signatures on paper,
or whatever.  It's in no way a property of a cryptographic system, or of
*any* system.  Nor, as written, is there even any possible set of evidence
that could be adduced to prove this:  After all, someone might, just by
chance, have guessed the private key.

Granted, there are significant issues with non-repudiation - so significant
that it probably isn't a very useful concept.  But it there *is* some
cryptographic content behind it!  Otherwise, what are we to make, for example,
of the various evolving signature key schemes that detect stolen keys?

-- Jerry

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


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-09 Thread Ed Gerck
Jerrold Leichter wrote:

 Now that we've trashed non-repudiation ...

Huh? Processes that can be conclusive are useful and do exist, I read here,
in the legal domain. It may not be so clear how such processes can exist in
the technical domain and that's why I'm posting ;-)

 just how is it different from authentication?

Using an information theory model, it's clear that authentication needs one
channel of information (e.g., the CA's public key, the password list) in addition
to the signal (e.g., a signed message, a username/password entry). Authentication
rests on the information channel being trusted (i.e., independently verifiable). In
this model, non-repudiation is different because it needs at least one additional
out-of-band signal (where authenticated absence of the signal is also effective).
BTW, that's why digital signatures per se are repudiable -- there's no second,
out-of-band signal.

An additional technical difference is that authentication promotes strength of
evidence while non-repudiation promotes lack of repudiation of evidence.
The latter is intuitively recognized to be stronger because  a single, effective
denial of an act can rebuke any number of strong affirmations.

This also means, intuitively,  that another difference exists. Non-repudiation
should be harder to accomplish than authentication (you want more, you need
to pay more). However, to the  extent that the process *can be* conclusive,
non-repudiation may be worth it. Imagine the added costs, time and hassle
(going back to a real-world comparison) if your bank would have to call you
to confirm payment for every check you sign? This would be the case if
paying a check could not be cast as a conclusive process for the bank (i.e.,
without the possibility of an irrebuttable presumption of payability).

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


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-09 Thread Ian Grigg
Ed Gerck wrote:


 Likewise, in a communication process, when repudiation of an act by a party is
 anticipated, some system security designers find it useful to define 
 non-repudiation
 as a service that prevents the effective denial of an act. Thus, lawyers should
 not squirm when we feel the same need they feel -- to provide for processes
 that *can be* conclusive.

The problem with this is that the squirms happen at
many levels.  It seems unlikely that we can provide
for conclusive processes when it comes to mixing
humans and tech and law.  If we try, we end up with
the Ross Anderson scenario - our work being trashed
in front of the courts.

Hence the need for a new framework.  Talk of non-
repudiation has gone to the extent of permitting
law makers to create new presumptions which - I
suggest - aren't going to help anyone.  For example,
the law that Pelle posted recently said one thing to
me:  no sane person wants to be caught dead using
these things:

   Pelle wrote:
   The real meat of the matter is handled in Article 31 (Page 10). Guarantees 
   derived from the acceptance of a Certificate:

The subscriber, at the time of accepting a certificate, guarantees all the
 
people of good faith to be free of fault, and his information contained 
within is correct, and that: 

1. The authenticated electronic company/signature verified by means of this 
certificate, was created under his exclusive control.

2. No person has had access to the procedure of generation of the electronic 
signature.

3. The information contained in the certificate is true and corresponds to 
the provided one by this one to the certification organization.


Is that for real?  Would you recommend that to
your mother?  I wouldn't be embarrassed to predict
that there will be no certificate systems in
Panama that rely upon that law.



I think aiming at conclusivity might be a noble
goal for protocol designers and others lower
down in the stack.  When humans are involved,
the emphasis should switch to reduction in costs:
strength of evidence, fast surfacing of problems,
sharing of information, crafting humans' part in
the protocol.

When I design financial systems, I generally think
in these terms:  what can I do to reduce the cost
and frequency of disputes?  I don't aim for any
sort of conclusivity at any costs, because that
can only be done by by setting up assumptions
that are later easily broken by real life.

Instead, I tend to examine the disputes that
might occur and examine their highest costs.
One of the easiest ways to deal with them is
to cause them to occur frequently, and thus
absorb them into the protocol.  For example,
a TCP connection breaks - did the packet get
there or not?  Conclusion: connections cannot
be relied upon.  Protocol response:  use a
datagram + request-reply + replay paradigm,
and lose a lot of connections, deliberately.
Conclusivity is achieved, at the cost of some
efficiency.

Another example - did the user sign the message?
We can't show what the user did with the key.
So, make the private key the agent, and give it
the legal standing.  Remove the human from the
loop.  Make lots of keys, and make the system
psuedonymous.  We can conclusively show that
the private key signed the message, and that
agent is to whom our contractual obligations
are directed.

Technical conclusivity is achieved, at the
expense of removing humans.  The dispute that
occurs then is when humans enter the loop
without fully understanding how they have
delegated their rights to their software
agent (a.k.a. private key).  We don't deny
his repudiating, we simply don't accept his
standing - only the key has standing.

Which brings us full circle to Panama :-)
Except, we've done it on our own contract
terms, not on the terms of the legislature,
so we can craft it with appropriate limits
rather than their irrebuttable presumptions.

From this pov, the mistake that CAs make
is to presume one key and one irrebuttable
presumption.  It's a capabilities thing;
there should be a squillion keys, each with
tightly controlled and surfaced rights.


iang

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


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-09 Thread John Lowry
Non-repudiation is really very simple in concept.

The ability to prove to a third party that you (or someone else) was party
to a transaction.

There are a lot of problems regarding who the third party must be, what
constitutes proof, etc., etc.

In the English common-law system, this is applied in various ways and times.
It all comes down to concepts of reasonableness, intent, care and so
on.

Can you say convince the judge or jury of your peers ?

The same is true for authentication.

John



On 1/7/04 15:06, Anton Stiglic [EMAIL PROTECTED] wrote:

 
 - Original Message -
 From: Jerrold Leichter [EMAIL PROTECTED]
 Cc: Cryptography [EMAIL PROTECTED]
 Sent: Wednesday, January 07, 2004 7:14 AM
 Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
 
 
 Now that we've trashed non-repudiation ... just how is it different from
 authentication?
 
 I don't think the word authentication has the same problem as
 non-repudiation,
 but you do need to be careful how you define it.
 
 So here we are talking about entity authentication (as opposed to data
 authentication,
 the latter really has a unambiguous definition, at least I hope it does!).
 
 The way you should define entity authentication
 is by stating that it is a process of verifying that an entity possesses the
 authentication
 credentials associated to a user that entity claims to be.  This entity
 might be the rightful
 user, or it might be someone who stole the credentials from the rightful
 user.   If someone
 stole my ATM card and my PIN, he/she can successfully authenticate
 him/herself to an
 ATM and withdraw money.  The word authenticate is appropriate in this last
 phrase.
 
 But I see that most definitions that have been collected here:
 http://www.garlic.com/~lynn/secgloss.htm#t523
 are not careful about this.
 
 The thing about non-repudiation is that it is something that even most laws
 do not
 permit.  See for example:
 http://www.firstmonday.dk/issues/issue5_8/mccullagh/
 
 Non-repudiation applied to digital signatures implies that the definition
 states that
 only one person possibly had possession of the private signing key and was
 conscious
 about the fact that it was used to sign something.
 
 In most jurisdictions a person has the right to repudiate a signature
 (had-written
 or electronic), and thus non-repudiation does not work.  People have the
 right to
 repudiate signatures since it might be the result of a forgery, fraud, the
 signer might have
 been drunk or something at the time of signing or forced to sign (like with
 a gun to his
 head).Repudiation is possible but non-repudiation is not.
 
 I know some people who use the term accountability instead of
 non-repudiation
 to express the property needed in certain systems (commercial
 infrastructures where
 users login and need to be accountable for their acts).  This seems like a
 better term
 to be used in certain contexts, but I'm still thinking about it...
 
 --Anton
 
 
 
 
 
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

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


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-09 Thread Arnold G. Reinhold
I did a Google search on irrebuttable presumption and found a lot 
of interesting material. One research report on the State of 
Connecticut web site

http://www.cga.state.ct.us/2003/olrdata/ph/rpt/2003-R-0422.htm

says: The Connecticut Supreme Court and the U. S. Supreme Court have 
held that irrebuttable presumptions are unconstitutional when they 
are not necessarily or universally true and the state has reasonable 
alternative means of making the determination.

The comment appears to apply to statutes and regulations (as opposed 
to contracts).  Still the two tests mentioned seem very appropriate 
to a discussion of non-repudiation as used in cryptography. In 
deciding whether the existence of a verified signature should 
automatically lead to some real world action, we should consider both 
the adequacy of the technology and the nature of the application.

So, for example, the military might adopt an irrebuttable presumption 
that a cryptographically signed order comes from the registered owner 
of a cryptographic key, because it has vetted all the technology 
employed, it can't tolerate delay, and  is willing to impose a duty 
on a key holders to protect their key or suffer the consequences.

On the other end of the scale, anti-spam software might accept a 
signature validated by a public key that is included in a user's 
white list as conclusive proof that the message should be transmitted 
to that user because the consequences of doing so with a forged 
message are so minute.

In the case of ordinary consumer transactions, an irrebuttable 
presumption for public key signatures would not seem to pass muster. 
There are too many problems with the technology (its not just a 
question of protecting the private key, but also of insuring the the 
document actually signed is the one the user thought he was signing) 
and there are usually other forms of evidence (e.g. delivery records) 
to substantiate the transaction.

This is apparently a very complex area of law. Another paper
http://www.law.nyu.edu/clppt/program2003/readings/Franck.doc
includes these quotes:
Every writer of sufficient intelligence to appreciate the 
difficulties of the subject matter has approached the topic of 
presumptions with a sense of hopelessness and left it with a feeling 
of despair.5  Commenting on the law of presumptions, Judge Learned 
Hand has commented: Judges have mixed it up until nobody can tell 
what on earth it means.6

It sounds like the legal profession long ago recognized the 
difficulties the cryptographic community is now grappling with regard 
to non-repudiation.  We should be very wary of assuming 
mathematical constructs naturally transform into the legal arena.

Arnold Reinhold
(who is not a lawyer)
 5  Edmund M. Morgan, Presumptions, 12 Wash. L. Rev. 255, 255 (1937).
 6  L. Hand, 18 ALI Proceedings 217-18 (1941).
At 5:32 PM -0800 1/5/04, Ed Gerck wrote:
 

In business, when repudiation of an act is anticipated we're reminded by
Nicholas Bohm (whose clear thinking I know and appreciate for 6 years)
that some lawyers find it useful to define irrebuttable presumptions  -- a
technique known to the law and capable of being instantiated in 
statute or contract.

For example, a legal irrebuttable presumption can take the form of 
a bank check
contract stating that a check (even though it can be *proven* a 
posteriori to be a
forgery) is payable by the bank if the account holder did not notify 
the bank to
repudiate the check *before* the check was presented to the bank for payment.
The requirement can be seen an out-of-band signal from the account holder to
the bank, which absence makes the check's payability an irrebuttable 
presumption
by the bank. In this case, as long as the check's signature does not 
look like a
(obvious) forgery and there is enough balance in the account, the bank has no
liability to that customer in paying the check. Note also that the 
effectiveness of
this method relies on an indirect proof -- the absence of a 
previous communication
makes the check payable.

Likewise, in a communication process, when repudiation of an act by a party is
anticipated, some system security designers find it useful to define 
non-repudiation
as a service that prevents the effective denial of an act. Thus, 
lawyers should
not squirm when we feel the same need they feel -- to provide for processes
that *can be* conclusive.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-08 Thread Anton Stiglic

- Original Message - 
From: Jerrold Leichter [EMAIL PROTECTED]
Cc: Cryptography [EMAIL PROTECTED]
Sent: Wednesday, January 07, 2004 7:14 AM
Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]


 Now that we've trashed non-repudiation ... just how is it different from
 authentication?

I don't think the word authentication has the same problem as
non-repudiation,
but you do need to be careful how you define it.

So here we are talking about entity authentication (as opposed to data
authentication,
the latter really has a unambiguous definition, at least I hope it does!).

The way you should define entity authentication
is by stating that it is a process of verifying that an entity possesses the
authentication
credentials associated to a user that entity claims to be.  This entity
might be the rightful
user, or it might be someone who stole the credentials from the rightful
user.   If someone
stole my ATM card and my PIN, he/she can successfully authenticate
him/herself to an
ATM and withdraw money.  The word authenticate is appropriate in this last
phrase.

But I see that most definitions that have been collected here:
http://www.garlic.com/~lynn/secgloss.htm#t523
are not careful about this.

The thing about non-repudiation is that it is something that even most laws
do not
permit.  See for example:
http://www.firstmonday.dk/issues/issue5_8/mccullagh/

Non-repudiation applied to digital signatures implies that the definition
states that
only one person possibly had possession of the private signing key and was
conscious
about the fact that it was used to sign something.

In most jurisdictions a person has the right to repudiate a signature
(had-written
or electronic), and thus non-repudiation does not work.  People have the
right to
repudiate signatures since it might be the result of a forgery, fraud, the
signer might have
been drunk or something at the time of signing or forced to sign (like with
a gun to his
head).Repudiation is possible but non-repudiation is not.

I know some people who use the term accountability instead of
non-repudiation
to express the property needed in certain systems (commercial
infrastructures where
users login and need to be accountable for their acts).  This seems like a
better term
to be used in certain contexts, but I'm still thinking about it...

--Anton







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


Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-07 Thread Jerrold Leichter
Now that we've trashed non-repudiation ... just how is it different from
authentication?  In both cases, there is a clear technical meaning (though as
with anything in mathematics, when you get right down to it, the details are
complex and may be important):  To produce an authenticator/non-repudiable
signature, you must have access to the secret.  There isn't, at this level,
even any difference between the requirements for the two.  Where we get into
trouble is in attempting to bind the real world to the mathematics.  In each
case, the receiver wants to be able to say:

 1. I can rely on the fact that X sent me this data, because it came
with a signature that could be calculated only by X.

What he *really* needs to say is:

 2. I can rely on the fact that X sent me this data, because it came
with a signature that could be calculated only by someone knowing X's
secret.

To go from 2 to 1, the receiver must also have:

 3. I can rely on the fact that only X knows X's secret.

In ordinary English usage, there is little difference between I've authenti-
cated this message as coming from X and X can't deny that he wrote this
message.  We've learned that non-repudiation is a concept with relatively
little use in the legal system.  However, authentication (of a signature,
document, whatever) is quite common (even if for the usual kinds of objects
that need authentication, there is generally little to discuss).  If the
ultimate question is whether, as a legal matter, X is bound by some writing
or whatever, authentication gets at the same basic question (which is only
part, usually a small part, of the relevant legal issues).

The problems that we've been discussion here are clear from 2 and 3:

- Rely on is inherently outside of the cryptography or mathematics.
It's only meaningful to the extent that there is some recourse
(generally through agreements, but ultimately through the legal
system) if you rely on something that turns out not be what
you thought it was.

- We identify X with an individual, but in fact X rarely knows
the secret personally, and never does the actual calculations -
some code running in some real physical machine does the work.

So in fact we can't even begin to get 3; at best, we have:

3'. I can rely on the fact that, if X has shared his secret with Y (where
Y is typically some equipment), then I can rely on X to be bound by
whatever Y does.

This is now so bizarre and removed from ordinary notions that it should be
clear why it's unlikely be of much real-world use!

-- Jerry

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