Subject: RE: Meaning of Non-repudiation

From: Peter Williams <[email-masked]>
Date: Wed, 01 May 2002 15:04:24 -0700

> Son-of-2459 says:
> 
>        Further distinctions between the digitalSignature and
>        nonRepudiation bits may be provided in specific certificate
>        policies.
> 
> This allows the CA to state what additional meaning is associated with the
> nonRepudiation bit.
> 
> Russ

OF course, when the RP - via its DPV & DPD agents - does path processing
and discovery (using CP parms selected by the RP in each case), it gets to
select/handle 
of behalf of the RP which of David's CA's 3 DoD CPs actually control the
additional 
application-oriented semantics that are controlling the subscription-weight 
(legal meaning) of David's signature(s). An issuer can control ambiguity
and RP choice by careful administration of the CPs cited in CA certs.
 
I dont see that David and Russ have any real differences of needs. Perhaps
the
only issue is that David would like his NR and DS semantics to be
uniformly imposed on all PKIX/X.509 CPs. The IETF standard requires the
imposition
of such control policies via CP definition. I think the latter is far more
flexible; and uses
CP-parameterized path processing in the manner ISO intended.
 
[1]Certificate Policy: PolicyIdentifier=2.16.840.1.101.2.1.11.5

[2]Certificate Policy: PolicyIdentifier=2.16.840.1.101.2.1.11.9

[3]Certificate Policy: olicyIdentifier=2.16.840.1.101.2.1.11.10

---

From: [email-masked]
Date: Thu, 2 May 2002 14:53:32 -0600

the NR bit in a certificate seems to be almost totally unrelated to whether
a person really intended for a signature to occur. within the chipcard
domain (on the way to showing non-repudiation need to first establish
intention &/or approval) ... there has been two different kinds of ... lets
say personalities;

1) access card personality .... the card powers on, a PIN is entered, and
the card signs an unlimited number of messages ... as an authentication
indication; from 3-factor authentication: two factors, a) something you
have and b) something you know.

2) financial card personality ... the card requires that a PIN be entered
for every signature; this has an implicit "intention" or "approval" in
addition to authentication; the card has the aspect of an access card
personality (two factor authentication) as well as the additional implicit
aspect of "intention" or  "approval" because a human interaction is
required for every signature ... aka the re-entry of the PIN for every
signature implying intention. The finread reader standard goes further ...
in that there needs to be a "secure" card acceptor device with secure
display & secure pin-entry (further increasing the probability that the
specific human was involved in the re-entry of the PIN ... and it was done
specifically in conjunction with a specific transaction being displayed).

Having a "NR" flag in a certificate seems to have little or no bearing on
whether there is an implicit intention of a person that a specific
signature be performed (in the sense of a chipcard with a "financial"
personality that carries with it some action implying approval or
intention).

misc. past "intention" post (aka before getting to non-repudiation ... need
to first establish something like intention &/or approval before there is a
basis for repudiation or non-repudiation).
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital
Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?

misc. past finread posts:
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet,
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet
Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet
Banking

trevor freeman <[email-masked]> on 5/2/2002 12:52 pm wrote:

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

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 02 May 2002 14:52:54 -0800

At 02:09 PM 5/2/02 -0700, Trevor Freeman wrote:

>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 think that sums up the situation very well (fortunately or not ;)

____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 03 May 2002 10:36:27 +0200

Well put Trevor,

I fully agree with this observation.

/Stefan

At 14:09 2002-05-02 -0700, Trevor Freeman wrote:

>Hi Santosh,
>That still sounds like a policy decision.
>-----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
>
>
>
>-----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: "Sabett, Randy" <[email-masked]>
Date: Fri, 3 May 2002 11:38:32 -0400

All:

I agree with Santosh from a legal perspective as long as the statement that
"we should offer implementations flexibility of having two bits" means that
it will be up to each specific application as to specifically how the bits
will be interpreted, including how the NR bit (or whatever it ends up being
called) is to be used for that application.  I don't believe that we would
ever be able to get every business sector to come to agreement as to exactly
what NR=1 means.  As Russ pointed out, how a particular application uses the
bit can be refined in the CP.

The points made by a number of different people make it clear to me that
most of us are in violent agreement, though we may come at the argument from
different angles.  From a legal perspective, we are dealing with what I view
as a continuous repudiation/nonrepudiation spectrum that cannot be
shoehorned into just two bits.  While, as Tony pointed out, the customer may
want NR=1 to mean "you shall be unable to repudiate", from a legal
perspective you can ALWAYS repudiate.  Then, it becomes a judgment call by a
judge or jury as to whether you really can or cannot repudiate, based on the
particular facts of the case (of which NR=1 may be just one piece of the
evidence).

