Subject: Re: Signing what you don't understand

From: [email-masked]
Date: Mon, 17 Jul 2000 10:21:20 -0400

Anything in the certificate that's used to imply something about the intent
behind a signature is asking for trouble, unless the specific certificate
that a relying party should use is bound to the signature.  What's to
prevent me from obtaining certificates from two different CAs, certifying
the same key, but with different settings of the NR bit in the two
certificates, and then using the certificate with the NR bit clear to
repudiate a signature I originally represented as being non-repudiable
using the other certificate?

The only way that using anything in the certificate could work is if the
specific certificate that I intend a relying party to use to verify the
signature is somehow bound into the signature.  Binding a particular
certificate to a signature has all sorts of other problems (e.g. do all my
signatures become unverifiable when my certificate is renewed?), and would
require a signature format change anyway, so why not simply assert the
intent explicitly as part of the signature?

John

Stephen Kent <[email-masked]> on 07/13/2000 09:48:56 AM

To:   <[email-masked]>
cc:   <[email-masked]>
Subject:  Re: Signing what you don't understand

Denis,

>The most important point of my previous message was buried under a pile of
>other stuff, so I am repeating it here:
>
>
>It is my proposal that a signature format is designed which will allow an
>entity to say: "I signed this data, but I didn't understand what I signed.
>You are free to use this signature as proof that I possess a certain
private
>key, but this is also the only purpose for which this signature can be
>used."

We have had an analogous debate on this list last year.  This is one
motivation for the use of the non-repudiation bit in certificates,
i.e., if this bit is NOT asserted, one can reasonably interpret the
signature as not binding.  This does not require a change to the
signing format, but rather appropriate use of key usage bits in
certificates. As others have pointed out, the preferred way to
represent the distinction between binding and non-binding signatures
is via flags in certificates, e.g., key usage, cert policy, etc.

Steve

---

From: Denis <[email-masked]>
Date: Mon, 17 Jul 2000 20:38:09 +0200

John,

See my response  below.

> using the other certificate?

Nothing can *prevent* someone to do this, but that someone should be
warned about the precautions to be used if this is done.

> certificate to a signature has all sorts of other problems

I do not think so. It has major benefits.

> (e.g. do all my
> signatures become unverifiable when my certificate is renewed?),

Very, *very* briefly, time-stamped signatures may be proven to be
valid long after the end of the validity period of the signer
certificate.

> and would

It is not a "change". It has to do with the right use of a signature
format, that binds the identifier of the certificate to the digital
signature. S/MIME has provisions for this. The recently posted draft
to the S/MIME working on "Electronic Signature Formats" uses the
same feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

Denis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jul 2000 20:11:11 -0400

John,

>using the other certificate?

Not necessarily. You seem to assume that a signer could escape 
responsibility for signing in an NR context by producing a 
certificate with the same public key but without the NR bit asserted. 
I don't subscribe to that assumption.  if I, as an RP, collect a cert 
associated with the user and it has the right public key and NR 
asserted, then why is my assertion of which cert was used in the 
transaction untenable?  A legitimate user should never put the same 
public key into two certs that differ in terms of this key usage bit 
(and probably not if they differ in other, significant ways).  If 
push came to shove and the user asserted that the NR-enabled cert was 
not really issued at his request, a check of CA records for POP could 
resolve the problem. [I assume that any CA issuing a cert with an NR 
bit enabled ought to insist on POP, but maybe that's my unwarranted 
assumption :-).]

>intent explicitly as part of the signature?

Based on my comments above, I'm not sure we need to perform this 
binding, but I agree with Denis's comments here, i.e., it's not 
infeasible and the persistence of the signature is divorced from the 
certificate lifetime by other mechanisms.

By the way, I'm not saying that a new format for signatures which are 
designed precisely for NR purposes with general purpose documents is 
a bad idea.  I just commented on what appeared to be a lack of good 
arguments for such a construct.  I agree that the ability to have a 
small token be able to understand such constructs could be valuable, 
even though we still face a lot of problems with regard to secure 
display of the contents of what is being signed.

Steve