Subject: RE: Non-Repudiation

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 4 Aug 1999 17:20:04 -0400

Dave,

	This one-bit failure thing gets scary when you, say, escrow a
dataEnciperment key pair without the nonRepudiation bit set, but with the
digitalSignature bit set.  And someone signs something for you.  Talk about
being hung by a bit (or hung by no bit)!  Can you think of any safe guards
within the PKIX "environment" that might help (leaving such things as
physical security, key-escrow policy, the ABA, and crossed fingers aside)?

Bill

> ----------
> From: 	David P. Kemp[SMTP:[email-masked]]
> Reply To: 	David P. Kemp
> Sent: 	Wednesday, August 04, 1999 4:15 PM
> To: 	[email-masked]
> Subject: 	Re: Non-Repudiation
> 
> > From: "Aram Perez" <[email-masked]>
> > 
> > How can setting the NR bit ensure that there isn't a "failure in any one
> of
> > those areas"?
> 
> It can't, obviously.  The NR bit is a tiny amount (one binary digit's
> worth)
> of information imbedded in a technical protocol which can be used to
> signal a person's intent, no more, no less.
> 
> If there is NO failure in any of the listed areas, and NO failure in
> areas not listed (what the user saw is what he signed, cert is
> bound to signature, etc), then the fact that the user has chosen to use
> a keypair with the NR bit set instead of a keypair with the NR bit
> clear MAY provide some evidence of intent to the legal process.
> Or it may not, if so determined by the ABA, the courts, and the
> legislatures.
> 
[snip]

---

From: Alfred Arsenault <[email-masked]>
Date: Wed, 04 Aug 1999 20:25:06 -0400

Bill,

"Flanigan, Bill" wrote:
> digitalSignature bit set.  

AWA:  First of all, don't do that.  Yes, I know, some people will
because the architecture of their systems is such that they don't
support separate keys for digitalSignature and dataEncipherment, and
they want to be able to recover their encrypted mail after losing their
keys, but don't even get me started on the lack of wisdom in such a
system design!

>And someone signs something for you.  Talk about

AWA:  In response to Bill's question above, I don't believe that there's
anything in what I consider to be the "PKIX environment" other than the
NR bit that provides this protection, other than compliance with the
rest of the PKIX (proposed) standards (like the stuff on cert path
validation, CRL checking, etc.).

My take on this whole matter is this:

	- I stand by the words I wrote in the Roadmap, which Tony quoted
earlier. Security of the system depends on the security of all the parts
of the system, to include the wetware which operates it.

	- The intent of the NonRepudiation bit was, as Dave Kemp has pointed
out, to show that the CA is willing to say that this certificate is
intended/permitted to be used in signing things for which their is hope
of providing the service of nonrepudiation, as defined in 7498-2 and
paraphrased by Steve Kent.  The intent of this bit is to explicitly
distinguish such certs/keys from those only intended/permitted to be
used in providing the service of authentication via the signing of
short-term entities.  

		- what the CA does before signing a certificate with the
NonRepudiation bit set is a matter left to the CA's CP and/or CPS.  So
is the division of liability between any given CA and user.  If you as
the user don't like the CA's rejection of liability, don't do business
with that CA.  (I try not to.)

		- to have a true non-repudiation system, even with the NR bit turned
on, requires a whole variety of things, and there's little to no legal
precedent, so we don't really know what all is required.  Setting this
one bit is clearly not sufficient, but it may be necessary.

	My bottom line is that I think that the NR bit should be left in,
because at a minimum it serves the purpose of explicitly stating by
being turned off that the CA provides NO WARRANTY whatsoever that the
relying party can expect the service of non-repudiation to be provided.  

			Al Arsenault

	-- the opinions expressed in this message are those of the author, and
do not necessarily represent those of my employer, or of any other
organization with which I have a relationship