Subject: Re: proposed key usage text

From: "Aram Perez" <[email-masked]>
Date: Fri, 19 Nov 1999 08:21:41 -0800

Hi Russ,

> Hi Aram.
> 
>  >>       The digitalSignature bit is asserted when the subject public key
>  >>       is used with a digital signature mechanism to support security
>  >>       services other than non-repudiation (bit 1), certificate signing
>  >>       (bit 5), or revocation information signing (bit 6). Digital  signa-
>  >>       ture mechanisms are often used for entity authentication and data
>  >>       origin authentication with integrity.
>  >>
>  >>       The nonRepudiation bit is asserted when the subject public key is
>  >>       used to verify digital signatures used to provide a non-
>  >>       repudiation service which protects against the signing entity
>  >>       falsely denying some action, excluding certificate or CRL  signing.
>  >>       In the case of later conflict, a reliable third party may deter-
>  >>       mine the authenticity of the signed data.
>  >>
>  >>       Further distinctions between the digitalSignature and nonRepudia-
>  >>       tion bits may be provided in specific certificate policies.
>  >
>  > What is happens when both the digitalSignature and nonRepudiation bits are
>  > set? Does one of them take precendence?
>
> I guess that you missed our point altogether.  There is no precedence.  If
> both the digitalSignature and nonRepudiation bits are set, then the public
> key may be used with a digital signature mechanism to support
> authentication and integrity and it may also be used to verify digital
> signatures used to provide non-repudiation.  One public can might be used
> for both purposes.

But how do you distinguish between what use was intended? If someone
captures a message that I signed for "authentication and integrity" and
another message that I signed for "non-repudiation", how does a third party
distinguish which use was intended?

I have seen many authentication protocols that require the party being
authenticated to sign a challenge (that is supposed to be a random number or
a nonce). Now suppose that I'm trying to get access to a system that instead
of sending me a random challenge, sends me the following message: "I agree
to sell 1000 shares of Apple at $10.00 per share." My software will blindly
sign the message and send my certificate which has the DS and NR bits set.
Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
third party that I was only trying to do authentication and not
non-repudiation?

Regards,
Aram Perez

---

From: Al Arsenault <[email-masked]>
Date: Fri, 19 Nov 1999 17:22:31 -0500

> third party that I was only trying to do authentication and not

AWA:  Aram, that's what the rest of the non-repudiation system is for. 
Your key has been shown to have been used to sign a message.  You do not
want to take the action indicated in the signed message.  Among other
things, the following questions have to be answered:

	1 - was it really you that caused the signature to occur?  Was your key
compromised, or your workstation used by one of your co-workers without
your knowledge/permission?  What evidence exists that it really was or
was not you?

	2 - did you know what you were signing?  Should you have known?  What
evidence is there that you took a conscious effort to understand and
verify before signing?

	3 - was the key used appropriate for the message signed?

The value of the NR bit only enters into #3 here.  And I suspect you
will find a lawyer willing to argue for you and against you regardless
of the value of that bit.

A non-repudiation system consists of a lot more than just one bit in a
certificate.

			Al Arsenault

-- insert standard disclaimer about this not reflecting my employer's
policies here.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Nov 1999 10:47:16 +0100

At 08:21 AM 11/19/99 -0800, Aram Perez wrote:
<snip>
>distinguish which use was intended?

This is the problem in a nut shell.

If you sign a message - then it must be for the purpose of providing
non-repudiation, because if you sign a message, you can count on the fact
that someone may try to hold you responsible for it (in some way)
regardless of what any bits in a certificate was saying.

So to me there is no such thing as signing messages just for authentication
purpose but NOT for non-repudiation. Not in real life. 

Can anyone show me a REAL implementation where a messages are signed, where
this is strictly NOT non-repudiation.

I would make the technical distinction that in case of authentication only,
this means a service where the signer signs data as part of an
authentication protocol, where good practice says that the signer should
include some self-generated nonce.

I can live with the text as proposed. But a clarification of this technical
distinction would be very useful.

