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]


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

2004-01-02 Thread John Kelsey
 At 06:24 PM 12/23/03 -0700, Richard Johnson wrote:
...
In my eperience, the terminology has more often been confidentiality,
integrity, and authentication.  Call it CIA if you need an acronym easy
to memorize, if only due to its ironic similarity with that for the name of
a certain US government agency. :-)
Surely a better government-related TLA for this would be derived from 
Non-changeability, Secrecy, and Authentication  :)

Richard
--John Kelsey, [EMAIL PROTECTED]
PGP: FA48 3237 9AD5 30AC EEDD  BBC8 2A80 6948 4CAA F259
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-30 Thread Amir Herzberg
At 18:02 29/12/2003, Ben Laurie wrote:
Amir Herzberg wrote:
...
specifications, I use `non-repudiation` terms for some of the 
requirements. For example, the intuitive phrasing of the Non-Repudiation 
of Origin (NRO) requirement is: if any party outputs an evidence evid 
s.t. valid(agreement, evid, sender, dest, message, time-interval, NRO), 
then either the sender is corrupted or sender originated message to the 
destination dest during the indicated time-interval. Notice of course 
that sender here is an entity in the protocol, not the human being 
`behind` it. Also notice this is only intuitive description, not the 
formal specifications.
What you have here is evidence of origin, not non-repudiation.
Ben, thanks, I'll change to this term (`evidence` instead of 
`non-repudiation`) since it appears from this thread that it may avoid 
confusion (at least for some people).

Best regards,

Amir Herzberg
Computer Science Department, Bar Ilan University
Homepage (and lectures in applied cryptography, secure communication and 
commerce): http://amir.herzberg.name

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


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

2003-12-29 Thread Ben Laurie
Amir Herzberg wrote:

Ian proposes below two draft-definitions for non-repudiation - legal and 
technical. Lynn also sent us a bunch of definitions. Let's focus on the 
technical/crypto one for now - after all this is a crypto forum (I agree 
the legal one is also somewhat relevant to this forum).

In my work on secure e-commerce, I use (technical, crypto) definitions 
of non-repudiation, and consider these as critical to many secure 
e-commerce problems/scenarios/requirements/protocols. Having spent 
considerable time and effort on appropriate definitions and analysis 
(proofs), I was/am a bit puzzled and alarmed to find that others in our 
community seem so vehemently against non-repudiation.

Of course, like other technical terms, there can be many variant 
definitions; that is not really a problem (the community will gradually 
focus on few important and distinct variants). Also it's an unavoidable 
fact of life (imho) that other communities (e.g. legal) use the same 
term in somewhat different meaning.

So my question is only to people like Ben and Carl who have expressed, 
if I understood correctly, objection to any form of technical, crypto 
definition of non-repudiation. I repeat: do you really object and if so 
why?
I object because its not a technical, crypto concept. It doesn't matter 
what you do to try to achieve non-repudiation technically, I can always 
repudiate it - all I have to do is say I didn't sign that or it 
wasn't me that initiated that transaction.

What of applications/scenarios that seem to require 
non-repudiation, e.g. certified mail, payments, contract signing,...?
These do not require non-repudiation in the existing world, why do they 
suddenly need it when they become electronic?

What I presume you are trying to get at is to distinguish the use of a 
key with an intent to bind you rather than with an intent to provide 
authentication (or some other service signing can provide). This is not 
non-repudiation, it's something else, and it only confuses matters to 
use the wrong word for it.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-29 Thread Ben Laurie
Carl Ellison wrote:
If you want to use cryptography for e-commerce, then IMHO you need a
contract signed on paper, enforced by normal contract law, in which one
party lists the hash of his public key (or the whole public key) and says
that s/he accepts liability for any digitally signed statement that can be
verified with that public key.
One of the things my paper discusses is that under UK law a signature on 
an email is just as binding as on paper, because contracts are all about 
intent to be bound and not the medium in which they are captured. Of 
course, if you want to repudiate an email it is probably easier, 
especially if you signed it by typing your name at the bottom (yes, this 
is a valid signature under UK law), but that's a judgement call on the 
part of the relying party.

Any attempt to just assume that someone's acceptance of a PK
certificate amounts to that contract is extremely dangerous, and might even
be seen as an attempt to victimize a whole class of consumers.
Agreed - as I say, its all about intent and reliance. Nothing is automatic.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-29 Thread Ben Laurie
Carl Ellison wrote:

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kelm
Sent: Tuesday, December 23, 2003 1:44 AM
To: [EMAIL PROTECTED]
Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)


Ah. That's why they're trying to rename the corresponding keyUsage bit
to contentCommitment then:
 http://www.pki-page.info/download/N12599.doc

:-)

Cheers,

	Stefan.


Maybe, but that page defines it as:

--

