ietf-smime
[Top] [All Lists]

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

2001-07-19 17:41:53

Baltimore has two implementations.  The old implementation,
SMT, ignores the version number and will fail if it gets
anything that falls outside the PKCS#7 spec.  

The newer implementation, KeyTools S/MIME, pays attention
to the version number and won't process the message unless 
it understands it.  It's debatable - and I suppose that's 
what this is about - whether this is a better approach.

Taking a stab at it (and I haven't been reading this 
thread thoroughly, so apologies if this is treading old
ground) ideally, I'd ignore all the tagged ASN.1 that we 
don't know about, keep going until there's some parsing 
error we can't deal with, and *then* check the version 
number for error-reporting.  This would have gotten us
through the differences between PKCS#7 and RFC2630 
fairly handily.

By the way, while I'm here - the CMS in PKCS#7 is v1.5.
What's the version of CMS in RFC2630?  How should we
refer to it?

Andrew Shellshear.

"Guttman, Peter" <pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz> writes:
"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.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.