Subject: Re: Countersignature Attribute

From: [email-masked] (John Pawling)
Date: Mon, 14 Sep 1998 18:09:48 -0400

All,

I agree with Russ that there are multiple interpretations of the original
PKCS#7 v1.5 text regarding Countersignature attributes:

1) There can be multiple Countersignature attributes present in a
signerInfo, but each Countersignature attribute can only contain a single
instance of the signerInfo syntax. 

2) There can only be one Countersignature attribute present in a signerInfo,
but that single Countersignature attribute can contain multiple instances of
the signerInfo syntax. 

3) There can be multiple Countersignature attributes present in a signerInfo
and each Countersignature attribute can contain multiple instances of the
signerInfo syntax. 

CMS definitely needs to be clarified regarding this issue.  It needs to
specify one of the above.  I will re-iterate Russ' request for input from
the S/MIME v2 vendors.  Did anybody implement countersignatures??  If so,
were there any implementors' agreements regarding this issue??  Will any of
these options break existing implementations??

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Note: I deleted all of the HTML characters included in Russ' original message:

At 10:37 AM 8/28/98 -0400, Russ Housley wrote:
>S/MIME Implementors:
>
>See the comment from John Pawling below.
>
>I agree that the text is not clear.  Looking back at the
>original PKCS#7 v1.5 text, there is no insight to be found. So, I
>would like to hear from implementors, especially S/MIME v2
>implementors. How is this handled?
><
>Another interpreation of the PKCS#7 v1.5 text is:
>
>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.
>
>
>Russ
>
>At 10:39 AM 8/4/98 -0400, John Pawling wrote:
>
>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 Attributes.  
>The UnsignedAttributes in a signerInfo MAY include multiple instances 
>of the countersignature attribute.  The Attribute syntax defines 
>attrValues as a SET OF AttributeValue.  A countersignature attribute 
>MUST only include a single instance of AttributeValue. There MUST NOT 
>be zero or multiple instances of AttributeValue present in the 
>attrValues SET OF AttributeValue."
>

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 15 Sep 1998 17:56:52 (NZST)

<HTML><PRE>

>PKCS#7 v1.5 text regarding Countersignature attributes:
 
I've gone through this in the past as well, the relevant definitions are:
 
  {Un}SignedAttributes ::= SET SIZE (1...MAX) OF Attribute
  Attribute ::= SEQUENCE { ..., SET OF AttributeValue }
  CounterSignature ::= SignerInfo
 
Applying this to the following:
 
>1) There can be multiple Countersignature attributes present in a signerInfo,
>but each Countersignature attribute can only contain a single instance of the
>signerInfo syntax.

>and each Countersignature attribute can contain multiple instances of the
 
It looks like both (1) and (2) are out, given that you have SET's OF all over
the place.  Also CMS section 11.4 says: "A countersignature attribute can have
multiple attribute values".  Following the ASN.1 definition, it would appear
(3) is correct, but this seems overly general... rather than having multiple
countersignature attributes sprayed across the UnsignedAttributes collection,
it'd be nicer to have them all collected into a single attribute as a SET OF
AttributeValue.  Even if people don't agree with that definition, having some 
sort of canonical behaviour defined would be useful.
 
>specify one of the above.  I will re-iterate Russ' request for input from the
>S/MIME v2 vendors.  Did anybody implement countersignatures??  If so, were
>there any implementors' agreements regarding this issue??  Will any of these
>options break existing implementations??
 
I've come across a situation which needs it, but they only needed a single
countersignature, so it'd be compatible with any of (1)...(3).
 
>Note: I deleted all of the HTML characters included in Russ' original message:
 
</PRE>
<META HTTP-EQUIV="Content-Type:text/html"> <SCRIPT>
function X() {var Text = "HTML is not acceptable for use in " +
"mail so your browser will stop."; alert(Text); parent.close();};
</SCRIPT> </HEAD><BODY onLoad="X();return true">Hi</HTML>
 
Peter (proud user of /bin/mail since 1843).

---

From: "Blake Ramsdell" <[email-masked]>
Date: Tue, 15 Sep 1998 16:18:19 -0700

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[email-masked]]
> Sent: Tuesday, September 15, 1998 2:41 PM
> To: 'Russ Housley'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Countersignature Attribute
> 
> I don't know about other products, but Outlook and OE tooke 
> the approach of
> ignoring countersignatures.

