Anders,
It's a helpful tool, not a requirement for S/MIME.
No one is required to use this.
If your CA don't have this info or it is not working with your client
structure, then don't use it.
It is however useful in a very large part of the enterprise use cases where
this is currently deployed without any problems. It helps avoid a lot of
uinnecessary occurances of bad 40 bit encryption in initial exchanges.
Stefan Santesson
Consulting Operations Specialist
Microsoft Security Center of Excellence (SCOE)
________________________________
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org on behalf of Anders
Rundgren
Sent: Thu 8/12/2004 10:34 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: I-D ACTION:draft-santesson-smime-scext-00.txt
I have no comments on the "design" in this draft.
However, I seriously question the idea to put client software
capabilities in certificates.
Why?
- because issuers may not have this information
- because users may have multiple clients
- because static solutions are limiting
If we begin to use dynamic methods like XKMS + DNS to find
public keys of recipients, SCEXT represents a step in another direction.
Due to the limited utility of true end-to-end encryption in corporate
environments (the DOMSEC RFC shows a few good reasons to that),
as well as the de-facto use of the web as a distribution medium for
e-government purposes (which is a much easier solution than S/MIME),
I believe that Microsoft should focus on making a gateway e-mail
standard a reality rather than patching a system that never will play
a major role and actually mostly creates problems for end-users and
system administrators.
Anders