contentCommitment: for verifying digital signatures which are intended to
signal that the signer is committing to the content being signed. The
precise level of commitment, e.g. with the intent to be bound may be
signaled by additional methods, e.g. certificate policy.
Since a content commitment signing is considered to be a digitally signed
transaction, the digitalSignature bit need not be set in the certificate. If
it is set, it does not affect the level of commitment the signer has endowed
in the signed content.
Note that it is not incorrect to refer to this keyUsage bit using the
identifier nonRepudiation. However, the use this identifier has been
deprecated. Regardless of the identifier used, the semantics of this bit are
as specified in this standard.
--

Which still refers to the signer having an intent to be bound.  One can
not bind a key to anything, legally, so the signer here must be a human or
organization rather than a key.  It is that unjustifiable linkage from the
actions of a key to the actions of one or more humans that needs to be
eradicated from the literature.
This is going a little far, isn't it? If the human controls the setting 
of the bit, then it is signalling their intent.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-29 Thread Ben Laurie
Amir Herzberg wrote:

At 04:20 25/12/2003, Carl Ellison wrote:
...
If you want to use cryptography for e-commerce, then IMHO you 
need a
contract signed on paper, enforced by normal contract law, in which one
party lists the hash of his public key (or the whole public key) and says
that s/he accepts liability for any digitally signed statement that 
can be
verified with that public key.


Of course! I fully agree; in fact the first phase in the `trusted 
delivery layer` protocols I'm working on is exactly that - ensuring that 
the parties (using some external method) agreed on the keys and the 
resulting liability. But when I define the specifications, I use 
`non-repudiation` terms for some of the requirements. For example, the 
intuitive phrasing of the Non-Repudiation of Origin (NRO) requirement 
is: if any party outputs an evidence evid s.t. valid(agreement, evid, 
sender, dest, message, time-interval, NRO), then either the sender is 
corrupted or sender originated message to the destination dest during 
the indicated time-interval. Notice of course that sender here is an 
entity in the protocol, not the human being `behind` it. Also notice 
this is only intuitive description, not the formal specifications.
What you have here is evidence of origin, not non-repudiation.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-28 Thread Amir Herzberg
Ian proposes below two draft-definitions for non-repudiation - legal and 
technical. Lynn also sent us a bunch of definitions. Let's focus on the 
technical/crypto one for now - after all this is a crypto forum (I agree 
the legal one is also somewhat relevant to this forum).

In my work on secure e-commerce, I use (technical, crypto) definitions of 
non-repudiation, and consider these as critical to many secure e-commerce 
problems/scenarios/requirements/protocols. Having spent considerable time 
and effort on appropriate definitions and analysis (proofs), I was/am a bit 
puzzled and alarmed to find that others in our community seem so vehemently 
against non-repudiation.

Of course, like other technical terms, there can be many variant 
definitions; that is not really a problem (the community will gradually 
focus on few important and distinct variants). Also it's an unavoidable 
fact of life (imho) that other communities (e.g. legal) use the same term 
in somewhat different meaning.

So my question is only to people like Ben and Carl who have expressed, if I 
understood correctly, objection to any form of technical, crypto definition 
of non-repudiation. I repeat: do you really object and if so why? What of 
applications/scenarios that seem to require non-repudiation, e.g. certified 
mail, payments, contract signing,...?

Best regards,

Amir Herzberg
Computer Science Department, Bar Ilan University
Lectures: http://www.cs.biu.ac.il/~herzbea/book.html
Homepage: http://amir.herzberg.name
Enclosed: At 21:33 23/12/2003, Ian Grigg wrote:
Amir Herzberg wrote:

 Ben, Carl and others,

 At 18:23 21/12/2003, Carl Ellison wrote:

   and it included non-repudiation which is an unachievable,
   nonsense concept.

 Any alternative definition or concept to cover what protocol designers
 usually refer to as non-repudiation specifications? For example
 non-repudiation of origin, i.e. the ability of recipient to convince a
 third party that a message was sent (to him) by a particular sender (at
 certain time)?

 Or - do you think this is not an important requirement?
 Or what?
I would second this call for some definition!

FWIW, I understand there are two meanings:

   some form of legal inability to deny
   responsibility for an event, and
   cryptographically strong and repeatable
   evidence that a certain piece of data
   was in the presence of a private key at
   some point.
Carl and Ben have rubbished non-repudiation
without defining what they mean, making it
rather difficult to respond.
Now, presumably, they mean the first, in
that it is a rather hard problem to take the
cryptographic property of public keys and
then bootstrap that into some form of property
that reliably stands in court.
But, whilst challenging, it is possible to
achieve legal non-repudiability, depending
on your careful use of assumptions.  Whether
that is a sensible thing or a nice depends
on the circumstances ... (e.g., the game that
banks play with pin codes).
So, as a point of clarification, are we saying
that non-repudiability is ONLY the first of
the above meanings?  And if so, what do we call
the second?  Or, what is the definition here?
From where I sit, it is better to term these
as legal non-repudiability or cryptographic
non-repudiability so as to reduce confusion.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-28 Thread Ed Gerck
Yes, the term non-repudiation has been badly misused in
old PKIX WG drafts (in spite of warnings by myself and
others) and some crypto works of reference -- usually
by well-intentioned but otherwise misguided people trying
to add value to digital certificates.

