RE: email address and signed operations

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

I think it is a bad move to tie or mandate ones email address to ones
certificate in the alt name - because - my name might be 
Alan Org = xyz C = AU but my email address is compuserve, ozemail, msn
or anything else.
Mail addresses deal with service based domains for routing messages
which can be totally different to real life named entities which are
represented as objects in a distributed directory system. In addition,
what does the client software do with this alt/mail name.. via some
preconcieved knowledge - locate something - by what means, http, smtp,
ldap.. etc. In what order does this occur? and by what privilege and
what (for the client software design process) algorithms.

Its easy to "add a name field" to anything .. whats the context, admin
and operational requirement?


In addition let me propose a vision that might help this process. (or
get me ignored for the next few years :-) )
Let us say that we (3rd rock from the Sun) have a distributed directory
system for many domains of interest (eg. banks, defence, libraries,
travel and transport, telecommunication and internet services etc) - and
that such directory systems are capable of having entries (as objects)
that can be gigabytes (ie. contain movies, documents, image, voice, etc)
and that one attribute (be it a complex one) is a Users mail box. And
directories via matching rules and "additional" processes (cert
validation, mail reply, etc) permitted Users who are authenticated on
the directory system in question, "drop email, documents, faxes, etc"
into ones directory object/mail box... by the dragging of an icon  (a
mail message or document) on a browsed system.

This future - object oriented/ name based approach of directory services
would render many mail system approaches obsolete. But is it really
futuristic - we do this locally on our servers today.
Just thoughts...

I think its very bad to mix real name things as per the directory with
service based names of email systems. and then build client software
that institutionalises this that may be able to deal with either/or name
forms in a yet to be defined system context. That direction strikes me
as problematic.

regards alan
----------
From: Bruce Greenblatt
To: Vesna Hassler; ietf-ldapext@netscape.com
Sent: 10/13/98 1:51:20 AM
Subject: Re: email address and signed operations

Vesna,

This is a very good point.  The S/MIME version 3 drafts no longer
require
certificates to have email addresses.  Section 2.2 of the cert handling
draft says:

"Receiving agents MUST support PKIX v1 and PKIX v3 certificates. See
[KEYM] for details about the profile for certificate formats. End
entity certificates MAY include an Internet mail address, as described
in section 3.1."

The interesting text from section 3.1 is:

"Receiving agents MUST recognize email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the
Distinguished Name field."

For the purposes of the signed operations draft, what is a "receiving
agent"?  I believe that it is any LDAP client or server that tries to
verify the signature of the entries in the signed audit trail...

Bruce

At 02:04 PM 10/12/98 +0100, Vesna Hassler wrote:
>Hi,
>
>RFC2312 mandates the use of email address in an S/MIME certificate.
>Is it also the case for the "Signed Directory Operations Using S/MIME"?
>If it is, it should be important to have RFC2312 as a reference
>in the sigops draft.
>
>However, I don't think it's a good idea to mandate the use of email
address
>for directory applications, since there are cases in which not all
>certified subjects have an email address (e.g. bank customers).
>
>Could the sigops authors comment on that? Thanks.
>
>Vesna
>
>
================================================
Bruce Greenblatt              bruceg@innetix.com
http://www.innetix.com/~bruceg
================================================