[Top] [All Lists]

re: draft-ietf-smime-cert

1997-12-17 13:24:03
On Wed, 17 Dec 1997 Kent(_dot_)Lancaster(_at_)PWGSC(_dot_)GC(_dot_)CA wrote:

-> 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 e-mail is not an application-specific information. As we all know,
e-mail names can be (and are) used in several different contexts (such as
anon-ftp, http POST command, etc.) An e-mail is a " name"  such as the
Social Security Number (which you use when the bank requires it in order
to identify your money transfer -- which has nothing to do with Social
Security purposes) or your Driver's License (which you may use to
clear a check in a CD store, even if the Driver's License has expired -- 
after all, you are still you). 

The advantage of e-mail names (which can easily be globally unique) is
that it can provide for a challenge-response method in an easy way. For
example, when you receive an e-mail confirmation of an order, which
provides the PIN to retrieve the order.

Combining such protocol-based challenge-response with cryptography-based
tokens is a natural use of S/MIME, because it provides the user with a

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

This is simply not true. Certificates (such as X.509) carry fields which
are just "copied as received' by the CA and have zero semantics. In fact,
X.509 only mandates that the public-key be verified by the CA, whereas the
DN is accepted by the CA but not denoted by it (this is done by the NA).
So, unless so warranted by a particular CA (such as Verisign, in a given
cert class and under given liability limits) the e-mail field is copied as
is and means nothing more than that: a reference. An invalid e-mail would
certainly not make a X.509 cert invalid -- nor unuseful. 

-> The more generic a
-> certificate, the broader its use and the longer it lasts.

No, the less it can be used for. Following your example, imagine a cert
which only has the subject's public-key and DN. What does it authorize? 
How to contact the subject? Is that key useful for signing or for

Further, clearly, a cert without e-mail address can be beautifully used in
a denial-of-service attack -- that's why PGP included an e-mail field.

After all, if send you my key-cert, tamperproof, and my e-mail, in
plaintext, I am just divorcing purpose from attitude.

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

This is not axiomatic. The mailbox whence it came provides for
accountability and may provide hints on possible interference, delays,
replays, etc.

For example, if you receive an e-mail from Clinton as sent by Khadaffi's
e-mail agent -- what would you think of it? Or, from a GM engineer as sent
from a VW e-mail agent? 

Further, there is a common misconception that security must always be
"perfect" as provided by cryptography -- with its costs. However,
oftentimes, all one needs is an assurance that miscreants will be caught
with a certain probability level. In an Intranet, such assurance might be
sufficient for day-to-day activities (with a properly secured server). If
more is needed, then the key may be used. Again, the user should be able
to choose.

 -> 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?  

As above. Note also that the fact you can validate its originator and
contents by the signature, does not mean that you can trust the clock used
in that host, or its msg delay, or its hidden forwarding. Which may render
the message totally useless for several purposes.

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

I find your phrase difficult to accept on three counts. First, tokens do
not increase PKI portability -- they increase key security. Second, no one
is tied to an e-mail address and the current trend is to have several
addresses. Third, one of the purposes of S/MIME was (or is) to secure
e-mail messages -- so, this means that if S/MIME does not allow that then
something else will (because there is a need).

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

Whatever X.400 turns out to be ;-)


Dr.rer.nat. E. Gerck                        

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