Subject: Re: Countersignature Attribute

From: [email-masked] (John Pawling)
Date: Tue, 15 Sep 1998 11:56:44 -0400

Peter (and friends),

I agree with your recommendation.  This results in a change to my comment to
CMS-06 to read as follows:

5) Sec 11.4, Countersignature: Please change as follows:

OLD: "A countersignature attribute can have multiple attribute values."

NEW: "The UnsignedAttributes syntax is defined as a SET OF Attribute.  
The UnsignedAttributes in a signerInfo MUST NOT include multiple 
instances of the countersignature attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A countersignature attribute 
MAY include one or more instances of AttributeValue.  There MUST NOT 
be zero instances of AttributeValue present in the attrValues SET
OF AttributeValue."

Does anybody disagree with this recommendation???

- John Pawling

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Sep 1998 16:39:56 -0400

John:

Prior to getting this note, I took a stab at revisions to the same
section of text.  I do not know how S/MIME v2 implementations handle
countersignatures, but I took the opposite approach that you did.  I
was trying to ensure that current implemntations would all conform.

Here is what I wrote:

A countersignature attribute can have multiple attribute
values.  The syntax is defined as a SET OF AttributeValue, and there
must be one or more instances of AttributeValue present.

The UnsignedAttributes syntax is defined as a SET OF
Attributes.  The UnsignedAttributes in a signerInfo may include
multiple instances of the countersignature attribute.

The fact that a countersignature is computed on a signature value
means that the countersigning process need not know the original content
input to the signing process.  This might have efficiency
advantages, but it also has security disadvantages.  Therefore,
countersigners must validate the signature value prior to signing
it.  This validation requires processing of the original
content.

A countersignature, since it has type SignerInfo, can itself contain
a countersignature attribute.  Thus it is possible to construct
arbitrarily long series of countersignatures.

Russ

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 15 Sep 1998 22:55:16 +0100

Russ Housley wrote:
>      means that the countersigning process need not know the original
>      content input to the signing process.  This might have efficiency
>      it.  This validation requires processing of the original content.
> 

I respectfully disagree that it should be made mandatory for a
countersigner to process the original content. IMHO it should depend on
the purpose of the countersignature which is itself related to the
policy of the signing authority.

In particular take the example of a trusted timestamp. The purpose of
such a countersignature is simply to state that a a given signature
existed at a given time. It says absolutely nothing about the content
being signed. It has a definite and valuable purpose for nonrepudiation.

It can for example show that a document was signed during the validity
period of the signer's certificate and is thus useful fot archiving
purposes and others related to software publishing.

In for example a large and confidential document a client would simply
pass its digital signature to the timestamper. If the content needs to
be analysed then large amounts of possibly confidential data would need
to be passed to the timestamper. This is undesirable both in terms of
security and increased load on the countersigner.

Of course if the countersignature is to have some additional value then
having access to the content does become important.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Sep 1998 20:32:05 -0400

Steve:

How do you know that the signature value being counter-signed has anything
to do with the content if you skip this step?

I agree that the signer cert path does not need to be validated to ensure
that the appropraite binding...

Russ

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 17 Sep 1998 14:30:15 +0100

> to do with the content if you skip this step?

You don't: they could just be getting random data countersigned that
isn't the signature to anything. 

If the client can't verify the original signature they can't rely on the
countersignature. At best it could see that the digital signature being
countersigned is a signature of "something" though not what it referred
to. It may or may not refer to some valid content.

A similar case could arise even if the countersigner does verify the
original content and it was for example corrupted in transit. In this
case the client could make the conclusion that some content was
countersigned they would just have no idea what it was.

IMHO the only real difference between the two is that without content
verification an arbitrary digest could be countersigned whereas with
content verification it would have to be a digest to some known content.

I'm not sure what additional tricks could be played with content
verification but without chain verification: since bogus certificate
chains with arbitrary public keys could be included.

In the case of a timestamp none of this matters. 

IMHO there are serious practical, security and privacy issues involved
if content has to always be examined by the countersigner, particularly
in the case of a timestamping authority.

In this case the countersigning certificate may well (should?) contain
appropriate extensions to indicate that it is a timestamping authority.

Maybe something more explicit could be included? For example an
additional signed attribute in the countersignature to indicate that the
original content had been examined?

Steve.

---

From: Francois Rousseau <[email-masked]>
Date: Thu, 17 Sep 1998 11:14:48 -0400

>original content had been examined?
If I am not mistaken, the EDI assurance segments from ANSI X12.58 contains
such a parameter (i.e. Domain_of_Computation_of_Assurance_Digest) to
indicate the scope of the digital signature.

Francois Rousseau