On Tue, 23 Dec 1997, David P. Kemp wrote:
-> If we agree that relatively long-lived stable identities are a goal,
-> and that accommodating environments where mail can reach a given user
-> by multiple and occasionally or frequently changing addresses is also
-> a goal, then we can't reach both goals by putting all the delivery
-> addresses into a cert.
->
David and list:
IF we agree that:
1. A long-lived certificate should live one year (I can supply supporting
data if needed, while some might even want to assume a smaller lifetime),
2. An e-mail address may live one year in the owner's reference frame,
with its death being determined by job change over, ISP change over, spam
overfill, etc. (admittedly, I lack data here but judging from all my
e-mail contacts in 8 years, I can remember only one address that lived
less than one year in the owner's reference frame),
3. An e-mail address may live much less in a recipient's reference frame
(as given by a Poisson distribution) but this is not important because the
recipient can of course receive a new certificate from the owner (sender)
in several ways at any time, such as a routine message of e-mail change
with the owner's new address, as a request, etc.,
4. An e-mail address may not be used so often by an entity in its own
reference frame but may still live and so be useful to reach the same
entity from the recipient's reference frame,
5. Under X.509, the e-mail field may be invalid but the certificate is
still valid if the e-mail is NOT the DN (as it should NEVER be),
6. An invalid e-mail field in a valid X.509 cert is at least as useful as
a null e-mail field in a valid X.509 cert (maybe more useful, because if
you learn that Bob Jones is not any more at bjones(_at_)ibm(_dot_)com then you
may
need to talk to someone else at IBM),
7. S/MIME primary motivation is to secure e-mail and e-mail depends on
e-mail addresses,
THEN
we should agree that including the e-mail as a referenced field in a X.509
cert is at least as useful as not including any e-mail, while it can be
very useful if the e-mail is correct and valid (which is the expected
behavior within a cert's lifetime in the owner's reference frame).
THEREFORE, I suggest (exact STD wording not my goal here, just concepts):
The e-mail field as quoted in the "From:" field MUST always
be verified by the receiving MUA against a correspondingly named field
in the certificate, where the certificate may be supplied with the message
or read from a local file, cache, etc. The same applies to the "From"
field. If the e-mail uses S/MIME services then two cases of warning MUST
be provided by MUAs, for each of the two fields, for any sender:
(i) if the recipient allows uncertified e-mail addresses to be used in
that field and the corresponding certificate field is "NULL", the
receiving MUA MUST NOT detect any discrepancy in that field,
(ii) if the recipient does NOT allow uncertified e-mail addresses to be
used in that field and a discrepancy is detected, the receiving
MUA MUST add a warning message to the recipient by inserting it as a
first block in the message body itself, where the message MUST clearly
indicate the discrepancy and the two field values.
Further, in case of (ii) and if so desired by the recipient, the MUA MAY
bounce, delete or otherwise process the message (forward, store, parse,
etc.) as a function of the corresponding field values.
(Note that S/MIME services includes current services such as
signing/encryption as well as future services)
This suggestion would allow e-mail addresses to be effectively used in
S/MIME, while still allowing no e-mail address to be used (NULL). This
would solve the issue for all the needs/restrictions posted in this list.
Cheers,
Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck
egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br
http://novaware.cps.softex.br