Boy, a lot of things have been bounced around when I was off for the holidays,
doesn't everybody take a vacation to some non e-mail reachable place?
From dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil Wed Jan 7 10:05:49 1998
The mandatory identifier syntax requirements for Internet Mail should be
that the CA is required to include at least one RFC 822 name and the UA
is required to be able to interpret and display RFC 822 names in an
intelligible manner.
*** <blink> Disagree </blink> ***
This is ISSUE3. The minimum S/MIME compliance requirement for CAs
should be that they populate the subject identifier in a form that can
be displayed by S/MIME-compliant UAs.
Agreed ...
If the resolution of ISSUE3 is that identifiers in a cert have no
S/MIME-mandated relationship to From:/To: addresses, then the form of
the identifier in a cert is not constrained except that it must be
displayable.
Well, the identifier in a cert, IMHO, must *not* have a *mandated*
relationship to From:/To: addresses. It is common-place to have the
certificate containing a RFC822 address as
"chen(_at_)cs(_dot_)toronto(_dot_)edu" and
the From:/To: address as something like
"chen(_at_)dvp(_dot_)cs(_dot_)toronto(_dot_)edu".
Well, we have multiple issues with dependencies between them. Can we
get agreement on JGM1 through JGM3 before tackling ISSUE2?
I agree with JGM1 - JGM3.
I think we all agree that the answer to ISSUE1 is "yes".
And the answer to ISSUE2 falls out once ISSUE3 is resolved.
ISSUE3 is the core. You and Jim Schaad have said essentially,
(quoting Jim):
1. It is my firm belief that all certificates should contain a name,
either as the subject name or as an alternate subject name that is in
the domain which is being dealt with application under question. As
S/MIME is specified primarily as an Internet Mail system, this would
imply that RFC 822 e-mail names should be present in a subjectAltName
extension.
That position sounds plausible on the surface, but when you examine the
premise on which it is based (ISSUE3), it falls apart. If you are not
prepared to mandate a relationship between identities and delivery
addresses, then there is no reason for S/MIME to require that the
domain of identities which are displayed to and understood by users
be identical to the domain of addresses to which Internet Mail can be
delivered.
Most of the contributors to this thread have demonstrated why it is
undesirable to mandate that 1) certs contain delivery addresses, or
2) there be any mandatory To:/From: checking requirements for UAs.
*If* a cert contains an identity that uses the same syntax as an
Internet Mail To:/From: address, and *if* the identity doesn't match
the address, then an S/MIME UA MAY take some unspecified action. As a
matter of good user interface design, not S/MIME-compliance, that
action should be configurable by the end user.
Agreed ... however, since S/MIME messages maybe transported over non
Internet Mail venues (such as HTTP), in which case To/From address
will not exist when the UA get to process the package. I would recommend
that the default action to be not enforced verification.
So again, what UA address-check-failure action are you prepared to
mandate in the S/MIME specification?
Since the S/MIME message specification does not explicitly stipulate the
mechanism over which the S/MIME packages are transported (such as SMTP
versus HTTP), I don't believe the S/MIME specification should mandate
any type of check failure action.
On a slightly different note, since S/MIME messages maybe transported
over alternative transport mechanisms, shouldn't the certificate also
potentially contain other types of addressing mechanisms? For instance,
if a S/MIME is to be delivered HTTP, then potentially the certificate
may contain a HTTP URL (following the argument that S/MIME certs *must*
contain a RFC822 name)? I am aware that this maybe outside the boundary
of this WG.
-- Chen Wang