Subject: RE: Mail addresses in S/MIME certs

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Wed, 22 Dec 1999 11:55:23 -0800

I am in complete agreement with Al.  I looked at this issue back when the
drafts were first getting started and I was just scared by the concept of
allowing more that I could reasonably verify into the RFC822 address field.
I had a chance as a mail program of looking at the RFC822 name, but not all
of the "comments" that go along with it.  While I agree that there may be
some issues for display of RFC822 names vs the comment fields that are in
messages, I think this is true no matter what is done and is more of a
presentation/application issue than a standard issue.  This is one of the
things that different applications will do well or not do well, but should
not really be part of the standard.  We have the ability to look at and
think about the RFC822 name (or what ever type of name is being used as the
delivery address i.e. an X500 name in the Microsoft Exchange Server world),
but have no way of doing any type of reasonable verification on the comment
sections.  Lets just leave things the way they are.

jim

> -----Original Message-----
> From: Al Arsenault [mailto:[email-masked]]
> Sent: Tuesday, December 21, 1999 6:50 PM
> To: Paul Hoffman / IMC
> Cc: [email-masked]
> Subject: Re: Mail addresses in S/MIME certs
> 
> 
> 
> 
> Paul Hoffman / IMC wrote:
> > 
> > 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
> 
> Count me in the 
> 
> "The many formats for the additional information are incredibly
> confusing and likely to promote lack of interoperability"
> 
> camp.  This, combined with the fact that that cruft is almost 
> infinitely
> changeable today, and almost never checked by anybody, seems 
> to me to be
> a sure guarantee of interoperability problems.
> 
> I don't have any philosophical objections to allowing this, 
> though, and
> if the S/MIME vendors are convinced that they can get it 
> right and make
> it all interoperate, I'm willing to be outvoted.  But it just 
> strikes me
> as begging for a failure to communicate.
> 
> 				Al Arsenault
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Dec 1999 13:02:58 -0800

At 11:55 AM 12/22/1999 , Jim Schaad (Exchange) wrote:
>allowing more that I could reasonably verify into the RFC822 address 
>field.  I had a chance as a mail program of looking at the RFC822 name, 
>but not all of the "comments" that go along with it.  While I agree that 
>there may be some issues for display of RFC822 names vs the comment fields 
>that are in messages, I think this is true no matter what is done and is 
>more of a presentation/application issue

Folks,

If one insists on specific semantics to the string(s) being used, then the 
task is probably difficult and all the stated fears are likely valid.

To the extent that the only real issue is ensuring uniqueness, then there 
are emerging enhancements to the RFC822 address string that might prove 
useful.

In effect the enhancement is retrofitting a schema template onto the 
mailbox (local-part) to the address.  The rough style is <key=str1/str2/... 
@domain>.  (Apologies for the shudders this no doubt engendered among those 
with an X.400 background.)  Also, there is still some flux in the work and 
so I could imagine that it will also permit  <str1/str2/...@domain> without 
the keyword preface.

The real point behind mentioning this is to suggest that you probably can 
choose to defer dealing with the issue, since it really involves matters 
that are larger than certs:  Things like shared mailboxes, roles vs. 
people, etc., need to be dealt with much more generally.  And they will be.

And it is looking likely that they will be dealt with in ways that will be 
compatible with (and transparent to) the current RFC822 address format.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA