Subject: RE: Meaning of Non-repudiation

From: Sharon Boeyen <[email-masked]>
Date: Tue, 7 May 2002 14:53:19 -0400

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

-----Original Message-----
From: Tom Gindin [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)
Subject: Re: Meaning of Non-repudiation

      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: "Dean Adams" <[email-masked]>
Date: Wed, 8 May 2002 13:04:30 +0100

RE: Meaning of Non-repudiationHi,
    Not having been involved in the original round of debates that led to
the establishment of the so called NR bit, I'm probably covering old ground
that was effectively discussed and resolved some time ago, but here goes
anyway.

It seems to me that we are talking about an element in a technical spec, and
which is somehow trying to address what is primarily a policy, procedural
and legal issue.

From a technical perpective, surely we can only specify those things of a
technical nature.  At its most basic, indicating allowable technical usages
such as keyEncipherment, dataEncipherment, keyCertSign, cRLSign etc.  The
difficulty appears to surround the issue of when the subscriber signs
something as a part of his/her intentional day-to-day operations.  In
general as subscribers, we do two things: - (1) sign a challenge to prove
who we are so we can gain access to something, or (2) sign a transaction,
email communication or document to attach our electronic moniker to it.

In the first case, we are using a digital signature technical capability to
authenticate ourselves, much as we have done in the past with passwords.
The real action that we are undertaking is authentication - the fact it is
accomplished via a digital signature mechanism is interesting to
cryptographers but not necessariliy to systems administrators, business
managers and the like.

In the second case, we are putting our name on a communication, transaction
or document for a variety of reasons (as we do in real life with real
signatures) - perhaps to indicate approval of some action (that the
transaction should go ahead, or that the contents of this document or
communication are accepted or formally issued by me), or as in the case of a
written memo from the CEO to all staff - that the contents actually come
from the the CEO.

I suppose the point I'm trying to make, is that we undertake two technical
actions - authentication and signing.  Non-repudiation is not a technical
matter, it is the subject of policy, procedural and legal/regulatory
controls and interpretations.  For example, a policy may exist that states
that the act of signing a communication, transaction or document, will will
be interpreted as ... (acceptance of the published terms, authorising
payment, etc.).  The bits in keyUsage should straightforwardly reflect these
two types of action and no more.

Any instance of repudiation has to be dealt with by policy, procedural,
legal/regulatory mechanisms that should be made aware to signers at the
outset.  Just as they are with respect to hand-written signatures.  These
non-technical mechanisms may draw upon technical protective mechanisms (such
as signing key being generated on smartcards and never being exposed outside
it, etc), to strengthen the means of arbitrating claims of repudiation, but
that is all.  Setting a bit called non-repudiation in a certificate does
nothing for anyone.

IMHO the current assignment of these bits should be declared deprecated, to
allow existing deployments to gradually move to a new specification, with a
new assignment declared for these bits reflecting the two actions described
above.  Most subscriber certs have a limited lifetime, and so it shouldn't
take too long for everyone to be able to move to a new assignment of
keyUsage bits.

Sorry for rambling on a while - just my two cents worth as you folks say.

    Dean

----------------------------------------------------------------------------
----
      Dean Adams Mobile: +44 (0) 7989 385914
      Trustis Limited Direct Tel/Fax: +44 (0) 1252 734320
      49 Whitehall Office Tel: +44 (0) 20 7451 1490
      London SW1A 2BX Office Fax: +44 (0) 20 7484 7961
      email: [email-masked] Web: http://www.trustis.com

The information in this message is confidential. It is intended solely for
the addressee. Access to this message by anyone else is unauthorised. If you
are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited and may
be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Sharon Boeyen
  Sent: 07 May 2002 19:53
  To: 'Tom Gindin'; Sharon Boeyen
  Cc: [email-masked]; 500 list (E-mail); Bill Burr (E-mail)
  Subject: RE: Meaning of Non-repudiation

  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

  -----Original Message-----
  From: Tom Gindin [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)
  Subject: Re: Meaning of Non-repudiation

        Sharon:

              Tom Gindin

  and nothing more. The remaining mechanisms for supporting a
  when this bit is set. The bit itself cannot do that. If an assertion that
a

  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.

  Sharon

  Sharon Boeyen

  Entrust, Inc.
  Securing the Internet