However, IMO non-repudiation refers to a useful and
essential cryptographic primitive. It does not mean the
affirmation of a truth (which is authentication). It means
the denial of a falsity -- such as:

(1) the ability to prevent the effective denial of an act (in
other words, denying the act becomes a falsity); or

(2) the ability to prevent the denial of the origin or delivery
of transactions.

Note that, except for a boolean system, the affirmation of
a truth is not the same as the denial of a falsity. Hence, the
usefulness of non-repudiation as a primitive. Take away
non-repudiation and you end up with a lesser language
with which to describe security processes.

Cheers,
Ed Gerck

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


RE: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-28 Thread Carl Ellison
Amir,

my objection is to the word sender which, in definitions I've
read, refers to the human being associated with a particular key.  As long
as we refer to a private key with no implication that this in any way incurs
liability for a human being, then I'm happy -- but e-commerce folks are not.

It is important to be able to authenticate a message origin and
verify its integrity - the things that a dsig or MAC give you.  When you use
a public-key dsig, you have the added security advantage that the key
capable of forming that signature does not need to be used to verify it.
This is the original technical meaning of the term we're struggling over.
However, in Diffie and Hellman's original paper, (which referred to this as
undeniable, if I remember correctly), the confusion had already set in.  A
key would never deny or repudiate anything. That's an action by a human
being.  However, the use of public key cryptography does not imply anything
about the human being to whom that key pair was assigned.

So, I would use the terms authentication and integrity
verification and avoid the term non-repudiation, since that one refers to
human behavior and invokes liability on human beings.  Since we have no idea
how to make computer systems that capture proof of a human being's behavior
and intentions, we can not claim to have any evidence that could be
presented in court to show that a particular human being made a particular
commitment, just based on some digital signature.  We can prove that a given
private key (to wit, the one private key corresponding to a public key that
is entered into evidence) formed a signature over some message or file.
However, any attempt to infer more than that is fallacious.

If you want to use cryptography for e-commerce, then IMHO you need a
contract signed on paper, enforced by normal contract law, in which one
party lists the hash of his public key (or the whole public key) and says
that s/he accepts liability for any digitally signed statement that can be
verified with that public key.

Any attempt to just assume that someone's acceptance of a PK
certificate amounts to that contract is extremely dangerous, and might even
be seen as an attempt to victimize a whole class of consumers.

 - Carl

+--+
|Carl M. Ellison [EMAIL PROTECTED]  http://theworld.com/~cme |
|PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71   |
+---Officer, arrest that man. He's whistling a copyrighted song.---+ 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Amir Herzberg
 Sent: Tuesday, December 23, 2003 1:18 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)
 
 Ben, Carl and others,
 
 At 18:23 21/12/2003, Carl Ellison wrote:
 
   and it included non-repudiation which is an unachievable,
   nonsense concept.
 
 Any alternative definition or concept to cover what protocol 
 designers 
 usually refer to as non-repudiation specifications? For example 
 non-repudiation of origin, i.e. the ability of recipient to 
 convince a 
 third party that a message was sent (to him) by a particular 
 sender (at 
 certain time)?
 
 Or - do you think this is not an important requirement?
 Or what?
 
 
 Best regards,
 
 Amir Herzberg
 Computer Science Department, Bar Ilan University
 Lectures: http://www.cs.biu.ac.il/~herzbea/book.html
 Homepage: http://amir.herzberg.name
 
 -
 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: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-28 Thread Carl Ellison
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kelm
 Sent: Tuesday, December 23, 2003 1:44 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)

 Ah. That's why they're trying to rename the corresponding keyUsage bit
 to contentCommitment then:
 
   http://www.pki-page.info/download/N12599.doc
 
 :-)
 
 Cheers,
 
   Stefan.

Maybe, but that page defines it as:

--

contentCommitment: for verifying digital signatures which are intended to
signal that the signer is committing to the content being signed. The
precise level of commitment, e.g. with the intent to be bound may be
signaled by additional methods, e.g. certificate policy.

Since a content commitment signing is considered to be a digitally signed
transaction, the digitalSignature bit need not be set in the certificate. If
it is set, it does not affect the level of commitment the signer has endowed
in the signed content.

Note that it is not incorrect to refer to this keyUsage bit using the
identifier nonRepudiation. However, the use this identifier has been
deprecated. Regardless of the identifier used, the semantics of this bit are
as specified in this standard.

--

Which still refers to the signer having an intent to be bound.  One can
not bind a key to anything, legally, so the signer here must be a human or
organization rather than a key.  It is that unjustifiable linkage from the
actions of a key to the actions of one or more humans that needs to be
eradicated from the literature.

 - Carl


