Kent's mail helped me refine my earlier position. I think
the answer to this problem is certificates issued for use
with S/MIME must have an Internet email address in them.
Otherwise it is difficult to understand what issuing a
cert for S/MIME use could mean.
This does not imply that a client be prohibited from using
a generic X.509v3 cert in conjunction with S/MIME, its just
that such certs cannot be considered 'S/MIME certificates',
should not be marketed as such etc.
The problem of using a different email address can occur in
two different ways:
1) The user acquires a new email address and the old one
remains usable.
2) The user acquires a new email address and the old one
is withdrawn.
I see scenario 1 as being something we need to address
with an authenticated header attribute and scenario 2 as
ineviatably requiring the revocation of the certificate.
The issue is whether someone can send confidential
information to the subject of the certificate. If there is no
email address they are not going to be able to use it for
S/MIME.
I am also wary of mandating the inclusion of Internet mail addresses in
certificates. From a PKI administration perspective, it is preferable
to keep application specific information out of certificates because
they incur additional burdens on the CA and his/her Registration
Authorities (RAs).
Only inrespect to certs to be used for email.
An RA will now have to obtain a user's email address, and for medium to
high assurance certificates, the RA would also be expected to validate
it (probably through the LAN Mail administrator).
This is one of the easiest identifications to check on the Internet
however. It it checked even in VeriSign class 1 certs.
Every time the user's
email address changes, the CA will have to revoke and re-issue the
certificate. Imagine how cumbersome certificate management would
become if all secure applications, e.g. secure fax, single sign-on,
required specific information in the certificates. The more generic a
certificate, the broader its use and the longer it lasts.
This is the real problem. But consider what happens if there is
no email address in the cert - you don't know how to contact the
person.
Secure fax sounds like a bogus application to me. How does it
differ from sending a TIFF of JPEG S/MIME attachment ? Similarly
single sign on requires an unambiguous machine readable
username, why should this be different from a person's email?
After all if single sign on means anything it means that a single
account gains access to both email and filestore.
I don't think that the plethora of identifiers is a problem because
there is only really one application.
Requiring S/MIME agents to check the email address in the 'from' field
against the one in the signer's certificate and provide 'alternate
processing' of the message, i.e. reject it, is overly restrictive. It
prevents a user, for example, from sending S/MIME messages from a
colleague's mail account while on a business trip.
I agree but the problem appears to be with the clients.
Authenticated data trumps unauthenticated. What is needed
is a secure means of saying 'i'm temporarily away from
my usual desk'.
i) mandating that the email address be an RFC-822 address closes the
door on future use of X.400 to transport S/MIME. If the email address
*must* be in the certificate, subjectAltName allows it to be X.400 or
RFC-822
Is this a bug or a feature? One could argue that making S/MIME
deliberately incompatible will speed the demise of X.400 :-)
Seriously though, I'm somewhat skeptical as to the value of
an S/MIME X.400 hybrid talking to the world at large to
start with but if we decide this is desirable we have to take
a more thorough approach. Simply refering to X.400 as
a tie breaker when corner cases come up strikes me as
pointless.
I don't want there to be any requirement for Internet clients
to deal with legacy email systems whether they be Decnet
phase VI, bitnet, Janet or OSI. This is no longer a current
standards battle. For better or worse SMTP is the email
dialtone of the Internet. Ergo if we require an email
address it has to be an RFC-822 email address.
ii) a question: for dual key pair architectures such as Entrust's is it
the intention to put the email addresses in both the signature
validation certificate and the encryption certificate?
I would say both.
Phill