Re: [IETF-PKIX] digitalSignature vs. nonRepudiation

[Sam Schaen <schaen@xxxxxxxxx>]

I believe too much is being made of the difference between
digitalSignature and nonRepudiation.  What we seem to be ignoring is the
context of the signature.  In the "wet signature" world, my same
handwritten signature can be used to sign a $10 check at the grocery
store, a $200K mortgage, or acknowledge receipt of a package from UPS.

I claim that in any context, the law will make assumptions about what
was reasonably intended by a signature and will hold reasonable
standards for what protections must surround the storage and use of the
digital signature.  Furthermore, any certificate will have a CPS behind
it that provides contractual limitations on what the signature can be
obligated for.

Sam Schaen

Hamid Homayouni wrote:
>
> Similar to Bill, I've not been involved in the discussions that led to this
> proposal. So please bear with me.
>
> The technical mechanisms for both digital signature and non-repudiation are
> the same. The only thing that can enforce non-repudiation is proper
> legislation behind it.
> At the same time, as a user, I'd prefer to separate my key usage into
> "digital signature" for day-to-day I&A use, and "non-repudiation". ie. I
> really want to consciously sign something and not get it mixed up with my
> day-to-day activity of using my I&A keys. Similar to what I actually do
> with my normal hand signature. I've one (the short version) that I use
> within the office for memos, etc, and one that I use for financial
> transactions (ie, I'm consciously accepting a bigger responsibility).
>
> So regardless of how it's implemented, the idea of key usage extension is
> useful, and I also suggest that the digitalSignature bit be set by default
> when nonRepudiation bit is set, but not the other way round. So I end up
> conveniently using my nonRepudiation key for both non-rep and I&A when I've
> consciously pulled it out. But I won't inadvertently sign a something while
> I'm using my other key for day-to-day I&A purposes.
>
> Regards,
>
> -Hamid Homayouni
>
> On Tuesday, November 25, 1997 3:15 AM, Bill Burr  wrote:
>
> > It seems to me that these two bits are trying to split much too fine a
> > hair.  The best solution would be to eliminate one or the other.  I
> wasn't
> > a participant in the discussions that led to the inclusion of both in the
> > Key Usage field, and have no real idea what was on the participants mind
> in
> > making this distinction, but there doesn't seem to be any real agreement
> > about just what non-repudiation actually means.
> >
> > I would say that non-repudiation is, or ought to be, a property, rather
> > than a service or a usage, which any digital signature ought to be
> designed
> > to have, to as high a degree as practical, and which is greatly affected
> by
> > other circumstances of the signature (e.g., date-time stamps, or whether
> a
> > gun was pointed at the head of the signatory when he executed the
> signature).
> >
> > The idea of an explicitly repudiable digital signature is repugnant.  So,
> > if setting the digitalDignature bit while not setting the nonRepudiation
> > bit means, in effect, "I reserve the right to deny I ever signed this," I
> > think I'd like to see that combination banned. If I have such a
> > certificate, can I use it to authenticate myself to log onto a system, do
> > some mischief, then repudiate that I ever logged on?
> >
> > If the point of the nonRepudiation bit is just to say this is a bit
> > stronger kind of a key or signature, then I that may be OK, but
> > certificatPolicies, if you believe in them, may be a better way to
> express
> > this.  At any rate, if this is the case, setting nonRepudiation while
> > leaving digitalSignature unset, makes no sense.
> >
> > I'm afraid that what we have here is another example of the kind of a
> camel
> > that we often get from a standards committee, which designs in the
> abstract
> > for the ages, and supplies answers for questions that haven't been and
> > don't need to be asked.  I'd prefer to see one of the bits eliminated
> > altogether. Failing that, I'd like to profile both bits as either set or
> > not set together, but never just one or the other.
> >
> >
> >
> > At 04:26 PM 11/22/97 -0700, you wrote:
> > >I agree in setting both if the CA issuing the cert is issuing it for
> more
> > >than just I&A, as would/should most commercial CAs such as banks or
> > >merchants.
> > >
> > >I also believe that, because the options are in the extension, a lawyer
> > >could argue against non-repudiation if it is not set, even though the
> > >re;liant party knows who signed something and that what was signed has
> not
> > >been altered since signing.
> > >
> > >If someone were contesting (attempting to repudiate) a signed agreement
> > >because non-repudiation was not set, then that would probably go in
> front of
> > >a court fro final arbitration.  If they both were set, then that reason
> is
> > >at least eliminated.
> > >
> > >michael
> > >
> > >
> > >-----Original Message-----
> > >From: Simonetti David <simonetti_david@bah.com>
> > >To: ietf-pkix@tandem.com <ietf-pkix@tandem.com>
> > >Date: Monday, November 17, 1997 1:45 PM
> > >Subject: digitalSignature vs. nonRepudiation
> > >
> > >
> > >>I am attempting to implement the key usages as defined for the keyUsage
> > >>extension.  I am stumbling upon digitalSignature and nonRepudiation.
> > >>
> > >>I define the key usage digitalSignature as a public key which affords
> > >>the services of authentication and data integrity.
> > >>
> > >>Of course, nonRepudiation affords the service of non-repudiation.
> > >>
> > >>My question is, with only nonRepudiation set (and not
> digitalSignature),
> > >>is it true that my public key can be used only to provide the service
> of
> > >>non-repudiation, and NOT the services of authentication and data
> > >>integrity?  If this is true, I'm curious to know how this is
> > >>implemented.
> > >>
> > >>I claim that if the nonRepudiation bit is set, that I can use that key
> > >>to implement authentication and data integrity, and also claim
> > >>nonRepudiation of the originator.  Since authentication and data
> > >>integrity are services provided under digitalSignature, I believe that
> > >>when nonRepudiation is set, digitalSignature should also be set.
> > >>
> > >>I'd like to hear agreements or disagreements with my line of reasoning.
> > >>
> > >>Dave Simonetti
> > >>
> > >>
> > >
> > >
> > Regards,
> >
> > Bill Burr