John and Russ,
I completely disagree with this. I don't think that it is any type of a
fair statement to say that down level clients should be able in any way,
shape or form to be able to parse one of these new messages. This is why
the MUST occurs in the S/MIME documents.
I don't think it is a deficency of a down level client to be able to
completely fail if the ASN does not completely match to spec, I think this
is normal. If a down-level client is not looking at version numbers then it
will deal with what it deals with, but I think that we need to give them
help not to kill them selfs.
If you are going to go with this agruement then I want to take you arguement
to the logical extreme. The text in section 6.1 should be changed so that
the version number there does not have anything to do with the version
numbers in RecipeientInfos. The same aguements about down-level clients
appear just as valid here as with SignedData. You should either get none of
the cake or the entire cake, not just the pieces you happen to like.
jim
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, February 03, 1999 7:59 AM
To: Ietf-Smime (E-mail)
Subject: RE: Last Call Comments on CMS-10
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