Steve, in an email from a week ago, elegantly restated the conclusion
reached at the joint ABA ISC and IETF meeting in Washington from a couple of
years ago, where the DS and NR bits were discussed.  The conclusion reached
was that the assertion of the NR bit was necessary but not sufficient for
showing that a party would be bound by a digital signature.  This means that
other dynamics that CANNOT be captured in bits must be considered (since it
would be difficult to implement a repudiation bit that, e.g., could be used
to indicate someone being forced to sign did so because that person had a
gun pointed to his or her head).

Regards,

R.

	_______________________________
	Randy V. Sabett, J.D., CISSP
	Cooley Godward LLP
	One Freedom Square, Reston Town Center
	11951 Freedom Drive
	Reston, VA  20190-5656
	Direct:		703.456.8137
	Main:		703.456.8000
	Cell:		703.597.6521
	Fax:		703.456.8100
	E-Mail:	[email-masked]
	http://www.cooley.com
	
http://www.cooley.com/practice_and_people.ixe?section=Attorney+Biographies&i
d=SABETTRV
	Broomfield * Kirkland * Menlo Park * Palo Alto * Reston * San Diego
* San Francisco

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Friday, May 03, 2002 8:56 AM
To: 'Tony Bartoletti'; 'Omer Hasret'
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Folks:

I am a bit confused.  I have NOT said that NR = 1 means non-repudiation.
All I have said is that we have two bits.  They may be a bit of
misnomer.  We should use one bit for signing challenges for
authentication and another one for signing data for the purposes of
"source authentication" and "data integrity"

What we call them is up to us.  Thus, we should offer implementations
flexibility of having two bits.

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]] 
Sent: Thursday, May 02, 2002 9:06 PM
To: Omer Hasret; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

At 10:46 AM 5/2/02 +0200, Omer Hasret wrote:

>Even if it is like Santosh says for the signing and the relying party, 
>my opinion is that it is not enough. I also think that the meaning of 
>these concepts should be the same for all parties including the 
>software developer.

I agree.  And if we allow this bit to represent something "sufficiently 
mechanical" (ala Tom Ginden's "Technical Nonrepudiation") we might
someday 
arrive at a "concept" that all can come close to recognizing.

Unfortunately, the customer expects NR=1 to mean, "If you signed
something 
with this key, you shall be unable to repudiate ... something" (that you

signed, and signed willfully, and signed knowingly, etc.)  This is just
too 
foggy for all of the interested parties to come to an agreement, except 
over certain specific types of situations (which would make the NR-bit 
useful to certain communities and not so much to others).

Indeed, in some contexts, NR "trumps the facts".  That is, the holder of
an 
NR-signed item can act "as if" you signed it, even if it can be
otherwise 
proven that you actually did not.  In this context, you have entered
into 
an agreement that "you will abide by the outcome, irrespective of intent
or 
even of involvement."  This is (loosely) analogous to the $50 you agree
to 
forfeit if your credit card is abused, irrespective of who actually used

it, how it was subverted, etc.

Cheers!

___tony___

=======================================================
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message

---

From: [email-masked]
Date: Fri, 3 May 2002 17:32:32 +0200

You can configure bullsh*t in many ways without disobeying technical specs
:-). A configuration like the one you cited, although technically possible,
is rather unlikely to happen in practice. Either you want deny the use of
the key for a certain operation or not. (by the way, all specs I am aware
of specify the combinations DS=1, NR=0 and DS=1, NR=1 as meaningful, NR=1
with DS=0 is specified as "does not make sense" - I actually do not like
this, but I am used to live with it). However, with the situation as
described by you, an authenticator will happily use the first certificate,
and a signature verifier the second, and hopefully the private key of the
user/signer is able to perform all corresponding operations.
|------------------------+------------------------+------------------------|
|                        |   Aram Perez           |                        |
|                        |   <[email-masked]>   |           To:          |
|                        |   Sent by:             |   PKIX                 |
|                        |   owner-ietf-pkix@mail.|   <[email-masked]>  |
|                        |   imc.org              |           cc:          |
|                        |                        |           Subject:     |
|                        |   03.05.2002 15:42     |   Re: Meaning of       |
|                        |                        |   Non-repudiation      |
|------------------------+------------------------+------------------------|

Hi Olaf,

The trouble is that the bits are applied to the certificate and not to
the public key or the private key. Thus, I can have two certificates,
one with DS=1, NR=0, and another with DS=0, NR=1, for the same key pair.

Regards,
Aram Perez

On Friday, May 3, 2002, at 03:43  AM, [email-masked] wrote:

