Peter,
RFC2630 (and I assume son-of-RFC2630) references the 1988 ASN.1 specs.
Given that fact, adding the password-based encryption option to the
RecipientInfo CHOICE IS a change to the EnvelopedData syntax. Not all
S/MIME implementations include the flexibility to skip unknown-tagged items
in a CHOICE. For example, the S/MIME Freeware Library uses the Enhanced
SNACC Compiler and library to implement the S/MIME v3 specs. The Enhanced
SNACC library will return an ASN.1 decode error if it encounters an
unknown-tagged item in a CHOICE. I am sure there are other implementations
that would also return an error under those conditions.
Having said all of that, I retract my recommendation to assign a new value
for use in the EnvelopedData version field due to the addition of the
password-based encryption option to the RecipientInfo CHOICE. I doubt if
many implementations check the EnvelopedData version value before attempting
to decode the hex data. A new version number would have assisted with
debugging and error reporting, but it is probably not worth the effort to
change the specs and implementations to populate the new version value.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Thursday, April 19, 2001 4:17 AM
To: John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com;
ietf-smime(_at_)imc(_dot_)org
Subject: RE: S/MIME version number
"Pawling, John" <John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com>
I believe that when an ASN.1 syntax is changed that includes a version
field,
then a new version number should be assigned to indicate the new ASN.1
syntax.
It doesn't really change it though, it just adds another option to the
CHOICE.
I would hope that any software which works with these things would just skip
the unknown-tagged item (having said that my own code will reject it because
I
tend to be overly pedantic in my checking, changing a constant and
recompiling
will fix this behaviour). On the whole I don't know whether changing the
version number will have any useful effect, because anything which rejects a
new CHOICE tag is just as likely to reject a new version number (any
comments
from implementors? If making either change will break apps equally then I'd
vote to leave the version number alone).
(Just for form's sake, I'll add my standard gripe that if we were using any
kind of non-archaic ASN.1 you could just add '...' to the CHOICE and this
whole issue would go away).
Peter.