Hello,
just to add one entry to the list: for our Java based CMS, S/MIMEv3
implementation we do not check the version number when parsing an
EnvelopedData. However, we currently do not accept another RecipientInfo than
KeyTransRecipientInfo, KeyAgreeRecipientInfo or KEKRecipientInfo as required by
RFC 2630, i.e. we do not support PasswordRecipientInfo, and OtherRecipientInfo
handling so far; we will wait to adopt our libraries until
draft-ietf-smime-rfc2630 has reached its final version.
Regards,
Dieter Bratko, IAIK
-----Ursprüngliche Nachricht-----
Von: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]Im Auftrag von Peter
Gutmann
Gesendet: Freitag, 27. Juli 2001 18:39
An: ietf-smime(_at_)imc(_dot_)org
Betreff: Re: Comments to draft-ietf-smime-rfc2630bis-01
Here's a summary of the situation, hope I got all these right:
Baltimore (old, SMT): Rejects message if version != 0
Baltimote (new, KeyTools): Won't process the message unless it understands the
version (does this mean it requires version = 0...2?)
cryptlib (older versions): Rejects message if unknown version encountered
(value >2)
cryptlib (newer versions): Ignores version
Microsoft: Ignores version
OpenSSL: Ignores version
RSA: Rejects message if version != 0
SFL: Ignores version (except for use in reporting errors)
Tumbleweed: Rejects message if version != 0
So it looks like there's about a 50/50 split between implementations which
require the version to be 0 (or in some cases 0...2) and ones which ignore it
entirely.
Peter.
smime.p7s
Description: S/MIME cryptographic signature