Subject: Re: Mail addresses in S/MIME certs

From: [email-masked]
Date: Tue, 21 Dec 1999 23:59:04 -0500

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" <[email-masked]> on 12/21/99 10:58:19 AM

To:   [email-masked], Paul Hoffman/ IMC <[email-masked]>
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 <[email-masked]>
To: <[email-masked]>
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
>
>

---

From: "Walter Williams" <[email-masked]>
Date: Tue, 21 Dec 1999 23:33:33 -0500

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: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Tuesday, December 21, 1999 11:59 PM
To: Frank W. Nolden
Cc: [email-masked]
Subject: Re: Mail addresses in S/MIME certs

 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

Dear All,

Frank Nolden
MaXware Benelux BV

----- Original Message -----
From: Paul Hoffman / IMC <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 20, 1999 22:35
Subject: Mail addresses in S/MIME certs

mailbox

---

From: Dean Povey <[email-masked]>
Date: Wed, 22 Dec 1999 16:32:47 +1000

>technology, is that the email alias is mine, not ours, if you catch the

Certificates identify whatever you choose to identify.  Certificate 
Policies specifiythe meaning of the naming in the cert.

Attribute Certs are better for dynamic things like roles, as they allow you
to separate the management of the role/credential/attribute from the
management of the key.  An attribute cert is rather like a normal 
Certificate but does not contain a public key (although it does contain a 
pointer to it).

Unfortunately there is not a lot of support in vendor products yet, but
they will get there eventually.

---

From: Bob Johnson <[email-masked]>
Date: Wed, 22 Dec 1999 07:36:21 -0500

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

> 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
>
>

---

From: "Bert Stals" <[email-masked]>
Date: Wed, 22 Dec 1999 16:17:53 +0100

It seems to me that identity and responsibility are mixed. A serious
problem with certificates is that they say who you are, not what you are
responsible for. No-one can determine from my certificate whether I'm
authorised to represent my company. And even when my certificate would
say "managing director" that still doesn't have to mean I can take all
decisions on my own.

	Regards,
		Bert

> Behalf Of Bob Johnson
> Sent: woensdag 22 december 1999 13:36
> To: Walter Williams; John_Payne; Frank W. Nolden
> Cc: ietf-smime
> discussion.

[rest deleted]