-----Original Message-----
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: Phillip Hallam-Baker <pbaker(_at_)verisign(_dot_)com>; ietf-smime
<ietf-smime(_at_)imc(_dot_)org>
Date: Monday, January 05, 1998 05:36
Subject: Re: CMS Critical flag for signed attributes?
All,
One of the primary requirements of the S/MIME v3 set of specs is to
maintain
backwards compatibility with the S/MIME v2 set of specs
snip....
John,
Let me stick my head above the parapet and be shot at ........
Why is a primary requirement of S/MIME v3 to be backwards compatible with
S/MIME v2? Surely the remit is to design a secure messaging protocol that
meets the majority of users requirements. This may or may not mean backwards
compatibility with S/MIME v2
If a firm requirement exists that results in a proposed enhancement to the
existing
specs that would make them incompatible with S/MIME v2, then that
enhancement must
never be thrown out just because its not backwards compatible. Surely this
is the whole
point of making S/MIME an IETF standard. If we find that we have
requirements that the
original S/MIME designers didn't foresee, we should not be constrained by a
design that
did not consider the requirement in the first place.
For example, why is there no extension mechanism, like X.509s, in
SignedData? 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.
Time to duck I think ........
Darren
smime.p7s
Description: S/MIME cryptographic signature