> The NR bit in a certifiicate does not proof anything. It is a statement
> made by the signer and/or the CA about the intended use of the key.
> KeyUsage bits are currently used to support key pair separation for the
> three basic use cases of public key cryptography: encryption,
> authentication and digital signing. Most application choose public key
> certificates needed for a certain type of operation based on the
> keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature
> to
> verify the response to a challenge for authentication, or to verify
> signature made on e-mail. These two bits are essential (and sufficient)
> to
> support key pair seperation per RSA operation capability (decryption or
> signing) of the private key as the RSA operation capabilities of private
> keys may be restricted by hardware implementation (i.e. a crypto
> processor
> card may be configured to allow only signing with a private key, or
> decryption, and check padding and format of input/output before and
> after
> the operation or even include part or all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, but
> not to sign an arbitrary challenge, (which practically means "can be
> used
> within S/MIME but not within SSL")  which is the case e.g. within the
> signature law compliant use cases, a new bit is needed to clearly
> distinguish between public keys used for authentication and for
> signature
> verification. In all specs that adress this seperation the
> nonRepudiation
> bit is used for that purpose. And I cannot see a need for changing
> that..
>
|------------------------+------------------------+------------------------|
> |                        |   "Omer
> Hasret"        |                        |
> |                        |   <[email-masked]>  |
> To:          |
> |                        |   Sent by:             |   "'Trevor
> Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[email-masked]|
> |                        |   imc.org              |   osoft.com>,
> "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[email-masked]|
> |                        |                        |
> m>                   |
> |                        |                        |
> cc:          |
> |                        |                        |   <ietf-
> [email-masked]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE: Meaning
> of       |
> |                        |                        |
> Non-repudiation      |
>
|------------------------+------------------------+------------------------|
> [snip]

---

From: [email-masked]
Date: Fri, 3 May 2002 11:48:41 -0600

in the X9A10 working group (for financial payment standards) provisions
were made for a token acceptor device to also be able to sign a
transaction. the operational characteristic  of the token acceptor device
(like finread standard) would be registered (RA; with or w/o a certificate
necessary) which would indicate whether it operated in such a manner as to
require a human interaction implying intention.

a simple hardware token digital signature by itself wasn't sufficient for
implying intention (a necessary pre-requisite before even talking about NR)
... but the process around the execution of the token digital signature was
also necessary for  implying intention. A finread complient reader provides
basis for inferring intention ... but then you still need proof that such a
reader was used for the specific transaction (either because of some
physical boundary, like ATM machines on private networks  ... or because
the token acceptance device is certified and also signs the transaction).

whether or not the digital signing environment was operated according to
acceptable mechanism for implying intention ... is pretty much independent
of whether there is a NR bit flag in a certificate. The additional
signature by a complient/registered token acceptor device attests to the
fact that specific operations were actually observed in conjunction with
the specific signing operation that might then be used to imply intention
on part of a person (as a necessary prerequisite for any attempt at
establishing non-repudiation).

Nominally a person would have to make some indication as to their intention
... that could be done up front to a device ... which would then know to
also only select a public key that had a certificate with a NR bit set.
Note however, it isn't whether a certificate with a NR flag that is
important ... it is important that the process of performing the digital
signature followed precedures necessary for infering intention (and some
registered device can attest to the intention infering process was
followed).

__________________

previous ref:

http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of non-repudiation

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 3 May 2002 12:20:18 -0700

Hi Olaf,
You are making the same leap as Santosh. Just because you don't want to use SSL as part of your NR system, does not preclude others from doing so. That is a policy decision, not a technology issue. Let me put it another way - setting the NR bit does not by itself assert that this certificate cannot be used for SSL client authentication. You may have a policy to that effect, and that policy may be called out in the certificate policy, bit the NR bit alone is not good enough to define the policy in the way you describe.
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 03, 2002 3:43 AM
To: [email-masked]
Cc: 'Santosh Chokhani'; [email-masked]; [email-masked]; Trevor Freeman
Subject: RE: Meaning of Non-repudiation

The NR bit in a certifiicate does not proof anything. It is a statement
made by the signer and/or the CA about the intended use of the key.
KeyUsage bits are currently used to support key pair separation for the
three basic use cases of public key cryptography: encryption,
authentication and digital signing. Most application choose public key
certificates needed for a certain type of operation based on the keyUsage
bits: with keyEncipherment to encrypt a message, with digitalSignature to
verify the response to a challenge for authentication, or to verify
signature made on e-mail. These two bits are essential (and sufficient) to
support key pair seperation per RSA operation capability (decryption or
signing) of the private key as the RSA operation capabilities of private
keys may be restricted by hardware implementation (i.e. a crypto processor
card may be configured to allow only signing with a private key, or
decryption, and check padding and format of input/output before and after
the operation or even include part or all of the hashing procedure).

If one wants to ensure that a private key is only used to sign data, but
not to sign an arbitrary challenge, (which practically means "can be used
within S/MIME but not within SSL")  which is the case e.g. within the
signature law compliant use cases, a new bit is needed to clearly
distinguish between public keys used for authentication and for signature
verification. In all specs that adress this seperation the nonRepudiation
bit is used for that purpose. And I cannot see a need for changing that..
|------------------------+------------------------+------------------------|
|                        |   "Omer Hasret"        |                        |
|                        |   <[email-masked]>  |           To:          |
|                        |   Sent by:             |   "'Trevor Freeman'"   |
|                        |   owner-ietf-pkix@mail.|   <[email-masked]|
|                        |   imc.org              |   osoft.com>, "'Santosh|
|                        |                        |   Chokhani'"           |
|                        |   03.05.2002 10:52     |   <[email-masked]|
|                        |                        |   m>                   |
|                        |                        |           cc:          |
|                        |                        |   <[email-masked]>  |
|                        |                        |           Subject:     |
|                        |                        |   RE: Meaning of       |
|                        |                        |   Non-repudiation      |
|------------------------+------------------------+------------------------|

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: "Trevor Freeman" <[email-masked]>
Date: Fri, 3 May 2002 13:06:27 -0700

Hi Dave,
You CANNOT change the semantics of existing bits. That kind of behaviour
breaks things, leads to even more ambiguity etc, etc. You can add new
bits with more precise meaning - though in the case of the KU extension
- that to breaks things so that is a less than optimal route as well.
Trevor

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]] 
Sent: Friday, May 03, 2002 7:03 AM
To: [email-masked]
Subject: Re: Meaning of Non-repudiation

> 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.

---

From: [email-masked]
Date: Sat, 4 May 2002 10:00:06 -0600

i still think the semantics are confusing .... rather than random
challenges ... lets say authentication vis-a-vis
approval/agreement/intention ... is much more sensible semantics from
business and/or process orientation.

an authentication could be a radius implementation sending

time-value LOGIN:

the respondent creates a PPP radius response that includes the time-value,
the entities userid and a FIPS-186 digital signature. FIPS186 digital
signature contains a random component by definition. simple authentication,
no sense of approval/agreement/intention.

 this is as opposed to something like a financial transaction or other
physical signature analog that carries with it the sense of human
approval/agreement/intention. non-repudiation is something of a legal issue
that may use something about human approval or intention as part of proving
something, An electronic device that perform digital signatures
automagically doesn't carry with it the same implicit connotation that a
physical signature does ... which requires an explicit human interaction.
The human interaction of executing a physical signature carries with it
some concept that the person, in fact intended to write the signature that
they were writing. An automagic electronic device creating digital
signatures doesn't carry with it the same connotation that the person was
explicitly involved in the execution of that specific digital signature.

From a process standpoint involving automagic electronic digital signing
devices ... there is no difference between the signing of random bits and
the signing of data. There may be a business reason to distinquish between
signature operations on challenge information vis-a-vis signature
operations on non-random data. However, in that case, the signer should get
to contribute a field to the signed message indicating what it believes it
is signing. Since an appended certificate isn't part of the signed message
... it wouldn't directly establish what the person believed (if they even
knew) that they were signing.

