John,
John Pawling <jsp(_at_)jgvandyke(_dot_)com> 01/06 1:33 pm >>>
I use the term "backwards compatibility" to mean that
it is possible to select the options and algorithms when
constructing an S/MIME v3 message such that S/MIME v2 agents can
successfully process that message, and vice versa. I did not mean
to imply in my previous message that "backwards compatibility" is
a silver bullet to shoot down any new proposal. However, when we
debate new proposals, I believe that we must consider the
backwards compatibility issue and design the specs to accommodate
that feature when possible. I believe that we have done an
excellent job so far of adding new features without breaking
backward compatibility.
I agree completely with you on this. So long as we keep the "when
possible" in mind, and don't get blinked we will get specs that
will be acceptable in all our environments.
Darren wrote:
For example, why is there no extension mechanism, like X.509s, in
SignedData?
IMHO, Phillip's proposal to define an attribute consisting of a
SEQUENCE of attribute-like structures each of which includes a
crticality flag meets that requirement.
I agree it does meet the requirement, as would redefining Attribute
as Attribute ::= SEQUENCE {
type ...snip...
critical BOOLEAN DEFAULT FALSE,
values ...snip... }
This would also be backwards compatible, and closer to X.509's
way of expressing criticality ;-)
Darren wrote:
Let's change the name to SIM (Secure Internet Mail) and get rid
of the reliance on MIME encodings and allow the passing of
arbitrary binary data.
That contradicts the S/MIME WG charter which states that the WG
will "define MIME encapsulation of digitally signed and encrypted
objects whose format is based on PKCS #7".
The reliance on MIME encodings that a meant, was the fact that data
has to be MIME encoded before it is protected using S/MIME, not that
the form that gets finally sent out is dependant in MIME - or am I
reading the specs incorrectly?
Darren