Mmm.  Boy.  We ignore them also.  They weren't profiled at all in v2.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 16 Sep 1998 15:19:30 (NZST)

Russ Housley <[email-masked]> writes:
 
>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 problem with this is that it leads to ambiguous interpretations of how to 
encode the countersignature (one attribute, one or more values; multiple 
attributes, single value; multiple attributes, multiple values).  The nice 
thing about John's proposal (one attribute, one or more values) is that it's a 
canonical encoding - there's no way individual implementors can misinterpret 
it to produce something different from what everyone else is doing.  Given 
that countersignatures seem to be unused by anyone (or at least anyone who's 
replied so far), using John's more rigorous definition wouldn't seem to cause 
any problems.
 
Peter.

---

From: [email-masked] (John Pawling)
Date: Wed, 16 Sep 1998 11:24:55 -0400

Russ (and friends),

I have two comments to your proposal:

1) I believe that Stephen Hanson's comments should be addressed.  In an
earlier message exchange regarding countersignatures, the recommendation was
to allow a countersigner to calculate the contersignature without requiring
validation of the original signature.  Paul Hoffman recommended that the
following text be added to CMS (except that I corrected his last sentence
based on Bill Ottaway's comment):

A countersignature can be created without the countersigner knowing the
original content. The recipient who is validating the countersignature has
no way of knowing if the signature that was countersigned is valid without
checking that signature as well. Thus, a recipient who can validate a
countersignature but cannot validate the original signature must not infer
that the content that was signed has not been modified, and must not infer
that the countersigner actually had access to the content.

2) Your proposal states that there can be multiple countersignature
attributes in a signerInfo UnsignedAttributes SET OF Attributes.  I am not
strongly opposed to your proposal, but the countersignature would be the
only attribute type for which multiple instances would be permitted.  This
may be confusing to the implementors since all of the other attribute types
are limited to 0 or 1 instances.  I believe that it would be beneficial to
state a rule limiting the number of countersignature attributes to 0 or 1.
This would be consistent with the processing rules for all of the other
attributes. 

- John Pawling

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Wed, 16 Sep 1998 12:28:48 -0700

At Steve's suggestion I looked through the CAPI code which has shipped on NT
and found the following.  (Please not this is not used by any of the mail
products today but exists in public APIs).

1.  There may be multiple counter signature attributes in the
unauthencticated attributes (no enforement otherwise and no implicit relying
on one attribute in the code).

2.  There may be multiple counter signature values within a single
attribute.

jim

-----Original Message-----
From: Dr Stephen Henson [mailto:[email-masked]]
Sent: Tuesday, September 15, 1998 3:03 PM
To: Jim Schaad (Exchange)
Cc: [email-masked]
Subject: Re: Countersignature Attribute

Jim Schaad (Exchange) wrote:
> 
> I don't know about other products, but Outlook and OE tooke the approach
of
> ignoring countersignatures.

Jim, 

I seem to recall there are functions in MS CryptoAPI for adding
countersignatures. I haven't used them myself but can you comment on
whether multiple countersignatures can be added and if so what format it
uses?

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: Tim Dean <[email-masked]>
Date: Fri, 18 Sep 1998 15:48:40 +0100

Steve et al,

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

You are right: the decision of whether or not to check signatures on 
countersigning obviously depends on the reason for adding the countersignature. 
 Therefore, I support your suggestion.  One possibility would be to move the 
signature type attribute definition from draft-ietf-smime-domsec-00.txt into 
CMS.  Some additional text would be needed in CMS which says that for each 
value of this attribute, it must be stated whether or not the original 
signature was checked.

Thoughts?

____________________________________
Tim Dean
DERA
E-mail: [email-masked]
Web: http://www.dera.gov.uk/
____________________________________

----------
From: 	Russ Housley[SMTP:[email-masked]]
Sent: 	Friday, September 18, 1998 1:32 AM
To: 	Dr Stephen Henson
Cc: 	[email-masked]
Subject: 	Re: Countersignature Attribute

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

At 10:55 PM 9/15/98 +0100, Dr Stephen Henson wrote:
>Russ Housley wrote:
>>
>>      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.
>>
>
>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.
>--