All,
I respectfully disagree with Jim. 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. This allows a single message to be sent to all recipients.
Otherwise, the user would need to send two messages: the old S/MIME v2
message to legacy users and a new S/MIME v3 message to S/MIME v3 users.
This seems unworkable, because how does the originator know what flavor of
software will be used by each recipient.
Furthermore, an S/MIME v3 user agent should be allowed to send an
envelopedData that includes a v0 RecipientInfo that can be processed by all
S/MIME user agents and a v3 RecipientInfo that can only be processsed by v3
user agents. The version number of such an envelopedData should be v0. If
the version number was v3, then the legacy software would reject the
envelopedData even though it includes a v1 ReceipientInfo that it could
process. This allows a single message to be sent to all recipients.
Otherwise, the user would need to send two messages. The old S/MIME v2
message to legacy users and a new S/MIME v3 message to S/MIME v3 users.
I agree with Jim that the rules for setting the signedData and envelopedData
version number must be consistent. Recommend that the Sec 6.1 text
regarding envelopedData version should be changed as follows:
"version is the syntax version number. If originatorInfo is
present, then version shall be 2. If all of the RecipientInfo
structures included have a version other than 0, then the version
shall be 2. If unprotectedAttrs is present, then version shall be
2. If originatorInfo is absent, any of the RecipientInfo
structures are version 0, and unprotectedAttrs is absent, then
version shall be 0."
- John Pawling
At 12:13 PM 2/3/99 -0800, Jim Schaad (Exchange) wrote:
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