Trying to load a static certificate with semantic meaning as to what a
person believed to be signing ...  for each signing operation ... leads
down this garden path that there needs to be a unique certificate for each
possible signing business case ... and since a static appended certificate
can't directly indicate what a person believe they were signing ...  then
there would also have to be a unique public/private key pair for each
possible certificate for each possible business case. Given that you can
proove that a person has only registered a public key for one and only one
type of business process, and there exists one and only unique certificate
for that public key ... specificying one and only one unique signing
business process ... then you may be able to infer that the use of a
corresponding private key with the corresponding appended certificate
indicates what type of data  the person believed they were signing.

Moving the type of (business/process) data indication (that the person
believed they were signing) out of the certificate and into the content of
the signed message  .... eliminates having to infer it from a static
appended certificate (along with the corresponding requirement of being
able to proove that a specific public/private key pair has only been
registered for a certificate with a unique business type indication).
Having a public/private key registered with multiple different certificate
business types .... or the same certificate indicating multiple possible
business uses (types of data being signed) .... creates ambiquity as to
what type of data the person believed it was signing (i.e. no longer able
to infer unique type of data the person believed it was signing based on
the business use indications in the certificates(s)).

The issue of type of data the person believed it was signing (by inferring
it from their choice of a unique signing key that  is uniquely associated
with each specific type of business data) is orthogonal to the business
process issue that may require some physical act on part of a person in
conjunction with a signing operation which can be used to infer
approval/agreement/intention for the execution of that specific digital
signature.

santosh chokhani <[email-masked]> on 5/4/2002 7:15 am wrote:

Let us call NR bit bit A and DS bit bit B.

You are welcome to show how you interpret the bits.  What I am proposing
is as follows:

A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.

A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.

A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.

A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.

I suspect of these, case "c" may be the most controversial, if any.  How
many implementations use case c and use the public key to verify the
signature on data?

---

From: [email-masked]
Date: Mon, 6 May 2002 11:59:19 -0600

