Oracle's e-mail address solution to the role problem seems very
reasonable, but may not be as extensible to PEM as it might at
first appear.
At present, I assume that your official answer givers are not
receiving encrypted mail, but I could imagine that if you had
a non-disclosure agreement for beta testing you might like
to receive bug reports, "nasty-grams" etc., using encrypted
email.
Have you thought about what you want to do about key
control? Do you intend to share keys?
Assuming that there is a one-to-one correspondence between
the people who can read that mail and those who can sign the
official answers, there is perhaps no great problem.
However, early in the PEM development effort I argued
unsuccessfully for separating the decryption keys and the
signature keys (and in fact using separate algorithms, but
that is a separate issue). My justification was that I might
want my secretary or someone I appoint as acting manager
to be able to read my mail while I am on travel or vacation or ill,
but I would not want them to be able to sign my personal
name, or even my role name. Even with a formal delegation
of authority, good business practices require that the individual,
not just a role, be held accountable for any official actions.
So my secretary or the acting manager should sign using their
own name, and perhaps say something to the effect "Forwarded
in the absence of Joe Blow to avoid delay, signed, Betty Boop,
Secretary to Mr. Blow." Unfortunately, if they can read my mail
they can also sign my name, so this becomes very awkward to
administer.
If I give my secretary my encryption key, I should somehow
indicate in my certificate that "This certificate is only valid
for encryption, not digital signatures."
On the other hand, the certificate that is used to validate my
digital signature should say "To be used for signature validation
only. Please don't send me anything encrypted in this key,
for otherwise my secretary or other people in the department
won't be able to read it. If you really mean for the information to
be personal and confidential, however, then this certificate is OK,
but in that case don't be upset if you ask for something and it
doesn't get done until I come back into the office."
On top of all that, I may want to send and receive personal
email while at the office. I'm a professional, and the Labor Department
considers me exempt the privilege of being paid overtime because I
may be thinking about a problem at any time, day or night. I may also
have to call in from home to retrieve mail or carry on business calls with
people in different time zone, so it seems only fair. Although some
companies grumble about delivering Christmas cards and other
personal mail, most allow it, and I would assume this would extend to
email as well.
So now I have to have a DN for personal mail that is received at the
office, and perhaps a different DN for personal mail that is delivered
to my house, plus the various "official business" DNs.
I claim that whether people like it or not, DNs are going to have to
contain a variety of role attributes that can be used to differentiate
between these various uses. There just isn't any other mechanism
that is currently available.
Every time I suggest using a multi-valued RDN to indicate these things
people tend to say "yuck", but unless we want to adopt an additional
certificate type right now, i.e., an authority certificate, for use with PEM,
I think we are stuck with such a solution. The alternative, of having
companies require that keys be escrowed like keys to offices and file
cabinets, is far worse, not only from the standpoint of personal privacy
concerns but also the possibility of fraud and/or impersonation.
So I can foresee something like the following being commonplace:
C=US, O=GTE, OU=GTE Labs,
{CN="Secure Systems Dept., Attn: R. Jueneman",
roleName="Valid for encryption only"}
and
C=US, O=GTE, OU=GTE Labs,
{CN="Robert R. Jueneman", Title="Mgr., Secure Systems",
roleName="For Company Confidential correspondence
and official signature use only"}
and
C=US, O=GTE, OU=GTE Labs,
{CN="Robert R. Jueneman",
roleName="Private and personal correspondence"}
Finally, I would certainly hope that we DO NOT adopt any particular
convention for assigning DNs based on email addresses, nor the
converse. Regardless of the role that I may be playing, I may want
to use a common mailbox for all of my correspondence, for it
is too great a nuisance to have to log on to mailbox after mailbox
every time my computer "dings" to indicate that more mail has been
received.
On the other hand, I may want to send all of my PEM mail to one mailbox
and all of my other mail to another, perahps becasue I want other people
in my group to be able to read the mail sent to me on one particular
subject.
The DN should be used to LOOK UP an email address in an X.500
directory, perhaps, but even then I may ask certain correspondents
to use one and give out another address to the rest of the world.
Unfortunately, although X.500 was originated by CCITT, they didn't
really think about the requirement for unlisted tleephone numbers, etc.
Bob