[Top] [All Lists]

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

2001-08-01 05:59:03

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.

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 
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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>
  • AW: Comments to draft-ietf-smime-rfc2630bis-01, Dieter Bratko <=