a "problem" is that certificates are suppose to be something that a relying
party ... can rely on ... because relying parties supposedly can't directly
trust the signer/sender.

if you are going to be able to always trust the signer/sender in all things
... then why do you need certificates ... which certify information by
independent parties ... just trust the signer/sender and completely do away
with certificates.

says that the relying party can't trust the signer ... but can trust the CA
... except it has to trust the signer  to not have two certificates with
different meanings and the same key ... so that if there is a dispute ...
the signer can repudiate the transaction by saying that the sender had sent
the certificate with the "random data" bit set ... but somebody substituted
another certificate w/o the random data bit set  .... unless somebody gets
a law passed saying a signer can't repudiate a transaction if they ever had
two different certificates issued for the same key. Even at that,
certificates don't include the signature on the data in a certificate by
the sender ... only by the CA ... what is to prevent the claim that some CA
generated an arbritrary certificate containing my public key ... w/o
adequately prooving the corresponding private key?

so the movement of all flags/indications ... especially related as to the
intention/belief of the sender associated with a specific message ... into
the signed body of the message. In effect, if there is some trust issue as
to what I believe or intend ... then I need to have explicitly signed it.
If there is some dependency on some state  with respect to some specific
signed message/content ... then the signer  can repudiate it if it isn't
covered by the signature. That is somewhat independent of whether a signer
can also repudiate stuff they've signed. This is specifically that signers
can repudiate a "not random bit" in an appended certificate that isn't
actually part of the signed message.

denis pinkas <[email-masked]> on 5/6/2002 10:42 am wrote:

It is the problem of the signer (not of the CA) to make sure that when it
uses these two different certificates, two different keys are being used.

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 6 May 2002 13:43:02 -0700

Dave,
I realise the intent, but there is a distinction between clarification
and redefinition. The exact intent indicated by bit 1 may be fizzy, but
it does have some boundaries and these proposals are not consistent with
the existing boundaries so are not clarifications but changes of
semantics. 
Trevor

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]] 
Sent: Monday, May 06, 2002 12:53 PM
To: [email-masked]
Subject: Re: Meaning of Non-repudiation

Trevor Freeman wrote:
> 
> Dave,
> If you truly were just changing the names - I could not care one jolt,
> but you are proposing changing the semantics, and that is
unacceptable.
> DS today means sign anything but certs and CRLS. That definition has
to
> stand for that bit.

Trevor,

You can read the standard as well as anyone, and know that
DS today means sign anything but certs, CRLs, *and bit 1 stuff*.

This discussion is trying to de-fuzzy the definition
of bit 1 stuff.  Your claim that {bit 1 stuff} == {the empty set}
may reflect the behavior of some existing products.  And
it is definitely about as non-fuzzy as you can get :-).

But X.509 and 2459 say that, whatever bit 1 stuff is,
it is *not* the empty set.  The X.509 definition, not the
Trevor definition, is what must stand.

Dave

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 7 May 2002 13:31:48 -0400

Sharon:

      With all due respect, IMHO this would be a step backward because the
condition is certainly not sufficient for an NR key.  If a browser
generated a key pair locally for authentication purposes, stored it on its
local disk database, and submitted a PKCS#10 or CR requesting signatures
for authentication it would meet this criterion.  I don't know if this is
even a necessary criterion, but it is certainly insufficient.

            Tom Gindin

Sharon Boeyen <[email-masked]>@mail.imc.org on 05/07/2002
09:28:23 AM

Sent by:    [email-masked]

To:    [email-masked], "500 list (E-mail)" <[email-masked]>
cc:    "Bill Burr (E-mail)" <[email-masked]>
Subject:    Meaning of Non-repudiation

I'd like to introduce another perspective on this topic, one that I really
think helps add some fundamental clarity to the topic. During the US FPKI
TWG meeting last week, this topic was raised and a short discussion was
held. Bill Burr commented that he understood the meaning of the
non-repudiation bit being set to be a statement by the certificate issuer
(CA) that they at no point had any access to the private key corresponding
to the public key being certified. I really like this because it states
what role this bit plays in a non-repudiation context. It is simply that
and nothing more. The remaining mechanisms for supporting a non-repudiation
service are outside the scope of the definition of this bit. Legal and
policy schemes can determine the behaviour of relying parties and users
when this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then that
assertion should be something that accompanies a specific signature. This
bit cannot be expected to act as that assertion.

I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it is
left to profiling groups, as it shoud be, what combinations of bits they
want set in their own environments.

Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the standard,
as well as to fix bugs etc). Part of the problem is that there isn't
agreement on what the original text meant, hence the clarification. Once
there is some sort of agreement on what the "right thing to do" is, then
we'll determine what the process is to achieve the intended result. That's
part of the reason why we are having the discussion before writing up a DR
or an enhancement request.

Sharon

