From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
I believe that programmers will implement one of the following:
a) examine the value of the version number and reject (or skip over, if
applicable) fields with unrecognized syntaxes; or
b) ignore the version numbers and just try to decode the object.
I believe that we should write the specs so that vendors can develop code to
properly implement option a.
I agree with John and Blake that a mixture of signerInfos should be
allowed in a v1 signedData. However, I agree with Eric that there
is little practical difference between a) and b). Decoding until
you come to an unsupported version number should have the identical
behavior as decoding until you come to some unrecognized syntax.
"Jim Schaad (Exchange)" <jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com> writes:
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.
There are general rules for extensibility which will allow new
features to be incorporated into existing structures without breaking
old software. X.509 extensions are an example - new extensions can
be defined, and old software either accept or reject certs containing
unrecognized extensions without choking on the ASN.1. The Certificate
version number doesn't get incremented above v3 every time a new set
of extensions is defined.
IMO, a version number should be incremented only when necessary to
prevent incorrect interpretation of an object. A version which tries
to capture every detail of the enclosed subfields is unnecessarily
complex and redundant. It is penny wise and pound foolish, because the
time saved by allowing receivers to do shortcut message rejection on
the outer object is overwhelmed by the complex logic required for
senders to propogate inner contents outward in order to construct
conforming version numbers in the various enclosing objects.
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
The crux of this issue is what S/MIME v2 code will do if it encounters a
version 1 SignedData that contains a SignerInfo with a version other than
1. Will your implmentation:
a) fail to parse the ASN.1 and report an error
b) check the version, skip it, and look for another SignerInfo
c) die ungracefully
(if you do not want to admit this publically, please send
private e-mail or use an anonymous service)
Similarly, what will S/MIME v2 code do if it encounters a version 3
SignedData. If the answer to both questions is a) or c), then that
implementation is too flawed to affect our decision, and can justifiably
be ignored.