Frank,
A three way scheme is pretty complicated and raises some non-trivial
trust issues. Let <BC,k1> be a certificate which binds the
distinguished name (DN) BC to the key k1. In your scheme, this
certificate will be issues through the normal hierarchy by BC's CA.
Separately, a mail provider will bind <BC,k1> to a mail address, e.g.
bc(_at_)mx(_dot_)com, thereby creating an address certificate
<<BC,k1>,bc(_at_)mx(_dot_)com>. In your model, the address certificate would be
issued by whomever controls the mail host, i.e. mx.com.
What's to keep an unscrupulous host from issuing a bogus address
certificate? E.g., suppose blackflag.org issues
<<BC,k1>bc(_at_)blackflag(_dot_)org>. How will the unsuspecting user be
protected form misunderstanding that he should send mail to
bc(_at_)blackflag(_dot_)org instead of to bc(_at_)mx(_dot_)com?
This is only the beginning of the trouble. It's possible to escalate
this kind of mischief up to a full scale penetration, i.e. to the
point where the user uses the wrong key and sends mail to the wrong
person without knowing he's doing so.
It's important in these kinds of discussions to keep track of what
each party trusts. In the mail context, the use of email addresses as
a form of identity is common, so it's important to guard against the
introduction of bogus email names and bogus bindings of email
addresses to keys. The introduction of extended names like
distinguished names, may actually make it harder to follow what's
going on.
Steve
From: Frank Sudia <p00561(_at_)psilink(_dot_)com>
To: pem-dev(_at_)tis(_dot_)com
Date: Wed, 02 Mar 94 22:47:06 -0500
Subject: Addresses in Certificates (was Goals Review)
I have a suggestion regarding the relationship between long, unique,
descriptive subject names and network mailbox addresses.
Given that a user typically will not obtain her base certificate from
her e-mail provider, her (external) CA is in a poor position to certify
the correctness of her e-mail address, or verify that it isn't being
wrongfully claimed for some type of scam. Also, as has been noted, she
may wish to change her e-mail provider (e.g., due to service problems)
before her certificate's natural expiration date.
It seems to me that the proper trust architecture here would be to have
the organization that administers the address space issue an "address
certificate" separate from the base certificate, in which they assert
that "mail address" has been assigned to "long user name," -- signed
provider. Then, when she doesn't pay her bill and is dropped from the
service, the provider can just revoke the address certificate. This way
we decouple the troublesome data associations and put each certifier in
the business of certifying only what it really has control over. Of
course it will be trivial for the e-mail provider to verify the proper
name binding, as it need only demand that the applicant for an address
certificate sign their application using their principal identity key.
This is a species of attribute certificate which will be considered as
an element of ANSI X9's forthcoming work on authorization.
Frank Sudia
Bankers Trust Co.
------- End of Forwarded Message