Sharon Boeyen
Principal, Advanced Security
Tel: 613 270 3181
www.entrust.com

Entrust, Inc.
Securing the Internet

---

From: [email-masked]
Date: Tue, 7 May 2002 11:28:19 -0600

so the bit in the certificate just means that the CA dsavows all knowledge
of the private key ... aka "private key not divulged".

then possibly if it can be prooven that the private key was also not
divulged to anybody else ... then some conditions for meeting
non-repudiation requirements might be met (i.e. a CA not having knowledge
of the private key is several steps removed from non-repudiation).

as aside ... definition for "non-repudation" (from nsa intrustion glossary)
and "non-repudation sevice" (from rfc2828) are in merged security glossary:
http://www.garlic.com/~lynn/security.htm

... quick path is to click on "PAIN" in acronym fastpath ... and then click
on "non-repudiation".

<[email-masked]> on 5/7/2002 7:28 am wrote:

Sharon

Sharon Boeyen

Entrust, Inc.
Securing the Internet

---

From: [email-masked]
Date: Tue, 7 May 2002 14:21:12 -0600

sorry, finger fumble with the keys ... or the fingers movingfaster than the
brain.

http://www.garlic.com/~lynn/secure.htm

is the merged security glossary.

for more info about merged glossaries and sources see:
http://www.garlic.com/~lynn/index.html#glossary

[email-masked] on 5/7/2002 11:28 am wrote:

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 08 May 2002 11:25:20 +0200

Sharon,

I agree to almost everything you say but I will have to disagree on this 
particular issue.

The fact that the CA have never possessed or processed the private key is 
neither a clear statement and nor is it always necessary in order 
to  obtain non-repudiation.

One example where you could encounter problem with such definition is when 
you use centrally produced smart cards or key tokens with pre-produced 
keys. Even if the keys have never been exposed in the process, one could 
argue that they have been processed and possessed by the CA system.

Such cards are in use today as national ID-cards and are used to provide NR.

/Stefan

At 14:53 2002-05-07 -0400, Sharon Boeyen wrote:

>Tom, I absolutely agree that this would be insufficient for 
>non-repudiation. However,
>non-repudiation is not a technical operation, but a policy/legal one. This 
>bit is only
>one very small component of non-repudiation. It is the CAs statement. The 
>user's statement
>should be something that accompanies their signature. In the example you 
>cite, perhaps in
>one environment, the policy dictates that all browser generated keys are 
>solely to be used
>for online authentication of a user to a service and not for signatures 
>that could be used
>in a non-repudiation context. In that environment, the policy would 
>dictate that the CA set
>only the digital signature bit and not the non-repudiation bit, regardless 
>of the fact that
>the CA hadn't seen the private key. In another environment, the policy 
>might dictate that
>all client side generated private keys could be used for signatures in a 
>non-repudiation
>context. In that particular environment the policy could dictate that the 
>CA does set the
>non-repudiation bit. The policy would also dictate the key-usage bits that 
>need to be set
>for the different types of operations a user performs (perhaps tied to 
>specific local applications
>e.g. if signing a purchase order must use a key that has this bit set). So 
>all the combinations
>would still be possible, but if the non-repudiation bit was set it would 
>be purely a statement
>by the CA (as dictated by policy) that it did not generate and never had 
>access to the private
>key. That is different that 'requiring' that the bit always be set if the 
>CA didn't generate the
>key. Hope that helps.
>
>Sharon
>
>From: Tom Gindin [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Tuesday, May 07, 2002 1:32 PM
>To: Sharon Boeyen
>Cc: [email-masked]; 500 list (E-mail); Bill Burr (E-mail)

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 10 May 2002 19:26:58 +1200 (NZST)

"David P. Kemp" <[email-masked]> writes:

>I have no problem with X.509 and PKIX following Trevor's approach. Deprecate
>(using the strongest possible terms) the existing KeyUsage OID, and define a
>new KeyUsage OID identical to the old one except that bits 0 and 1 are
>replaced by nonceSign and dataSign.

I agree fully with the theory [0], but I'm not sure about the practicality.
The current keyUsage is going to take a long time (possibly forever) to be
displaced (no matter how strongly it's deprecated), which will lead to problems
unless you're very careful with how you define the semantics, since people are
going to keep using the current keyUsage for backwards-compatibility alongside
the new one.  You'd have to do something like require that if both are present,
the new one overrides the old one, and then use it in combination with the
critical flag if you absolutely require the new semantics and nothing else.

Peter.

[0] That's too mild a term.  I would really, *really* like to see this
    confusion finally sorted out so we can get back to arguing over the meaning
    of DPD.

---

From: [email-masked]
Date: Sat, 11 May 2002 23:44:49 -0600

while i was at it, i thot i would go ahead and update the merged security
glossary with the latest from ISO SC27
http://www.garlic.com/~lynn/secure.htm

some of the new defintions (from merged security taxonomy/glossary; i'm
still working on taxonomy for many of the new terms in the latest sc27
glossary).

non-repudiation

A security service by which evidence is maintained so that the sender of
data and recipient of data cannot deny having participated in the
communication. [IATF] Method by which the sender of data is provided with
proof of delivery and the recipient is assured of the sender's identity, so
that neither can later deny having processed the data. [NSAINT] The ability
to prove an action or event has taken place, so that this event or action
cannot be repudiated later. [ISO/IEC PDTR 13335-1 (11/2001)] [sc27] The
reasonable assurance that a principal cannot deny being the originator of a
message after sending it. Non-repudiation is achieved by encrypting the
message digest using a principal's private key. The public key of the
principal must be certified by a trusted certification authority. [misc]
(see also Generic Security Services API, IT security, NRD token, NRO token,
NRS token, NRT token, assurance, defense-wide information assurance
program, digital signature, distinguishing identifier, information
assurance, invalidity date, 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
token, notarization token, originator, proof, recipient, sandboxed
environment, secure single sign-on, certification authority, public-key
infrastructure, quality of protection) (includes non-repudiation service,
privacy, authentication, identification, integrity, non-repudiation,
privacy, authentication, identification, non-repudation)

non-repudiation exchange

A sequence of one or more transfers of non-repudiation information (NRI)
for the purpose of non-repudiation. [ISO/IEC WD 13888-1 (11/2001)] [sc27]
(see also non-repudiation)

non-repudiation information

A set of information that may consist of the information about an event or
action for which evidence is to be generated and validated, the evidence
itself, and the non-repudiation policy in effect. [ISO/IEC WD 13888-1
(11/2001)] [sc27] (see also non-repudiation)

non-repudiation of creation

This service is intended to protect against an entity's false denial of
having created the content of a message (i.e. being responsible for the
content of a message). [ISO/IEC WD 13888-1 (11/2001)] Protection against an
entity's false denial of having created the content of a message (i.e.,
being responsible for the content of a message). [ISO/IEC 15945: 2002]
[sc27] (see also non-repudiation)

non-repudiation of delivery

This service is intended to protect against a recipient's false denial of
having received the message and recognised the content of a message.
[ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)

non-repudiation of knowledge

This service is intended to protect against a recipient's false denial of
having taken notice of the content of a received message. [ISO/IEC WD
13888-1 (11/2001)] [sc27] (see also non- repudiation)

non-repudiation of origin

This service is intended to protect against the originator's false denial
of having approved the content of a message and of having sent a message.
[ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)

non-repudiation of receipt

This service is intended to protect against a recipient's false denial of
having received a message. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also
non-repudiation)