/Stefan

   \\|||//   Stefan Santesson
    (@ @)    Accurata Systemsäkerhet AB
_ooO_(_)_Ooo____________________________________
|__|___|____|_____|_____|_____|_____|_____|_____| 
|___|____|____|_____|_____|_____|_____|_____|___|
|  Tel. +46-40 108588 , Mobile +46-705 247799   |
|  [email-masked] , http://www.accurata.se  |
-------------------------------------------------

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Nov 1999 02:10:47 -0800

> this is strictly NOT non-repudiation.

The Shared Registry Protocol for DNS names used by registrars for COM/NET/ORG
has a provision for signing email messages ... just to make forging email messages
more difficult.  But, there is no assurance value associated with the signature  -- and
this is a very common use of email signatures even exemplified in this discussion
group (see archives).

And, this is also so defined in X.509 -- where authentication and non-repudiation
are considered different services.

So, making non-repudiation a blob together with authentication will not be useful,
since it does not occur --  neither in pratice nor in theory.  And, IMO, it will not
allow non-repudiation to be somehow "better defined", as by clumping it with
authentication. In fact, we would lose resolution of a difference that we ought to
highlight.

Cheers,

Ed Gerck

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Nov 1999 12:44:53 +0100

Ed,

I must admit that I was thinking about situations where a physical person
sign information.
I guess when the signer is a service, there will always be a context
deciding the assurance value of the signature, which should be obvious for
the user of the service.

But I still think that there is a common understanding of the differences
between non-repudiation and authentication and the way the NR-bit is
distinguished from the DS-bit in implementations out there. And I think
that understanding is rather close to what I was trying to say.

But of course your example destroys my simplified definition :-(

/Stefan

>authentication. In fact, we would lose resolution of a difference that we 

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Nov 1999 11:31:24 -0500

>this is strictly NOT non-repudiation.

Yes.  X.509 was originally written for X.500 Directory Strong 
Authentication.  This is a case where authentication, not non-repudiation, 
is implemented.

Russ

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Nov 1999 10:50:20 -0800

> But of course your example destroys my simplified definition :-(

When we use public discussions as a mechanism to mine the gold of truth,
verifying that some gold pieces are actually faux gold is beneficial to all
and IMO does not "destroy" but builds a better understanding.

And, in this case, David Kemp also added an argument (in a different thread)
which adds a perhaps even stronger reason than the one I stated in my
message, of why we need to keep DS vs NR functionality distinct:

 If you care about separating challenge signatures from signed messages,
  you will use different keys, with DS set for one and NR set for the other.

where not the assurance value associated with the signature is the needed
difference between authentication and NR but the integrity and origin values
of the signature that is used -- without any need for non-repudiation
whatsoever.

These reasons motivate the importance of this discussion (even if it needs to
be repeated from time to time, or may flare up from nowhere), because otherwise
we would lose resolution of important differences (plural) that we ought to
highlight and make clear -- not shove under the carpet.

In regard to Aram's question of why the two bits DS and NR should be allowed
to coexist or, if they coexist, what is the precedence order between them, there
are several possible answers of course.  The one that IMO would solve all problems
and create none uses the fact (already given in 2459) that all bits are independent for the
purpose of compliance testing -- while any application is free to provide its own
restrictions and/or requirements.  The combination of (DS=1,NR=1) can then
be used to signal the highest validity assurance possible in the system, in a graded
scale as I suggested before (see archives) of all *four* possible cases  for the two
bits of (DS,NR) and for which there is no bit precedence at all since all two-bit values
are assigned to different security functions.

The encoding of four validity values in two bits can be entirely optional (since all
bits are independent for the compliance testing) and yet afford a convenient grading
for *all* types of non-repudiation that have been discussed here -- as depicted in
the table already given (see archives).

In other words, the solution to this debate does not have to be either/or but can
actually profit from the diversity of views expressed here in order to provide a
comprehensive system that is able to interoperate in a large variety of circumstances,
including cross-interoperation (since the suggested validity scale for the two-bit
combination is ordered).

Cheers,

Ed Gerck