Re: The address-in-certs issue

The issue is we don't want addresses in certs because it shortens their
life, but we need some authenticated way of knowing how to reply to whoever
sent the mail and real names are not unique.   The 822 headers are outside
the hash and get screwed with by all and sundry.

Perhaps what we need is reply to or originator info inside the hash but not
in the cert.  That means you can be sure that the sender intended that
address to be in the mail and the sender can change address at will without
needing a new cert.  (I'm having a strong urge to duck and run for cover
after saying that :-)

John

-----Original Message-----
From: David P. Kemp <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: Wednesday, December 17, 1997 11:29 AM
Subject: Re: The address-in-certs issue


> > From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
> >
> > I propose the following:
> >
> > - There will be no base-level interoperability statement for the content
of
> > the identifier: it's up to the application using S/MIME
> > - S/MIME messages that are to be sent through SMTP MUST have the
identifier
> > be an RFC822 email address, and any cert that goes with that message also
> > MUST use an RFC822 email address
> Paul, the content of the cert is the crux of the issue.  I agree with the
> many recent comments that email addresses should not be required or even
> recommended in the cert at all, irrespective of any S/MIME User Agent
> requirements.
>
> Reasons include 1) the more information that goes into a cert, the shorter
> the expected lifetime, 2) additional burdens on CAs/RAs to validate email
> addresses (in cases other than the zero-assurance certs which are issued
> to email addresses, not people), and 3) it's not clear that the user agent
> can do anything at all useful with an email address in a cert, given that
> users should be allowed to change addresses, mail authenticated messages
> from a friend's account, etc.
>
> One topic that came up on the PKIX list many months ago was the use of
> RFC822-style strings as identities.  It is quite reasonable that some
> people might find RFC822 names to be more comfortable than DNs, and it
> might even be reasonable for CAs to issue certs to RFC822-style identities,
> whatever it means to certify something like that.
>
> But an RFC822 identity is a completely separate thing than an SMTP delivery
> address - there are forwarding services now that let you keep the same
> identity regardless of how often you change ISPs.  Doing any sort of
> checking of an SMTP delivery address against an RFC822 identity, if it
exists,
> will often be futile (more than one account, kiosks/friend's account/IETF
> terminal room, address-munging gateways/listservs, etc).
>
> Requiring or recommending the existence of an RFC822 identity in certs
> solely for the purpose of enabling a check against a totally volatile
> delivery address is not warranted.
>
> Dave Kemp

smime.p7s
Description: S/MIME cryptographic signature