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.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz]
Sent: Wednesday, April 18, 2001 10:41 PM
To: John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com;
ietf-smime(_at_)imc(_dot_)org
Subject: RE: S/MIME version number
"Pawling, John" <John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com> 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.