ietf-smime
[Top] [All Lists]

re: draft-ietf-smime-cert

1997-12-17 10:17:20
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).

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

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.  As Elliot noted in
his message, what is important is that the message content has been
signed by its originator, not what mailbox the content came from.  I
realize this does not prevent 'spoofing' but who cares?  As long as you
can validate that the content was signed by the originator and has not
been tampered with why would you be concerned if it came from the user's
true and correct mail address or not?  Given the current trend to
increase PKI portability via PCMCIA hardware tokens and smart cards,
tying S/MIME users to their email addresses decreases portability.

Two other points:

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

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?

Kent Lancaster
Government of Canada
kent(_dot_)lancaster(_at_)pwgsc(_dot_)gc(_dot_)ca
819-956-4866

 ----------
From: Elliott N Ginsburg
To: ietf-smime(_at_)imc(_dot_)org
Cc: ginsburg(_at_)mitre(_dot_)org
Subject: re: draft-ietf-smime-cert
Date: Tuesday, December 16, 1997 2:48PM

There are several issues to be addressed in this draft:
1) Should there be mandatory processing of email addresses in
certificates
2) The processing descriptions must recognize that not only do receiving
agents process certificates during signature validation, but sending
agents process certificates used for encryption.
3) The current PKIX profile recommends that subject, if not null,
contain a Directory Name; and that an email address, if present, be in
subjectAltName.


Rather than require an email address in the certificate, and require the
matching of the email address and header information, I think that when
a signature is declared valid, it is essential to present the owner
names bound into the certificate, because it is from the certificate
owner that the message originated,
regardless of what is in the header of the message. This allows the
choice of how to
present the owner name in the certificate, where email address is only
one of the possible choices.

I recommend that the end of section 3.1 should read something like:

<snipped>

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