Subject: RE: Last Call Comments on CMS-10

From: "Blake Ramsdell" <[email-masked]>
Date: Tue, 2 Feb 1999 14:53:22 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 02, 1999 2:43 PM
> To: Ietf-Smime (E-mail)
> Subject: RE: Last Call Comments on CMS-10
> 
> I believe that a version 3 SignerInfo MUST cause the parent SignedData
> version to be 3.  This strategy allows the receiving software 
> to be able to
> distinquish between an S/MIME v2 or v3 message by looking at 
> the first field
> in the signedData.

I respectfully disagree -- it is possible to have multiple SignerInfos, some
of which are v2 and can be processed by a v2 agent.

If you reword this to be "if all of the SignerInfos are v3, then the parent
SignedData should be version 3" or equivalent verbiage, then I think I'd go
along with it.

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: Russ Housley <[email-masked]>
Date: Wed, 03 Feb 1999 12:49:17 -0500

Please excuse my previous posting.  when I did a cut-and-paste from anothe
window, my mail user agent software decided to make it HTML.  Sorry.  Here
is the reply in plain text.

==========

John:

I agree.  How about this for replacement text in section 5.1:

	The fields of type SignedData have the following meanings: 

		version is the syntax version number.  If no attribute 
		certificates are present in the certificates field, the 
		encapsulated content type is id-data, and all elements of 
		SignerInfos are version 1, then the value of version shall 
		be 1.  Alternatively, if attribute certificates are 
		present, the encapsulated content type is other than 
		id-data, or any of the elements of SignerInfos are version 
		3, then the value of version shall be 3.

Russ