Subject: RE: Meaning of Non-repudiation

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 2 May 2002 14:09:59 -0700

Hi Santosh,
That still sounds like a policy decision. 
A signature over an SSL challenge is potentially just as valid a piece
of a NR jigsaw puzzle as any other signature. Why are we dictating what
someone wants as a NR process? If you want to build a system where NR
signatures only occur over documents - fine by me, but don't dictate how
I build my NR system.
Trevor

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

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

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: Aram Perez <[email-masked]>
Date: Thu, 2 May 2002 15:30:41 -0700

Hi Trevor,

I too am breaking my vow of silence on the NR bit. You are absolutely 
correct. I/you should be able to design a NR System where 
"non-reputable" transactions take place using SSL.

Regards,
Aram Perez

---

From: "Omer Hasret" <[email-masked]>
Date: Fri, 3 May 2002 10:52:58 +0200

Trevor, Santosh,

It is certain that everybody will need some means of proving that he is
the originator of a specific message, document, whatever. And when we
talk about the NR bit on a certificate, I believe the only thing this
proves is that a specific data is signed by the holder of this
certificate. This never means that the signer agrees with the content or
not. Therefore there is no need to load other meanings to this one bit
changing from policy to policy. Just standardize its use only for
authentication and let others who want to implement their own NR systems
do it by other means. (Some ways to do this have been posted on the list
a day or two days ago.) And I really do not think this as a "dictation"
because you don't have to use that bit just because its name is NR.

> A signature over an SSL challenge is potentially just as 
> valid a piece of a NR jigsaw puzzle as any other signature. 
> Why are we dictating what someone wants as a NR process? If 
> you want to build a system where NR signatures only occur 
> over documents - fine by me, but don't dictate how I build my 
> NR system. 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.
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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 
> 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
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 May 2002 09:19:54 -0400

Trevor:

I am a bit late in posting and I know a lot of other folks have seconded
your view.  I look at the whole matter little differently.  My reasoning
is as follows:

The standard does not mandate using separate keys for encryption and
signature, but offers the implementations that opportunity by having two
bits.  Thus, one implementation can set both bits for dual usage, while
another implementation can use two keys.

Same way, we should keep two bits: one for data originated by signer to
which the signer takes some ownership and another one for signing random
challenges in authentication protocols.

This approach accommodates both implementations: 1. use of a single key
to sign anything and everything and 2. use to separate key for digital
signature and another for authentication.

As aside, I for one have never mentioned non-repudiation in this.  I do
think having separate keys is step towards eliminating some of the
non-repudiation related concerns, how so ever small.

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

Hi Santosh,
I build my NR system. Trevor

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

Trevor:

-----Original Message-----

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,

Very unlikely to happen.

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

Fine.

Denis

been debated
debate.
were raised

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 03 May 2002 10:02:56 -0400

> signatures only occur over documents - fine by me, but don't dictate how

Trevor,

I agree completely.

That is why if:
  key usage bit 0 = digital signature on a "nonce" (*)
        and bit 1 = digital signature on other data

then the name of bit 1 should be changed to something
other than nonRepudiation.  As you say, even a signed
challenge could play a role in some NR systems.

Nonetheless, there is a benefit to having separate key
usage bits for four different categories of data to
be signed: certificates, CRLs, nonces, and
everything else.

The word "non-repudiation" is an obstacle to achieving
that benefit.  Therefore the word must be removed from
the definition of Key Usage, and instead be discussed
in the context of Extended Key Usage, certificate
policies, and best of all, the methods described by
Denis Pinkas: document contents and signed attributes.

Dave

(*) A nonce is data explicitly designed to be
non-replayable in its primary application (e.g. SSL).
The protocol would not serve its primary purpose if
the signed nonce could be replayed, even if there is
a secondary forensic or NR reason for verifying the
signed nonce at a later time.