+--+
|Carl M. Ellison [EMAIL PROTECTED]  http://theworld.com/~cme |
|PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71   |
+---Officer, arrest that man. He's whistling a copyrighted song.---+ 

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


RE: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-28 Thread Carl Ellison
Amir,

I am glad to see that you are treating this seriously.

It is always possible to use the term non-repudiation for some
legitimately defined thing - but I personally would prefer not to use the
term because it has been tarred by over a decade of misuse (implying some
presumption of liability on the part of a human being as a result of the
behavior of a cryptographic key).

I wish you luck with your protocols and look forward to seeing them.

 - Carl


+--+
|Carl M. Ellison [EMAIL PROTECTED]  http://theworld.com/~cme |
|PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71   |
+---Officer, arrest that man. He's whistling a copyrighted song.---+ 

 -Original Message-
 From: Amir Herzberg [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, December 25, 2003 2:47 AM
 To: Carl Ellison; [EMAIL PROTECTED]
 Subject: RE: Non-repudiation (was RE: The PAIN mnemonic)
 
 At 04:20 25/12/2003, Carl Ellison wrote:
 ...
  If you want to use cryptography for e-commerce, 
 then IMHO you need a
 contract signed on paper, enforced by normal contract law, 
 in which one
 party lists the hash of his public key (or the whole public 
 key) and says
 that s/he accepts liability for any digitally signed 
 statement that can be
 verified with that public key.
 
 Of course! I fully agree; in fact the first phase in the 
 `trusted delivery 
 layer` protocols I'm working on is exactly that - ensuring 
 that the parties 
 (using some external method) agreed on the keys and the resulting 
 liability. But when I define the specifications, I use 
 `non-repudiation` 
 terms for some of the requirements. For example, the 
 intuitive phrasing of 
 the Non-Repudiation of Origin (NRO) requirement is: if any 
 party outputs an 
 evidence evid s.t. valid(agreement, evid, sender, dest, message, 
 time-interval, NRO), then either the sender is corrupted or sender 
 originated message to the destination dest during the indicated 
 time-interval. Notice of course that sender here is an entity in the 
 protocol, not the human being `behind` it. Also notice this is only 
 intuitive description, not the formal specifications.
 
   Best regards,
  
   Amir Herzberg
   Computer Science Department, Bar Ilan University
   Lectures: http://www.cs.biu.ac.il/~herzbea/book.html
   Homepage: http://amir.herzberg.name
  
   
 -
   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: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-28 Thread Ian Grigg
Carl Ellison wrote:

  From where I sit, it is better to term these
  as legal non-repudiability or cryptographic
  non-repudiability so as to reduce confusion.
 
 To me, repudiation is the action only of a human being (not of a key) and
 therefore there is no such thing as cryptographic non-repudiability.


Ah.  Now I understand.  The verb is wrong, as it
necessarily implies the act of the human who is
accused of the act.  (And, thus, my claim that it
is possible, was also wrong.)

Whereas the cryptographic property implies no such
thing, and a cryptographic actor can only affirm
or not, not repudiate.  I.e., it's a meaningless
term.


 We
 need a different, more precise term for that -


Would irrefutable be a better term?  Or non-
refutability, if one desires to preserve the N?

The advantage of this verb is that it has no
actor involved, and evidence can be refuted on
its own merits, as it were.

As a test, if one were to replace repudiate
with refute in the ISO definition, would it
then stand?


 and we need to rid our
 literature and conversation of any reference to the former - except to
 strongly discredit it if/when it ever appears again.

I think more is needed.  A better definition is
required, as absence is too easy to ignore.  People
and courts will use what they have available, so it
is necessary to do more; indeed it is necessary to
actively replace that term with another.

Generally, the way the legal people work is to
create simple tests.  Such as:

  A Document was signed by a private key if:

  1. The signature is verifiable by the public key,
  2. the public key is paired with the private key,
  3. the signature is over a cryptographically strong
 message digest,
  4. the Message Digest was over the Document.

Now, this would lead to a definition of irrefutable
evidence.  How such evidence would be used would be
of course dependent on the circumstances;  it then
becomes a further challenge to tie a human's action
to that act / event.



iang


PS: Doing a bit of googling, I found the ISO definition
to be something like:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0149.html
 ... The ISO
 10181-4 document (called non repudiation Framework) starts with:
 The goal of the non-repudiation service is to collect, maintain,
 make available and validate irrefutable evidence concerning a
 claimed event or action in order to solve disputes about the
 occurrence of the event or action.

But, the actual standard costs money (!?) so it is
not surprising that it is the subject of much
controversy :)

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


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

2003-12-28 Thread Ben Laurie
Ian Grigg wrote:
Carl and Ben have rubbished non-repudiation
without defining what they mean, making it
rather difficult to respond.
I define it quite carefully in my paper, which I pointed to.

