ietf-smime
[Top] [All Lists]

RE: The address-in-certs issue

1997-12-18 07:06:50
John Pettit said:

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 would like to second that suggestion.  Firstly because as has been observed 
there are many good reasons not to mandate putting an  822 address in a 
certificate.  Secondly, IMHO the address is something which should be 
associated with the *signature* not the *certificate*.  I.e. there are several 
reasons to want to sign something.  Only one of them is that I want to be the 
authenticated sender of the E-mail.  Another is that I want to claim ownership 
of the data (but not send it out as an e-mail). A third is that I want to 
parallel sign the content but not be implicated as having sent the mail.  There 
are probably several more.

A neat solution would be to define another authenticated attribute, something 
like 'signature reason', which would be some kind of enumerated type.  Reasons 
could be 'Authenticate E-mail sender', 'Authenticated data', etc.  Depending on 
the reason, other attributes would be included in the signature.

Without this, I could envisage a situation of having S/MIME signed a local file 
for my own private purposes, and someone sends it off in a mail, followed by an 
interesting non-repudiation debate...

Tim

-----Original Message-----
From:   John Pettitt [SMTP:jpp(_at_)cybersource(_dot_)com]
Sent:   Thursday, December 18, 1997 3:46 AM
To:     David P. Kemp; ietf-smime(_at_)imc(_dot_)org
Subject:        Re: The address-in-certs issue

 << File: smime.p7s >> 
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



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