non-repudiation of sending

This service is intended to protect against the sender's false denial of
having sent a message. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also
non-repudiation)

non-repudiation of submission

This service is intended to provide evidence that a delivery authority has
accepted the message for transmission. [ISO/IEC WD 13888-1 (11/2001)]
[sc27] (see also non-repudiation)

non-repudiation of transport

This service is intended to provide evidence for the message originator
that a delivery authority has delivered the message to the intended
recipient. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)

---

From: [email-masked]
Date: Thu, 16 May 2002 10:43:07 +0200

Looking at existing PKI implementations in standard products like Lotus
Notes or Microsoft Outlook, unfortunately it appears that only
keyEncipherment and digitalSignature are used in an coherent way. Outlook
or Netscape Messenger for example reject and do not offer the use of a key
with a certificate containing a keyUsage = NR only for anything, Notes does
accept it for signing E-Mails (as it does with KeyUsage= DS). On the other
hand a key certified with NR = DS can be used both for authentication and
signing in all products I looked at.

This means that DS is currently interpreted by existing applications as
"private key capable of signing something (a hash or a challenge)", NR is
interpreted by some applications as either equivalent to DS or "private key
not capable of signing." (I did not test the applicability of the keyUsage
= NR for authentication beside checking wether Netscape offers this
certificate for preselection as an authenticaiton certificate, it does not)

Looking at the suggested semantics listed below, existing applications
obviously do not follow, but include the suggested meaning of NR into the
meaning of DS.

Note that a CA can not normally make statements on the environment a user
has when applying a key for any purpose. A CA only can make a statement
like "I informed the user about the conditions under which the key shall be
used, and the user is aware of consequences of not meeting those
conditions." An excemption of this is if the CA knows the the token holding
the private key protects it against misuse in a technologically way then
the CA can make this statement on the "environment". However, one can
always design and deploy an authentication protocol that utilizes a key
capable of signing hashes only. There are no technological means for a CA
to ensure that the user uses a key intended for non-repudiation really only
in this way.

