And another de-lurks (apologies in advance for the length)...
I won't offer my opinion on the S/MIME technical issues, but perhaps I can
cast a bit of light on some of the operational requirements driving this
discussion. In the military, you have a definite concept of an
organizational role which has to do with the command structure. That role,
perhaps "Base Commander", is stable. However, the personnel who are
responsible for that role come and go. Much official correspondence is sent
and received by this role. Let's say that Col. Smith is currently filling
the role of "Base Commander". When he sends an official notice as the Base
Commander, it should be signed by that role - not the individual person,
Col. Smith.
The plot thickens when you realize that "Base Commander" probably has a
half-dozen people who are authorized to read messages addressed to the role,
and at least 3 or 4 who can send official messages signed by that role.
Typically, Col. Smith would draft a message and forward it to a Duty Officer
(or secretary) who would "release" it under the authority of the Base
Commander (ergo, the concept of an "Organizational Release Authority" shared
by several people). And, if Col. Smith is TDY, you can bet that Lt. Col
Jones, the Duty Officer, and the base Messaging Center can all read messages
addressed to the Base Commander.
Remember, however, that Col. Smith also has an identity of his own. If
Brig. Gen. Brown wants to send over an itenerary for an upcoming visit that
includes dinner, golf, and drinks afterward - he would probably send it to
Col. Smith, not "Base Commander". Also, just to confuse things, you might
want to send an "eyes-only" type of message to the Base Commander, which
could ONLY be read by Col Smith (or whomever happens to "own" that role at
the time).
So what you have, in data structure terms, would be a network of one-to-many
relationships. The Base Commander role is "owned" by Col. Smith. There are
a set of individuals who are allowed to read messages addressed to this
role, in addition to Col. Smith. There are also a set of individuals who
are allowed to release messages signed by this role. These two sets may not
be, and in fact usualy are not, identical (e.g. the Messaging Center could
read a message to this role, but couldn't release one from this role). Each
individual, by inference, could be part of any number of these role release
and/or reading lists. For instance, the set of people authorized to work in
the base messaging center might be authorized to read messages addressed to
darn near every "role" on base.
Adding to the confusion - any individual could also be an e-mail
administrator, network administrator, directory administrator, security
officer, etc, etc, etc. Each of these is an additional role - defined by
function, not necessary by command structure.
Believe it or not, the above description is exactly what the Canadian
Department of National Defence will have to sort out in order to deploy
their classified Military Message Handling System (MMHS). So, these are
actual, real-world operational requirements that need to be met by S/MIME.
By the way - the security will be based on Entrust, which adds a whole
'nother level of complexity. But (as they say) that's another story, for
another day.
Bob Johnson, NEXOR
-----Original Message-----
From: owner-ietf-smime(_at_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)imc(_dot_)org]On
Behalf Of Walter Williams
Sent: Tuesday, December 21, 1999 11:34 PM
To: John_Payne; Frank W. Nolden
Cc: ietf-smime
Subject: RE: Mail addresses in S/MIME certs
Another lurker jumps into the ring.....
This begs the question: do certificates identify an individual or a role?
There is no effective way for a single certificate to do both.
A second question becomes are certificates appropriate for role
definition?
Certificates are usually valid for a span of years. My role changes
constantly, who I am never really has. Role definition might be best left
to other objects within a public key infrastructure, such as a directory
leaf entry as an example. After all, certificates, while
important, do not
a pki comprise. The important thing to get right, and this is process not
technology, is that the email alias is mine, not ours, if you catch the
drift.
Walt Williams
GTE Internetworking
-----Original Message-----
From: owner-ietf-smime(_at_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)imc(_dot_)org]On
Behalf Of John_Payne(_at_)motorcity2(_dot_)lotus(_dot_)com
Sent: Tuesday, December 21, 1999 11:59 PM
To: Frank W. Nolden
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Mail addresses in S/MIME certs
Sorry, I am also new to this thread.
Where are we going here?
A certificate ties a group of attributes (in this case the
Subject Alternate
Identity of RFC821(or 2)
address to public key).
Should we be looking at some other binding?
Surely in the case described the alternate identity should be some form of
Role
or MailingList. More than one
identity using the same MailingAddress completely blows
non-repudiation out
of
the water unless there is
some (out of scope?) work flow process or role identity
"Frank W. Nolden" <frank(_dot_)nolden(_at_)maxware(_dot_)nl> on 12/21/99
10:58:19 AM
To: ietf-smime(_at_)imc(_dot_)org, Paul Hoffman/ IMC
<phoffman(_at_)imc(_dot_)org>
cc: (bcc: John Payne/CAM/Lotus)
Subject: Re: Mail addresses in S/MIME certs
Dear All,
I would see it as follows (but then again I am very new to this discussion
and maybe I am completely off track):
When two people are using the same email address, the email
address is used
as a role which can be filled by more than one person. In this case there
will be a certificate for the role and certificates for each person. The
certificates for the people will be used in private (or mail sent on
personal title) situations, while the certificate for the role
will be used
in correspondence for this role only.
This means that both persons can have two certs, i.e. one for the role and
one for themselves, and each of these certs has to be stored in a separate
account or something like that.
When it is used on this way there is no problem when having the
informational stuff in the subjectAltName.
Regards,
Frank Nolden
MaXware Benelux BV
----- Original Message -----
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
To: <ietf-smime(_at_)imc(_dot_)org>
Sent: Monday, December 20, 1999 22:35
Subject: Mail addresses in S/MIME certs
At the DC IETF meeting, Bob Jueneman brought up the issue of different
certs for the same address. For instance, two people might use one email
address and thus want different certificates. The current
S/MIME and PKIX
specs allow the email address, not the informational kruft around it, in
the subjectAltName for a cert.
Do we want to change this? The arguments we heard against this
in the PKIX
group included:
- A CA might check the validity of the email address but not the name
- The many formats for the additional information are
incredibly confusing
and likely to promote lack of interoperability
The arguments in favor of using full addresses include:
- Ability for multiple people with access to the mailbox to have unique
certificates
- Increased identification for systems that do more than just check the
mailbox
Comments?
--Paul Hoffman, Director
--Internet Mail Consortium