On Wed, 17 Dec 1997 Ed Gerck
(egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br) wrote:
-> -> 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.
In the context of the Canadian Federal Government, it is not the X.509
standard alone that binds the authentication trust model, but the
Certificate Policy (CP )and Certificate Practice Statements (CPSs) of
the CA that will make it legally binding.
Whether and how denotation 'is done by the NA" (Notary Authority), LRA
(Local Registration Authority) or some other agent of the CA, or the CA
itself, is determined by these policies. Therefore, "unless so warranted
by a particular CA", which will be the case for the Canadian
Government, an invalid DN or an invalid email address would make a
X.509 cert standard conforming but invalid as per the CP, and then would
not be created.
-> -> 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
->encryption?
Again, as defined in the CP, an X.509 authentication certificate does
not authorize anything.
All the authentication certificate does is give some degree of trust to
the binding of the information attribute values used in a certain
context to a unique, real life object in the world. Authority
certificates (X.509 v3) issued by particular authorities will grant
authorization to different real world objects.
Bill Aitken
Government of Canada
bill(_dot_)aitken(_at_)pwgsc(_dot_)gc(_dot_)ca
819-956-4850
----------
From: Ed Gerck
To: LancasterKent
Cc: ginsburg(_at_)mitre(_dot_)org; ietf-smime(_at_)imc(_dot_)org; CatleyBruce;
AitkenBill
Subject: re: draft-ietf-smime-cert
Date: Wednesday, December 17, 1997 3:26PM
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
choice.
-> 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
encryption?
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 ;-)
Cheers,
Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck
egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br
http://novaware.cps.softex.br