Now, presumably, they mean the first, in
that it is a rather hard problem to take the
cryptographic property of public keys and
then bootstrap that into some form of property
that reliably stands in court.
But, whilst challenging, it is possible to
achieve legal non-repudiability, depending
on your careful use of assumptions.  Whether
that is a sensible thing or a nice depends
on the circumstances ... (e.g., the game that
banks play with pin codes).
Actually, its very easy to achieve legal non-repudiability. You pass a 
law saying that whatever-it-is is non-repudiable. I also cite an example 
of this in my paper (electronic VAT returns are non-repudiable, IIRC).

So, as a point of clarification, are we saying
that non-repudiability is ONLY the first of
the above meanings?  And if so, what do we call
the second?  Or, what is the definition here?
From where I sit, it is better to term these
as legal non-repudiability or cryptographic
non-repudiability so as to reduce confusion.
Read my paper (it was co-authored with a lawyer, so I believe we've got 
both the crypto and legal versions covered).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-28 Thread Ian Grigg
Ben Laurie wrote:
 
 Ian Grigg wrote:
  Carl and Ben have rubbished non-repudiation
  without defining what they mean, making it
  rather difficult to respond.
 
 I define it quite carefully in my paper, which I pointed to.


Ah.  I did read your paper, but deferred any comment
on it, in part because I didn't understand what its
draft/publication status was.


Ben Laurie said:
 Probably because non-repudiation is a stupid idea:
 http://www.apache-ssl.org/tech-legal.pdf.


You didn't state which of the two definitions
you were rubbishing, so I shall respond to both!



Let's take the first definition - your technical
definition (2.7):

  Non-repudiation, in its technical sense, is a property of a communications
  system such that the system attributes the sending of a message to a person
  if, but only if, he did in fact send it, and records a person as having received
  a message if, but only if, he did in fact receive it. If such systems exist at all,
  they are very rare.

  Non-repudiability is often claimed to be a property of electronic signatures of
  the kind described above. This claim is unintelligible if non-repudiation is
  used in its correct technical sense, and in fact represents an attempt to confer a
  bogus technical respectability on the purely commercial assertion the the owners
  of private keys should be made responsible for their use, whoever in fact uses
  them.

Some comments.

1. This definition seems to be only one of the many
out there [1].  The use of the term correct technical
sense then would be meaningless as well as brave
without some support of references.  Although it does
suffice to ground the use within the paper.

2. The definition is muddied by including the attack
inside the definition.  The attack on the definition would
fit better in section 6. Is \non-repudiation a useful
concept?

3. Nothing in either the definition 2.7 or the proper
section of 6. tells us above why the claim is unintelligable.

To find this, we have to go back to Carl's comment
which gets to the nub of the legal and literal meaning
of the term:

To me, repudiation is the action only of a human being (not of a key)...

Repudiate can only be done by a human [2].  A key cannot
repudiate, nor can a system of technical capabilities [3].
(Imagine here, a debate on how to tie the human to the
key.)

That is, it is an agency problem, and unless clearly
cast in those terms, for which there exists a strong
literature, no strong foundation can be made of any
conclusions [4].



4. The discussion resigns itself to being somewhat
dismissive, by leaving open the possibility that
there are alternative possibilities.  There is
a name for this fallacy, stating the general and
showing only the specific, but I forget its name.

In the first para, 2.7, it states that If such systems
exist at all, they are very rare.  Thus, allowing
for existance.  Yet in the second para, one context
is left as unintelligable.  In section 6, again,
most discussions ... are more confusing than helpful.

This hole is created, IMHO, by the absence of Carl's
killer argument in 3. above.  Only once it is possible
to move on from the fallacy embodied in the term
repudiation itself, is it possible to start considering
what is good and useful about the irrefutability (or
otherwise) of a digital signature [5].

I.e., throwing out the bathwater is a fine and regular
thing to do.  Let's now start looking for the baby.



  But, whilst challenging, it is possible to
  achieve legal non-repudiability, depending
  on your careful use of assumptions.  Whether
  that is a sensible thing or a nice depends
  on the circumstances ... (e.g., the game that
  banks play with pin codes).
 
 Actually, its very easy to achieve legal non-repudiability. You pass a
 law saying that whatever-it-is is non-repudiable. I also cite an example
 of this in my paper (electronic VAT returns are non-repudiable, IIRC).

Which brings us to your second definition, again,
in 2.7:

To lawyers, non-repudiation was not a technical legal term before techies gave
it to them. Legally it refers to a rule which defines circumstances in which a
person is treated for legal purposes as having sent a message, whether in fact
he did or not, or is treated as having received a message, whether in fact he
did or not. Its legal meaning is thus almost exactly the opposite of its technical
meaning.


I am not sure that I'd agree that the legal
fraternity thinks in the terms outlined in the
second sentance.  I'd be surprised if the legal
fraternity said any more than what you are
trying to say is perhaps best seen by these
sorts of rules...

