Based on John's response, I propose the following text:
version is the syntax version number. If no attribute certificates are
present in the certificates field, the encapsulated content type is
id-data, and any of the 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 all of the
elements of SignerInfos are version 3, then the value of version shall be 3.
Russ
At 10:58 AM 2/3/99 -0500, John Pawling wrote:
Blake and friends,
I initially objected to the concept of allowing v1 and v3 signerInfos to
exist in the same signedData because I believed that the beneift was not
worth the problems that they will probably cause in legacy S/MIME products.
I suspect that many legacy products don't check the version number of the
singerInfo before decoding it. If they don't check it, then they will
encounter an ASN.1 decode error when processing a v3 signerInfo which could
cause unpredictable behavior in the software.
Upon further reflection, I now agree with Blake. Potential deficiencies in
legacy products should not drive the design of the v3 S/MIME specs. An
S/MIME v3 user agent should be allowed to send a signedData that includes a
v1 signerInfo that can be processed by all S/MIME user agents and a v3
signerInfo that can only be processsed by v3 user agents. I agree with
Blake that the version number of such a signedData should be v1. If the
version number was v3, then the legacy software would reject the signedData
even though it includes a v1 signerInfo that it could verify.
This concept raises another issue. ESS states: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos in that SignedData object MUST include an
eSSSecurityLabel attribute and the value of each MUST be identical." I
believe that this statement should be changed to: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos (including those marked as v1) in that SignedData
object MUST include an eSSSecurityLabel attribute and the value of each MUST
be identical."
- John Pawling
At 02:53 PM 2/2/99 -0800, Blake Ramsdell wrote:
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
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