-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ
BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl
Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx
NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T
ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL
Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB
AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL
X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF
AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+
8lqrLQ7YpTzyE74pKR1cl5TAUU4=
MIC-Info: RSA-MD5,RSA,
ABe1MXuVNVQa2EvRwMTL+bUbAzprZ6FHulw3ltX/roTi47cp3WdBW09GOjYrYHzX
x6zAKT5NDO6XgppMBjc8dR0=
X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
To take a quote from Steve Crocker, who was talking about legal
non-repudiation, and use it for a different subject:
I already know that spock(_at_)rsa(_dot_)com is Steve Dusse and that
kent(_at_)bbn(_dot_)com
is Steve Kent. I know that from lengthy interactions over the net.
If their messages are signed, then I can be assured those messages
were not sent by anyone else.
I have been greatly puzzled by the X.500 DN debate. I don't believe that
anyone would consider either of SecureWare's implementations of PEM/MSP to be
in the "rocket science" category. In fact, the version I am using to create
this message (based upon the public domain "elm" user agent) doesn't provide
a graphical user interface and doesn't have access to a directory service.
(To keep our marketing types happy I should also mention that we have a
pretty slick Motif product supporting any combination of MIME, PEM, MSP and
multilevel security). The modifications to the existing mailer and its user
interface were not significant, and yet, I never have to type in a DN. In
fact, I hardly ever have to think about them.
How can this be so? Well, as Steve points out above, with few exceptions
there is a one-to-one mapping between email address, whatever format you
choose, and recipient. There is also supposed to be a one-to-one mapping
between the Certificate subject DN and recipient. This implies a pretty
good correlation between email address and DN. Our mailers simply extract
this information from received messages and store it in a database. (Yes,
they are sophisticated enough to map multiple email addresses to the
same certificate). Thus the user only need specify the recipient's email
address -- or better yet, use the built in address book with search
capabilities.
To prevent spoofing, only verified certificates can be cached. And whenever
the user takes some action implying trust in the binding between email
address and DN, (e.g. using the certificate to provide message
confidentiality, or explicitly deciding to trust a certificate that cannot
be verified for lack of an issuer certificate), the user is queried to
verify the mapping between email address and DN.
What does this mean from a user and administrator viewpoint? Well, in the
typical multiuser installation using the available PEM infrastruture :-),
the system administrator is required to take explicit action in order to
approve the loading of top level issuer certificates (PCA or CA) into the DB
- -- we use a multirooted trust model. We get along fine with just two such
certificates, our own, and the TIS PCA. In making the decision to trust a
certificate that cannot be verified due to a missing issuer certificate, the
adminstrator is presented with the subject's DN, the MD5 hash of the
certificate, and the subject's email address if available. He/she must then
use some out-of-band mechanism to verify the certificate, e.g. phone call,
certified mail, etc... This, and a couple of other nice touches, were
borrowed from Mark Riordan's RIPEM.
Normal users then see only minor differences in their standard mailer
interface. When viewing a message they see an indication of the security
services that were applied to the message, an indication of the signature
status, and the DN of the signer. They can see much more if they wish,
including full certificate chains, etc..., but there is hardly ever a need
for this information.
When sending an encrypted message, the user specifies the recipient
addresses as they would normally. The mailer uses its database to find
the certificates of the recipients, and then checks with the user to
make sure that the correct certificates were chosen.
This simple scheme works quite well, but relies upon two assumptions:
1) DN's are constructed such that they identify their recipient with little
or no ambiguity, i.e, when you see:
CN = Charles Watt, OU = Engineering CA, OU = SecureWare PCA,
O = SecureWare Inc., C = US
you have a high degree of faith that I'm on the other end.
2) That you can receive a signed message from someone before you need to
send them an encrypted message.
Neither of these assumptions is very restrictive (assuming that you are not
already stuck with a predefined set of nondescriptive DNs). They both
go away should we ever have X.500.
From my experience I would assert:
- The use of X.500 DNs as certificate subject names add very little
complexity to the user interface of a mail UA.
- Nor do they require a sophisticated infrastructure in order to
use them with PEM.
Charles Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----