John Pawling wrote:
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. PKCS #7 does not
include a critical flag in the Attributes syntax, so we need to consider how
this would be implemented without breaking backward compatibility.
Agreed.
One entirely backwards compatible method of doing this would be to
create
an OID whose attributes would simply be a list of critical extensions.
S/MIME v3 clients would be required to understand the OID semantics.
One
alternative would be to make the critical flag optional.
Then it would have no effect. The point of CRITICAL is that it provides
a single point of obligation.
The value of the
version number in the signerInfo SEQUENCE could be used to indicate if the
critical flag is being used. Assuming that the S/MIME v2 products examine
the version value, they could determine if they could decode the rest of the
signerInfo SEQUENCE based on the value of the version number.
This raises further issues such as:
1) How do sending agents determine if specific receiving agents can handle
the critical flag?
I don't think this can be guaranteed in an asynchronous protocol,
especially
since we are defining a message syntax and not a transport protocol.
2) What happens if a S/MIME v3 agent sends a signedData with critical flag
present and the receiving S/MIME v2 agent determines that it can't decode
it. How does the receiving agent communicate the failure to the sending
agent?
I don't think this is a critical problem. I understand the problems of
legacy software - I've been struggling for the past four years to
get minor corrections into HTTP that were suggested in 1993!
The reason for the critical flag is to provide a mechanism for
placing contract disclaimers. I would hope and expect folk who
are going to rely on contracts exchanged via S/MIME would
upgrade their clients.
One of the mistakes we made with HTTP was to underestimate the
rate at which browsers would become obsolescent. We failed to
kill HTTP 0.9 back in 1992 because there were 'hundreds' of
0.9 servers.
I think we should focus on the backwards compatibility problem
as 'old clients will not break', rather than 'old clients won't
become useless'.
I don't think the critical flag is a facility that will be essential
for a while, probably not for a couple of years or so. The reason
I am raising the issue now is that two years is the time it takes
for a positive expectation that a feature is supported can be
made.
Also I am proposing the critical flag as only one piece of a broader
contract processing infrastructure. In a corporate environment an
employee receiving a contract had better make sure it gets filed
somewhere a bit more accessible than their personal hard drive! I
would expect some sort of 'contract repository' to be an essential
part of the infrastructure I am anticipating. This is a point where
the infrastructure can raise the 'insufficient authorization' error
flag if no other.
The point I am making is that if this feature is to be supported at
all we have to have it in the base spec as a required feature. We
do not require the Version 2 clients to support it but we do draw
the line at V3.
Phill
smime.p7s
Description: S/MIME Cryptographic Signature