I would like to suggest an additional item for the charter. Currently
there is no support for addresses that are role based (ie
support(_at_)company(_dot_)com). Here are some examples of problems that need
Suppose there are ten people who need to read mail sent to
support(_at_)company(_dot_)com, how would this be handled without sharing the
private key, which for this example is prohibited by policy. As well any
of the ten support people need to be able to send messages that can be
verified as being from the individual sender and that the sender is a
member of the support role.
Also suppose the CEO of a company is on vacation and he wishes his EA to
check his mail. But the CEO's mail is not encrypted for his EA and he
doesn't want the EA to have access to his personal email that is
encrypted for the same address. As well the CEO wants to delegate his
CEO signing authority to the COO for the duration of his vacation.
Another feature the CEO wants is the ability to have his secretary draft
and address messages for him that he can later sign (without cutting and
The above situations are most elegantly solved by defining S/MIME
extension(s) and a standard set of role attributes that support the
concept of role based messaging. By adding extensions to S/MIME to
support "draft messages", role signing authorities, and private
role-owner only messages, email developers will be able to create more
flexible mail solutions for large corporate and government users. Work
in PKIX on attribute certificates can be used for the role attributes
and support the delegation of role authority.
Therefore I recommend that the smime WG charter include the
investigation of S/MIME extensions to support role based messaging and
standardization of role based messaging attributes and certificates that
are compliant with the attribute certificate work being done in PKIX.