[Top] [All Lists]

RE: Protection of header elements in an S/MIME message

2005-02-02 08:26:59

From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jim 


MASS I think is going to fail because they are trying to 
solve the problem without upsetting anybody by adding some 

On the other hand we do intend to upset plenty of people by expecting list
serves to work properly.

The difference is context. The demand for cryptographic email security has
never been as widespread. S/MIME could not expect the rest of the world to
change. DK/IIM can.

I do not believe it is possible for MASS to fail, there will not be a MASS
until it is clear that the spec has been deployed.

Since MASS is not using S/MIME in any way shape or form, I 
doubt you are offending them.

I think that one of the big mistakes that has been made in email crypto
security (besides the S/MIME vs PGP war) is trying to combine signature and
encryption in one spec. This led to all sorts of restrictions that are
inevitable with encryption being pushed onto signature.

DK/IIM will provide a signature format and a policy layer, there is no
reason to go and repeat the work of S/MIME & PGP for encryption, just hook
the existing formats into the policy framework. The biggest hole in email
encryption schemes is the lack of a policy layer. Each time it is proposed
in the IETF someone wet blankets it by saying 'that's haaard', like so what?

So DK/IIM becomes a lower barrier to entry route for crypto secured email.
Once folk are signing at the domain level they will want to encrypt at the
domain level. Domain level crypto security will naturally lead to some
people going to per account level. 

I see DK/IIM as being a means of driving deployment of S/MIME encryption.
The only reason that I think we might not get to S/MIME is if we end up
going straight past it to DRM type formats which actually make a lot of
sense for messaging security. But that is not likely given the encumberances