I suggest to define the bits in keyUsage in terms of key capabilities. This
is already been done for the DS bit, and should be done for the NR bit as
well. The NR bit should be defined as "the private key is in some way
restricted in signing certain data formats only, and cannot be used to sign
arbitrary data pieces".
Applications should then not use a key with the NR bit set for
authentication protocols.
|------------------------+------------------------+------------------------|
|                        |   Denis Pinkas         |                        |
|                        |   <[email-masked]|           To:          |
|                        |   t>                   |   pkix                 |
|                        |   Sent by:             |   <[email-masked]>  |
|                        |   owner-ietf-pkix@mail.|           cc:          |
|                        |   imc.org              |           Subject:     |
|                        |                        |   Re: Meaning of       |
|                        |   15.05.2002 18:19     |   Non-repudiation      |
|                        |                        |                        |
|------------------------+------------------------+------------------------|

After taking a few days off, I have analyzed the storm of the e-mail
exchanges on that topic.

The core of the problem is that some people, by claiming requesting some
"clarifications" on these two bits, would like to change their semantics.

:-(

The roadmap provides a good summary of what happened in the past:

   (...) many discussions were needed to arrive at
  a common agreement on the meaning of the digitalSignature (DS bit)
  and nonRepudiation (NR bit) bits and when they should be set. The
  group quickly realized that key usage extension mixes services and
  mechanisms. The DS bit indicates a mechanism - a public key used to
  verify a digital signature. The NR bit indicates a service - a public
  key used to verify a digital signature and to provide a non-
  repudiation service. When trying to indicate when each bit should be
  indicated arguments were based on:

   The lifetime of the object being singed. Some felt that the DS bit
  should be set when the certificate is used to sign ephemeral objects
  (e.g., bind tokens) while the NR bit should be set for things that
  are survive longer (e.g., documents). Of course, the problem with
  this distinction to determine how long is the time period for
  ephemeral?

   A conscious act taken by the signer. Many felt that the NR bit should
  be set only when the subject has expressly acknowledged that they
  want to use the private key to sign an object. Signing a document say
  where there is a conscious decision by the subject would be
  appropriate for the key usage extension to contain NR, but when the
  key is used for authentication purposes, which can occur
  automatically and more frequently, the DS bit is more appropriate.

   The discussion also concluded that since some authentication schemes
  occur automatically, that the DS bit and NR bit should never be set
  together in the same certificate. Some agreed to the differentiation
  of the bits based on the time, but did not agree that the two could
  not be in the same key usage extension.

   The procedures followed by the CA. Some felt that NR bit was kind of
  'quality mark' indicating to the verifier that the verifier could be
  assured that the CA is implementing appropriate procedures for
  checking the subject's identity, performing certificate archival,
  etc. Other felt that it was not entirely the CAs job and that some
  other entity must be involved.

   In the end the WG agreed to a few things:

   - Provision of the service of non-repudiation requires more than a
    single bit set in a PKC. It requires an entire infrastructure of
    components to preserve for some period of time the keys, PKCs,
    revocation status, signed material, etc., as well as a trusted
    source of time. However, the nonRepudiation key usage bit is
    provided as an indicator that such keys could be used as a
    component of a system providing a non-repudiation service.

   - The certificate policy is the appropriate place to indicate the
    permitted combinations of key usages. That is, a policy may
    indicate that the DS and NR bits can not be set in the same
    certificate while another may say that the DS and NR bits can be
    set in the same certificate.

   [2459bis] includes new text indicating the above agreements.

In addition to these explanations I would like to quickly reply to Sharon
to
say her that I disagree (as others) when she says that the only meaning of
the NR bit is to say that the CA has no knowledge of the value of the
private key. This would rule out CAs generating key pairs and would not be
backward compatible with the current meaning.

Now let us attempt to CLARIFY the meaning.

David Kemp offered good explanations on these two bits:

DS bit: the key is used to sign data, nonces or challenges that can be
verified in real-time (entity authentication and data origin authentication
services).

NR bit: the key is used to sign data that can be verified at a later time
(non?repudiation service).

I would offer these additional explanations:

When the DS bit (bit 0) is set, this means that the private key MAY have
been used in an environment that is not fully controlled by the private key
holder. In practice, this means that private keys related to certificates
that have the DS bit set, will be used for entity authentication (e.g.
signing challenges or nonces) or for data origin authentication (signing
data that has not necessarily been reviewed).

Since the environment is not fully controlled by the private key holder,
the
private key holder COULD deny that his key was used to sign a transaction,
because he could claim that he was believing that his private key was used
in an authentication process.

Some authorities (like CRL Issuers) can sign by using a key related to a
certificate that only has the DS bit set because they always chose what
they
sign and will never use that same key in an authentication exchange.

When the NR bit (bit 1) is set, this means that the private key holder will
only use its private key in an environment that he can control and which
allows him to be confident of the data that is being effectively signed..

The signer cannot claim that he was believing that his private key was
simply used in an authentication process that he could not control.

Denis