Much of law already duplicates what is implied
above, anyway, which makes one wonder (a) what
is the difference between the above and the
rules of evidence and presumption, etc, etc
and (b) why did the legal fraternity adopt
the techies' term with such abandon that they
didn't bother to define it?

In practice, the process of 

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

2003-12-28 Thread Richard Johnson
On Sun, Dec 21, 2003 at 09:45:54AM -0700, Anne  Lynn Wheeler wrote:
 note, however, when I did reference PAIN as (one possible) security 
 taxonomy  i tended to skip over the term non-repudiation and primarily 
 made references to privacy, authentication, and integrity.


In my eperience, the terminology has more often been confidentiality,
integrity, and authentication.  Call it CIA if you need an acronym easy
to memorize, if only due to its ironic similarity with that for the name of
a certain US government agency. :-)


Richard

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


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

2003-12-28 Thread Anne Lynn Wheeler
At 01:34 AM 12/24/2003 -0800, Ed Gerck wrote:
However, IMO non-repudiation refers to a useful and
essential cryptographic primitive. It does not mean the
affirmation of a truth (which is authentication). It means
the denial of a falsity -- such as:
(1) the ability to prevent the effective denial of an act (in
other words, denying the act becomes a falsity); or
(2) the ability to prevent the denial of the origin or delivery
of transactions.
so another way of looking at it ... is that somebody repudiates, refutes, 
and/or disavovs ... typically after the fact.

non-repudiation would be those things that would support countering claims 
of repudiation, refuting, and/or disavowing.

authentication is typically demonstrating that an entity is allowed to do 
something. authentication can include having a passphrase that is known by 
everybody in the organization. knowing the passphrase is sufficient to 
authenticate that somebody is allowed to do something. however, if somebody 
refutes that they had done something  showing that they knew the 
passphrase (known by everybody in the organization) isn't sufficient to 
counter the repudiation claim.

an infrastructure that requires a unique passphrase for every person would 
help counter repudiation claims

public/private asymmetric cryptography systems where the infrastructure 
requires that a single person only has access to a particular private key 
would help counter repudiation claims. In that sense  public/private 
key system can be seen as addressing both privacy and non-repudiation 
issues.  the policies governing the determination of private key in a 
asymmetric cryptography infrastructure can influence whether it just 
pertains to just privacy and authentication and/or whether it can also be 
used to counter repudiation claims.
while making sure that one  only one person has knowledge of a specific 
private key, in no way impacts the asymmetric cryptography operations 
...  the process can be used to countering repudiation claims.

while repudiation tends to be a human act  it is entirely possible to 
have infrastructure and organizational implementation features that support 
countering claims of repudiation when they occur.

say dozens of people know (the same) vault combination lock 
(authentication)   which doesn't do anything to counter a particular 
person's claim that they didn't enter the vault,
however video surveillance and door badge access logs could be considered 
as part of security taxonomy for countering repudiation claims.
--
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: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-28 Thread Peter Gutmann
Carl Ellison [EMAIL PROTECTED] writes:

Ah. That's why they're trying to rename the corresponding keyUsage bit
to contentCommitment then:

Maybe, but that page defines it as:

contentCommitment: for verifying digital signatures which are intended to
signal that the signer is committing to the content being signed. The
precise level of commitment, e.g. with the intent to be bound may be
signaled by additional methods, e.g. certificate policy.

This refers to the second (and IMHO more sensible) use of the X.509
nonRepudiation bit, which uses digitalSignature for short-term signing (e.g.
user authentication) and nonRepudiation for long-term signing (e.g. signing
a document).  The other definition uses digitalSignature for everything,
and nonRepudiation as an additional service on top of digitalSignature.  The
problem with that definition is that no two people in the X.509 world can
agree on what nonRepudiation actually signifies.  The best suggestion I've
seen for the nonRepudiation bit is that CAs should set it to random values
to disabuse users of the notion that it has any meaning.  For the
additional-service definition of nonRepudiation, the X.509 Style Guide 
says:

  Although everyone has their own interpretation, a good practical definition 
  is Nonrepudiation is anything which fails to go away when you stop 
  believing in it.  Put another way, if you can convince a user that it isn't 
  worth trying to repudiate a signature then you have nonrepudiation.  This 
  can take the form of having them sign a legal agreement saying they won't 
  try to repudiate any of their signatures, giving them a smart card and 
  convincing them that it's so secure that any attempt to repudiate a 
  signature generated with it would be futile, threatening to kill their kids, 
  or any other method which has the desired effect.  One advantage (for 
  vendors) is that you can advertise just about anything as providing 
  nonrepudiation, since there's sure to be some definition which matches 
  whatever it is you're doing (there are nonrepudiation schemes in use today 
  which employ a MAC using a secret shared between the signer and the verifier, 
  which must be relying on a particularly creative definition of 
  nonrepudiation).

Peter.

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


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

