Subject: Countersignature Security Consideration

From: Russ Housley <[email-masked]>
Date: Thu, 15 Oct 1998 14:27:52 -0400

I am trying to write a simple, short paragraph for the "Security
Considerations" section of CMS dealing with the countersignature issues
discussed at great length on this list.  I do not want to rekindle that debate,
but I do want to make sure that the paragraph captures the concerns raised.

Does the enclosed paragraph cover the issues?  If not, please post a
replacement paragraph.

Russ

= = = = = = = = =

The countersignature unauthenticated attribute includes a digital signature
that is computed on the content signature value, thus the countersigning
process need not know the original signed content.  This structure permits
implementations efficiency advantages; however, this structure may also permit
the countersigning of an inappropriate signature value.  Therefore,
implementations that perform countersignatures should either validate the
original signature value prior to countersigning it (this validation requires
processing of the original content), or implementations should perform
countersigning in a context that ensures that appropriate signature values are
countersigned.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 16 Oct 1998 16:01:40 -0700

Russ,

I followed the thread and I have had difficulties to find some time available to
give my opinion earlier.

> Does the enclosed paragraph cover the issues?

I am afraid to say no.  :-(

There has been arguments to say that the co-signer had verified the previous
signature and also its contrary. I believe that the solution should be flexible
enough to handle both cases. Having said that, this means that we should be a
solution that is able to support both cases.

I think that the current document is not "rich" enough to handle the case. When
someone signs a document (e.g. a contract) this is in accordance with the terms of
a policy (i.e. the terms of a contract). In any case the intention of the signer
(or co-signer) must be explicitly mentionned. The intention may be "approval with
verification of the previous signature" or "approval without verification of the
previous signature". Translating this in technical terms, this means that we should
have a non-repudiation policy indicator/pointer and a type of non-repudiation
event. These two attributes should be signed (or "authenticated").

Unless these two "useful" signed attributes are added, I fear that we will not be
able to cover the issues correctly.

Regards,

Denis

> If not, please post a