Subject: S/MIME version number

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 6 Apr 2001 17:17:12 -0700

From John's WG minutes:

> Paul Hoffman asked if the change in the algorithms would case the
> S/MIME version number to change (ex: v3.1).  John Pawling made the
> point that the CMS ASN.1 syntax is not changing, just the algorithms
> used with that syntax.  He further stated that the algorithms in an
> instance of a CMS object are clearly indicated by OIDs populated in 
> that object, so a version number change is not required.  Russ agreed
> and made the point that the RFCs would change, but the S/MIME version
> number would still be 3.  Nobody disagreed with Russ.  

Because this is a combination of message syntax and algorithm use (however
identifcal they might look on the wire, and however clearly the algorithms
being used are identified in that representation), I believe that there
needs to be a unique way to represent this.  From a practical standpoint as
an application vendor, I want to say "we support S/MIME v3.1" (specifially
meaning that we do not support in any way the Diffie-Hellman variant used in
S/MIME v3, which is a germane difference between the current "S/MIME v3" as
defined in RFC 2633 and "S/MIME son-of-2633").

Blake
--
Blake C. Ramsdell
Tumbleweed Communications
Voice +1 425 376 0225 x103  Fax +1 425 376 0915

---

From: "Pawling, John" <[email-masked]>
Date: Mon, 16 Apr 2001 15:06:55 -0400

Jim,

I believe that this comment applies to the upcoming CMS draft rather than
the Password Based encryption I-D.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, April 16, 2001 3:03 PM
To: 'Pawling, John'; [email-masked]
Subject: RE: S/MIME version number

John,

I think that you need to make a comment about this either in regards to the
Password Base encryption that is currently with the IESG in last call, or
with the upcoming CMS draft to be issued.

jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Pawling, John
> Sent: Monday, April 16, 2001 10:26 AM
> To: [email-masked]
> Subject: RE: S/MIME version number
>
>
> Jim,
>
> I believe that when an ASN.1 syntax is changed that includes a version
> field, then a new version number should be assigned to
> indicate the new
> ASN.1 syntax.  If password-based encryption is added as a new
> CHOICE to the
> RecipientInfo syntax (which is part of EnvelopedData), then I
> believe that a
> new version number should be assigned for use in the
> EnvelopedData version
> field.  In that case, I propose that the RFC 2630, Section 6.1
> EnvelopedData Type, version definition should be changed to
> state: "version
> is the syntax version number.  If originatorInfo is present,
> then version
> shall be 3.  If any of the RecipientInfo structures included
> have a version
> other than 0, then version shall be 3.  If unprotectedAttrs
> is present, then
> version shall be 3.  If originatorInfo is absent, all of the
> RecipientInfo
> structures are version 0, and unprotectedAttrs is absent,
> then version shall
> be 0."
>
> ===========================================
> John Pawling, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 19 Apr 2001 02:41:16 (NZST)

"Pawling, John" <[email-masked]> writes:

>I agree that there are work-arounds for this problem, but I prefer that we
>define a clean strategy (i.e. new SignedData and EnvelopedData version
>numbers), rather than needing to resort to work-arounds.

Given that use of ACs is currently essentially nonexistant and that ACs used
with S/MIME are probably[0] completely nonexistant, why is this an issue?  It's
not as if it's going to break some vast installed base of software if we just
say that ACs use the 2000 syntax and leave the version numbers alone.

Peter.

[0] Added as a safety catch just in case there is some solitary implementation
    floating around out there.

---

From: "Pawling, John" <[email-masked]>
Date: Wed, 18 Apr 2001 12:05:32 -0400

Peter,

I made a similar statement in my original response to Blake's message: 

"The other option is that the "son-of-RFC 2630" CMSVersion number usage
could
remain the same as defined in RFC 2630 if the working group assumes that
1997 ACs have not been operationally used in SignedData and EnvelopedData
objects.  I do not know if that is a safe assumption."

I still do not know if that is a safe assumption.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 10:41 PM
To: [email-masked]; [email-masked]
Subject: RE: S/MIME version number

Given that use of ACs is currently essentially nonexistant and that ACs used
with S/MIME are probably[0] completely nonexistant, why is this an issue?
It's
not as if it's going to break some vast installed base of software if we
just
say that ACs use the 2000 syntax and leave the version numbers alone.

Peter.

[0] Added as a safety catch just in case there is some solitary
implementation
    floating around out there.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 19 Apr 2001 08:17:22 (NZST)

"Pawling, John" <[email-masked]>

>I believe that when an ASN.1 syntax is changed that includes a version field,
>then a new version number should be assigned to indicate the new ASN.1 syntax.

It doesn't really change it though, it just adds another option to the CHOICE.
I would hope that any software which works with these things would just skip
the unknown-tagged item (having said that my own code will reject it because I
tend to be overly pedantic in my checking, changing a constant and recompiling
will fix this behaviour).  On the whole I don't know whether changing the
version number will have any useful effect, because anything which rejects a
new CHOICE tag is just as likely to reject a new version number (any comments
from implementors?  If making either change will break apps equally then I'd
vote to leave the version number alone).

(Just for form's sake, I'll add my standard gripe that if we were using any
 kind of non-archaic ASN.1 you could just add '...' to the CHOICE and this
 whole issue would go away).

Peter.

---

From: "Pawling, John" <[email-masked]>
Date: Thu, 19 Apr 2001 17:07:56 -0400

Peter,

RFC2630 (and I assume son-of-RFC2630) references the 1988 ASN.1 specs.
Given that fact, adding the password-based encryption option to the
RecipientInfo CHOICE IS a change to the EnvelopedData syntax.  Not all
S/MIME implementations include the flexibility to skip unknown-tagged items
in a CHOICE.  For example, the S/MIME Freeware Library uses the Enhanced
SNACC Compiler and library to implement the S/MIME v3 specs.  The Enhanced
SNACC library will return an ASN.1 decode error if it encounters an
unknown-tagged item in a CHOICE.  I am sure there are other implementations
that would also return an error under those conditions.

Having said all of that, I retract my recommendation to assign a new value
for use in the EnvelopedData version field due to the addition of the
password-based encryption option to the RecipientInfo CHOICE.  I doubt if
many implementations check the EnvelopedData version value before attempting
to decode the hex data.  A new version number would have assisted with
debugging and error reporting, but it is probably not worth the effort to
change the specs and implementations to populate the new version value.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 19, 2001 4:17 AM
To: [email-masked]; [email-masked]
Subject: RE: S/MIME version number

>I believe that when an ASN.1 syntax is changed that includes a version
field,
>then a new version number should be assigned to indicate the new ASN.1
syntax.

It doesn't really change it though, it just adds another option to the
CHOICE.
I would hope that any software which works with these things would just skip
the unknown-tagged item (having said that my own code will reject it because
I
tend to be overly pedantic in my checking, changing a constant and
recompiling
will fix this behaviour).  On the whole I don't know whether changing the
version number will have any useful effect, because anything which rejects a
new CHOICE tag is just as likely to reject a new version number (any
comments
from implementors?  If making either change will break apps equally then I'd
vote to leave the version number alone).

Peter.