Subject: RE: Meaning of Non-repudiation

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 2 May 2002 11:52:50 -0700

I am breaking one of my New Year resolutions by mailing on this topic,
but here goes...

Signing anything is always a challenge to prove position of a private
key to authenticate whether it's in the context of a protocol like SSL
or over a SMIME message. Technically all we can say is the signature
occurred. The intent behind why the signature occurred is beyond the
scope of this discussion. Use of certificates with the NR bit asserted
is ultimately a matter of local policy on what constitutes usage as part
of a non-repudiation service since two organisations could have two
separate non repudiation serves where one requires a NR signature as
part of an SSL session, and the other only wants NR signatures over
SMIME messages.

Never in the course of IETF has history so much been written over
something so small.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, May 02, 2002 2:27 AM
To: David P. Kemp
Cc: [email-masked]
Subject: Re: Meaning of Non-repudiation

Dave,
 
> Russ,
> 
> I believe we are all sorry to resurrect this topic.
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509
defect
that has been officially raised.

> and if the text of X.509 eventually changes in a way
> that is incompatible with Son-of-2459, then
> Grandson-of-2459 will need to take that into
> consideration.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be
provided
and we are (nearly) all saying the same thing using different words.
Santosh
in a subsequent e-mail provided one of these explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used
to
authenticate data (this does not mean that the signer has read the
data).

Now, there are cases where, beyond the fact that the signer did know
what he
signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says
that
the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to
the
document and indicates a signature policy that is explicit about the
meaning
of all signatures performed under that policy (note that one single
meaning
is possible in that case).

3) another signed attribute (using the CMS language) is signed in
addition
to the document and the previous attribute. It indicates the type of
commitment being made under the signature policy for that signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate
Policy
from the CA.

> We can all live with the text because we have no consensus on 
> anything better.  

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a
> meaningful replacement in the future.
> 
> Dave
> 
> "Housley, Russ" wrote:
> >
> > Dave:
> >
> > I am sorry that I replied to this thread at all.  This topic has
been debated
> > before, and the text in Son-of-RFC 2459 is the result of that
debate.
> > Obviously, everyone can live with that text because no objections
were raised
> > during WG Last Call or IETF Last Call.
> >
> > I am not surprised that there is not 100% agreement....
> >
> > Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 May 2002 17:02:51 -0400

Trevor:

I also made a resolution long time back when ABA started a debate on
this.  But, I also broke it.

I do think that there is a value in SSL case to say that I am not owning
up to signature (as attesting to something) except I signed a challenge.
Thus, subscriber (possessor of the private key) should be able to use a
separate key so that he can claim he simply signed a random challenge.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Thursday, May 02, 2002 2:53 PM
To: Denis Pinkas; David P. Kemp
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, May 02, 2002 2:27 AM
To: David P. Kemp
Cc: [email-masked]
Subject: Re: Meaning of Non-repudiation

Dave,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509
defect that has been officially raised.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be
provided and we are (nearly) all saying the same thing using different
words. Santosh in a subsequent e-mail provided one of these
explanations:

I would add that a certificate with the the DS bit set can also be used
to authenticate data (this does not mean that the signer has read the
data).

Now, there are cases where, beyond the fact that the signer did know
what he signed, he wants to say exactly what its signature means.

1) the document that is signed is unambiguous and its semantics says
that the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to
the document and indicates a signature policy that is explicit about the
meaning of all signatures performed under that policy (note that one
single meaning is possible in that case).

3) another signed attribute (using the CMS language) is signed in
addition to the document and the previous attribute. It indicates the
type of commitment being made under the signature policy for that
signature 
(note that multiple meanings are possible in that case).

Policy from the CA.

Fine.

Denis

been debated
debate.
were raised