[Top] [All Lists]

RE: The address-in-certs issue

1997-12-18 04:27:35
I, too, don't like the idea of putting e-mail addresses in

Why not use a PKCS #9 emailAddress attribute in the authenticated
attributes list of a signed message?  That way the address gets
included in the signature calculation, and the attribute value
is set on a per-message basis.


-----Original Message-----
From:   John Pettitt [SMTP:jpp(_at_)cybersource(_dot_)com]
Sent:   Wednesday, December 17, 1997 10:46 PM
To:     David P. Kemp; ietf-smime(_at_)imc(_dot_)org
Subject:        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 :-)


-----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
the identifier: it's up to the application using S/MIME
- S/MIME messages that are to be sent through SMTP MUST have the
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

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

 << File: smime.p7s >> 

<Prev in Thread] Current Thread [Next in Thread>