RE: email address and signed operations

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

Oh I see. Are you promoting 2 algs per cert one for sig verification and
one for confidentiality? or is the same cert/alg used for both.
I am not sure why one wants email addresses in certs used in dir signed
operations - is that something a directory will do .. ie.  email the
client about something ... from DSA@machineroom.com.. Dear client, I
have rxd your signed LDAP request, unfortunately I will return a
referral shortly... :-) 
What happens if the email address is not there. Does the client or the
DSA make a directory request to the Users entry for their email
address..
What if they only have a phone number?

Adding fields to objects seems a simple thing to do. But where is the
process model for this, what are the operational scenarios and options??
Who wants it..

As for defects on PKIX and X.500 - I was horrified when that was added
(ie. the choices of address forms, because there was very little
qualification to it, let alone any system scenarios from an operational
perspective or a process model re the options and the fall back issues..
This is a bit similar to the signed LDAP things.

Anyway I still like my vision of a directory attribute as a mail box
where users can drag messages into it - and mail protocols becoming
obsolete. In addition I still like X.500 signed operations simply
because they dont need a messsaging infrastructure to make choices
about.

Perhaps X.500 is getting simpler and better by the day ... and thats
good!

regards alan



----------
From: Bruce Greenblatt
To: ietf-ldapext@netscape.com; Alan Lloyd
Sent: 10/13/98 5:24:09 AM
Subject: RE: email address and signed operations

Alan,

In the context of an X.509 certificate an email address that appears in
the
subject alternative name field has been signed by the issuing CA. This
is
an indication that the CA has in some since verified that the email
address
corresponds with the public key that is inside the certificate.  Thus,
the
email address in the certificate is strongly bound to the "owner of the
public key".  I.e, if I trust the issuer of the certificate, and I can
verify the thing that the was signed by the owner (i.e. the signed
directory operation), and the certificate includes an email address
inside
the PKCS #7 envelope according to the S/MIME specifications, then I can
have a reasonable level of confidence that email address belongs to the
signer.  Furthermore, I can now send an encrypted message to this email
address, and have the belief that the recipient has the private key
corresponding the certificate in the signed directory operation, and he
can
then decrypt the message.

I don't think that your points have any relevance to the signed
operations
draft.  If you have problems with the inclusion of email addresses in
certificates, please address those issues either to the PKIX WG or to
the
X.500 defect editor.

Bruce

At 02:36 AM 10/13/98 +1000, you wrote:
>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
>================================================
>
>
================================================
Bruce Greenblatt              bruceg@innetix.com
http://www.innetix.com/~bruceg
================================================