Subject: Re: Signing what you don't understand

From: [email-masked]
Date: Tue, 18 Jul 2000 10:47:05 -0400

Steve,

>>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?
>
>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 :-).]

I think you're suggesting the use of a distinct key for each possible
"signature intent" here (although the example deals with R vs. NR, there
are more than just two flavors of signature intent).  Quite apart from
requiring a signer to maintain a large number of distinct keys, I think
it's a bit much to expect every "legitimate user" to be well-enough versed
in the nuances of certificates to always request the same certificate
extensions in every certificate for a given key.

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

What other mechanisms would cover that case of my issuing CA going out of
business?  If a CA's assets (including its keys) are sold as part of a
bankruptcy process, I would think that trust in those keys would be fairly
quickly revoked by other CAs that might have cross-certified it.  In this
case, invalidityDate on those revocations would probably be set so that no
certificate that had been issued by the former CA's key would be trusted
(to prevent the keys' new owners from issuing new backdated certificates).
However, as a subscriber to the former CA, I don't see why my signatures
should suddenly become less trustworthy, if my key can be verified via
another path.

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

The most persuasive argument I can come up with is an architectural one,
and assumes that there are more flavors of "signature intent" than just
repudiable vs non-repudiable.  There are three places I can see that one
might try to encode the intent behind a signature: The particular key used,
the particular certificate used, or explicitly as part of the signature
structure.  The intent behind a signature is fairly dynamic, possibly
varying with each signature.  On occasion I might want to sign a nonce
simply to prove I possess a key; at other times I might want to sign a
piece of e-mail to indicate that I have read it, i.e. to generate a
return-receipt;  at other times my signature might assert my agreement to
the contents of a document;  at other times it might be intended as an
approval of some business process (i.e. "If the expenses listed in the
document are as described, then they may be reimbursed").  However, both
the certification hierarchy and the availability of keys are fairly static
things - I either need to get my key re-certified for each possible
signature intent I might want to assert, or I need to generate and certify
a distinct key for each possible signature intent.  Encoding the intent
explicitly as part of the signature allows me to choose at the time I
generate the signature what intent I wish to associate with the signature,
rather than having to have previously set up certification chains for all
intents I might wish to asserts.  I would also claim that it's less
error-prone and probably of greated legal validity to explicitly encode the
intent along with the signature than to try to infer the certified intent
from the contents of certificates issued by third-party CAs.

John

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 18 Jul 2000 17:05:16 +0200

[email-masked] wrote:

> Quite apart from

Right. This kind of details has to be hidden to the average user.

> Encoding the intent
> intents I might wish to asserts.

Maybe this can simply be done through the signed extensions that are available
with PKCS#7 ?

It sounds quite feasible and would not require any format change, just defining
some new extensions and their role.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jul 2000 14:58:29 -0400

John,

<snip>

>extensions in every certificate for a given key.

I am a firm believer in users holding multiple certs and multiple 
keys. Appropriate interface/management software should make this 
tolerable.  I also believe that it is rarely appropriate to put the 
same key into multiple certs, hence my general lack of concern over 
the other issue you cite.  But, if one needs to push the granularity 
of signature intent very far, then I agree that what I proposed could 
become infeasible to manage.

>should suddenly become less trustworthy, if my key can be verified via

A RP can be responsible for acquiring all the requisite evidence for 
later support of signed document validity, including time stamping 
this evidence. I think this addresses the scenario you described 
above.

>from the contents of certificates issued by third-party CAs.

Those are good arguments.  One can choose to represent this info in 
the document being signed, analogous to what we do in the physical 
world, or can try to codify the various intents in a newly defined 
signature format.  The latter approach will entail considerable 
haggling over what the requisite info types will be, how to encode 
them, etc.  The same problems would arise if we try to do this fine 
granularity intent expression in a standard fashion in signed 
documents.  We already have this sort of facility in the policy 
qualifier aspect of cert policies, and many of us question the 
ability of folks to manage this in the more static context in which 
it might be used.  So, another aspect of this debate is whether the 
"average" user is capable of managing this sort of facility, on a per 
signature basis, as suggested, irrespective of how we support the 
capability.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 18 Jul 2000 17:05:13 +0200

John,

May I suggest again that you take a closer look at 

http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

which answers most of your basic questions.

Regards,

Denis