We blow out if the EnvelopedData version != 0. I understand that this
prevents us from processing a message with mixed RecipientInfo structures.
In retrospect, we can probably get away with skipping any RecipientInfo for
which we don't recognize the version.
Blake
-----Original Message-----
From: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz]
Sent: Wednesday, July 18, 2001 5:32 PM
To: John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com;
ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
"Pawling, John" <John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com> writes:
Nobody (except for Peter) has stated that their implementations rejected an
EnvelopedData based solely on the version value.
OTOH nobody (except for you) has stated that their implementations won't
reject
an EnvelopedData based solely on the version value. I'd really like to see
some comments from other implementors - Baltimore, MS, Entrust, OpenSSL,
Netscape, what do all of these implementations do? If the vendors won't
respond, perhaps someone who has all this stuff installed for interop
testing
or whatever could feed them some EnvelopedData with a weird version number
(eg
42) to see what they do.
Peter.