Subject: AW: Comments to draft-ietf-smime-rfc2630bis-01

From: "Dieter Bratko" <[email-masked]>
Date: Wed, 1 Aug 2001 15:02:06 +0200

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: [email-masked]
[mailto:[email-masked]]Im Auftrag von Peter Gutmann
Gesendet: Freitag, 27. Juli 2001 18:39
An: [email-masked]
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.