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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Pawling,
John
Sent: Monday, April 16, 2001 10:26 AM
To: ietf-smime(_at_)imc(_dot_)org
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, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================