2003-12-26 Thread Ian Grigg
Amir Herzberg wrote:
 
 Ben, Carl and others,
 
 At 18:23 21/12/2003, Carl Ellison wrote:
 
   and it included non-repudiation which is an unachievable,
   nonsense concept.
 
 Any alternative definition or concept to cover what protocol designers
 usually refer to as non-repudiation specifications? For example
 non-repudiation of origin, i.e. the ability of recipient to convince a
 third party that a message was sent (to him) by a particular sender (at
 certain time)?
 
 Or - do you think this is not an important requirement?
 Or what?


I would second this call for some definition!

FWIW, I understand there are two meanings:

   some form of legal inability to deny
   responsibility for an event, and

   cryptographically strong and repeatable
   evidence that a certain piece of data
   was in the presence of a private key at
   some point.

Carl and Ben have rubbished non-repudiation
without defining what they mean, making it
rather difficult to respond.

Now, presumably, they mean the first, in
that it is a rather hard problem to take the
cryptographic property of public keys and
then bootstrap that into some form of property
that reliably stands in court.

But, whilst challenging, it is possible to
achieve legal non-repudiability, depending
on your careful use of assumptions.  Whether
that is a sensible thing or a nice depends
on the circumstances ... (e.g., the game that
banks play with pin codes).

So, as a point of clarification, are we saying
that non-repudiability is ONLY the first of
the above meanings?  And if so, what do we call
the second?  Or, what is the definition here?

From where I sit, it is better to term these
as legal non-repudiability or cryptographic
non-repudiability so as to reduce confusion.

iang

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


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

2003-12-26 Thread Anne Lynn Wheeler
At 11:18 AM 12/23/2003 +0200, Amir Herzberg wrote:
Any alternative definition or concept to cover what protocol designers 
usually refer to as non-repudiation specifications? For example 
non-repudiation of origin, i.e. the ability of recipient to convince a 
third party that a message was sent (to him) by a particular sender (at 
certain time)?
there is some reference in old posting in pkix thread:
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudation
possibly more than you want to know ... but merged security taxonomy and 
glossary ... sources at:
http://www.garlic.com/~lynn/index.html#glosnote

has definitions for:

non-repudiation
non-repudiation exchange
non-repudiation information
non-repudiation of creation
non-repudiation of delivery
non-repudiation of knowledge
non-repudiation of origin
non-repudiation of receipt
non-repudiation of sending
non-repudiation of submission
non-repudiation of transport
non-repudiation policy
non-repudiation service
non-repudiation token
plus:

NRD token
NRO token
NRS token
NRT token
--
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: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-23 Thread Amir Herzberg
Ben, Carl and others,

At 18:23 21/12/2003, Carl Ellison wrote:

 and it included non-repudiation which is an unachievable,
 nonsense concept.
Any alternative definition or concept to cover what protocol designers 
usually refer to as non-repudiation specifications? For example 
non-repudiation of origin, i.e. the ability of recipient to convince a 
third party that a message was sent (to him) by a particular sender (at 
certain time)?

Or - do you think this is not an important requirement?
Or what?
Best regards,

Amir Herzberg
Computer Science Department, Bar Ilan University
Lectures: http://www.cs.biu.ac.il/~herzbea/book.html
Homepage: http://amir.herzberg.name
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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

2003-12-23 Thread Stefan Kelm
 Let's just leave the term non-repudiation to be used by people who don't
 understand security, but rather mouth things they've read in books that
 others claim are authoritative.  There are lots of those books listing
 non-repudiation as a feature of public key cryptography, for example,
 and many listing it as an essential security characteristic.  All of that
 is wrong, of course, but it's a test for the reader to see through it.

Ah. That's why they're trying to rename the corresponding keyUsage bit
to contentCommitment then:

  http://www.pki-page.info/download/N12599.doc

:-)

Cheers,

Stefan.
---
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [EMAIL PROTECTED], http://www.secorvo.de
---
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

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


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

2003-12-23 Thread Anne Lynn Wheeler
At 08:23 AM 12/21/2003 -0800, Carl Ellison wrote:
That's an interesting definition, but you're describing a constraint on the
behavior of a human being.  This has nothing to do with cryptosystem choice
or network protocol design.  What mechanisms do you suggest for enforcing
even the constraint you cite?  Of course, that constraint isn't enough.  In
order to achieve non-repudiation, the way it is defined, you need to prove
to a third party (the judge) that a particular human being knowingly caused
a digital signature to be made.  A signature can be made without the
conscious action of the person to whom that key has been assigned in a
number of ways, none of which includes negligence by that person.
total aside ... i just did jury duty in criminal case last week

a mammal taxonomy can have
* humans
* horses
* mice
which doesn't mean that all mammal's have hooves, and correspondingly, all 
security doesn't have to have non-repudiation.

if the authorizations and/or permissions require for somebody to be an 
employee ... it is possible to authenticate somebody as being an employee 
w/o having to authenticate who they are ... just sufficient to authenticate 
them as whether or not they are allowed to do what they are allowed to do.

now, if you have 10,000 people that are authorized to do something ... and 
you have no tracking about what any specific person does  then if some 
fraud takes place  you may have no grounds whether to suspect any of 
the 10,000 over any of the others.  However, if you have a policy that 
employees are strictly not suppose to share passwords and can get fired if 
they do  and some fraud process takes placed ... done by an entity 
entering a specific password  there would possibly be at least 
sufficient grounds to at least get a search warrant. The password by itself 
might not be sufficient to convict beyond a reasonable doubt ... but the 
audit trail might at least help point the investigation in the correct 
direction and also be admitted as circumstantial evidence. The defense 
attorneys in their opening statements said something about the prosecution 
showing means, motive, opportunity and misc. other things.

in any case, I would claim that both human and non-repudiation issues are 
part of security.

I wouldn't go so far as to say that just because a certification authority 
turned on a non-repudiation bit in a certificate  and had no means at 
all of influencing human behavior, that just because the bit was turned on 
... it, in anyway had anything to do with non-repducation.

there is recent thread in pkx mailing list about the name of the 
non-repudiation bit in a certificate being depreciated. There seems to be 
two separate issues ... 1) calling the bit non-repudiation isn't 
consistent with the meaning of the bit and 2) the semantics of what the bit 
supposedly controls.
--
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]


Non-repudiation (was RE: The PAIN mnemonic)

2003-12-22 Thread Carl Ellison
 -Original Message-
 From: Anne  Lynn Wheeler [mailto:[EMAIL PROTECTED] 
 Sent: Sunday, December 21, 2003 6:42 AM
 To: Carl Ellison
 Cc: 'Anne  Lynn Wheeler'; [EMAIL PROTECTED]
 Subject: Re: The PAIN mnemonic
 
 At 11:20 PM 12/20/2003 -0800, Carl Ellison wrote:

 and it included non-repudiation which is an unachievable, 
 nonsense concept.

 one could look at one aspect of non-repudiation as the 
 requirement for 
 everybody having a unique pin/password with guidelines never to share 
 pin/passwords ... which could be considered across a broad range of 
 security activities. 

That's an interesting definition, but you're describing a constraint on the
behavior of a human being.  This has nothing to do with cryptosystem choice
or network protocol design.  What mechanisms do you suggest for enforcing
even the constraint you cite?  Of course, that constraint isn't enough.  In
order to achieve non-repudiation, the way it is defined, you need to prove
to a third party (the judge) that a particular human being knowingly caused
a digital signature to be made.  A signature can be made without the
conscious action of the person to whom that key has been assigned in a
number of ways, none of which includes negligence by that person.

Let's just leave the term non-repudiation to be used by people who don't
understand security, but rather mouth things they've read in books that
others claim are authoritative.  There are lots of those books listing
non-repudiation as a feature of public key cryptography, for example, and
many listing it as an essential security characteristic.  All of that is
wrong, of course, but it's a test for the reader to see through it.

 - Carl

+--+
|Carl M. Ellison [EMAIL PROTECTED]  http://theworld.com/~cme |
|PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71   |
+---Officer, arrest that man. He's whistling a copyrighted song.---+ 

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


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

2003-12-22 Thread Anne Lynn Wheeler
At 08:23 AM 12/21/2003 -0800, Carl Ellison wrote:
That's an interesting definition, but you're describing a constraint on the
behavior of a human being.  This has nothing to do with cryptosystem choice
or network protocol design.  What mechanisms do you suggest for enforcing
even the constraint you cite?  Of course, that constraint isn't enough.  In
order to achieve non-repudiation, the way it is defined, you need to prove
to a third party (the judge) that a particular human being knowingly caused
a digital signature to be made.  A signature can be made without the
conscious action of the person to whom that key has been assigned in a
number of ways, none of which includes negligence by that person.
Let's just leave the term non-repudiation to be used by people who don't
understand security, but rather mouth things they've read in books that
others claim are authoritative.  There are lots of those books listing
non-repudiation as a feature of public key cryptography, for example, and
many listing it as an essential security characteristic.  All of that is
wrong, of course, but it's a test for the reader to see through it.
I mentioned PAIN as a (in-use) security taxonomy ... not a cryptosystem 
taxonomy  or network protocol taxonomy ... and there is nothing precluding 
human factors in a security paradigm (like human factors issues of 
requiring unique shared-secret for every security domain leading to humans 
having to fumble around with scores of shared-secrets).

i agreee that non-repudiation has been seriously mis-used especially with 
regard to crypto systems.  I've even made the assertion that possibly some 
of it can be contributed to having the word signature occur in both the 
term digital signature and legal signature  even tho the two may 
have nothing at all to do with each other.

note, however, when I did reference PAIN as (one possible) security 
taxonomy  i tended to skip over the term non-repudiation and primarily 
made references to privacy, authentication, and integrity.

sample of some past posts in various venues on the subject.
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI not working
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards 
(slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation 
practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation 
practicalities