Well, I don't know how AlphaTrust does this, but one system I've been
involved with in the past works as follows:
- the directory mandates "strong authentication"; i.e., you have to
authenticate yourself cryptographically as part of binding to the directory;
- the directory enforces the policy that only people who have
certificates issued by an approved CA can query the directory. That is,
when you ask the directory for a certificate for user "Paul Hoffman", it
verifies via the strong authentication that:
- you possess the private key associated with a certificate
- that certificate was issued by an approved CA.
If you pass this check, the directory will search for the cert you want and
return it if it can find it.
- requests from other than approved users are rejected. If you
aren't already in my community, you don't get information from my directory.
Enforcement is via authentication to the directory; no matter who you claim
to be, if you can't authenticate using a cert from an approved CA, it's the
bit bucket for ya.
Then, the only people who can violate the policy on combing the directory
for email addresses to later be used for spam are your own users, and you
have their pledge - I hope backed up with the threat of legal action - that
they won't do so.
Bill, is that roughly how your system works?
-- As usual, this posting reflects my own opinions only, and does not
represent the opinions or policies of my employer or any other organization
with which I may have a relationship.
Graham Laws wrote:
Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to
encrypt a message to you, I would be able to find your public key
certificate, if the CA's directory entries are not open to the public ?
avoid cross-cert issues, lets assume we both belong to the same CA).
Are you assuming that correspondents will swap key files and use some
out-of-band authentication mechanism ? Or can your clients only gain
to the directory for searches, etc., by using their certificates, e.g. by
LDAPv3 TLS or SASL ?
The S/MIME requirement to place email address in the certificate severely
weakens the PKI model with regard to privacy, and will no doubt lead to
sorts of bespoke solutions for public Directories. I suspect this will
lead to many interoperability problems later.
From: Bill Brice (listserv)
Sent: 07 February 2000 15:54
To: 'Graham Laws'
Subject: RE: Problem for public CAs
As a US based public CA that incorporates EU Privacy and Data Protection
directives into our PKI, we have addressed this issue as follows:
1) Our Members give their permission, as required by EU law, to
common names and email addresses into their certificates.
2) Our Members pledge, as part of their Member Agreement, not to use
Members information for purposes such as spam.
3) Our directory entries are not open to the public, unless the Member has
to publish such information publicly.
4) Relying parties have agreed to respect the privacy rights of our
not to use personally identifiable information without the Member's
Such a solution is possible with a contractually-based public PKI such as
AlphaTrust. It is more difficult to implement with an enterprise model
or an open model (i.e. Verisign). But then that's why we exist - to solve
sticky issues of privacy, legality and transaction risk.
Food for thought.
Bill Brice, CEO
From: Graham Laws [mailto:lawsg(_at_)it(_dot_)postoffice(_dot_)co(_dot_)uk]
Sent: Monday, February 07, 2000 8:24 AM
To: 'SMIME IETF'
Subject: Problem for public CAs
For public CAs, particularly in Europe, the requirement to place an email
address in the subjectAltname extension of each x.509 public key
in order to enable S/MIME is a big problem.
Firstly, all such certificates must reside in a public Directory. Any
determined spammer is going to be able to easily create an immense spam
from the Directory's entire certificate population, using a few LDAP calls
and an ASN.1 decoder. Our customers are already nervous at the prospect of
this, and for potential customers it may be a significant bar to take-up.
Secondly, the European Privacy Directive looks very unfavourably upon
real-world identities being in any way expressed both in the Subject and
SubjectAltName attributes of the public key certificate. This would appear
to rule out S/MIME for those whose names are embedded in their email
addresses, e.g. graham(_dot_)laws(_at_)postoffice(_dot_)co(_dot_)uk
The issues raised by the second point are relatively easy to circumvent.
pseudonymous names for the Subject, and insist on a pseudonymous email
address if S/MIME is required.
But the first point about the ease with which spam lists can be created is
real worrier. I have looked through previous threads, including the one
entitled "Mail addresses in S/MIME certs", but I can't find where these
specific issues have been discussed before.
Comments/discussion via this forum welcome.
PKI Systems Technical Consultant
Royal Mail ViaCode Phone : +44 (0)1246-293761
Block A, 1st Floor Postline : 5453-3761
St. Mary's Court Fax : +44 (0)1246-293751
St. Mary's Gate
Public Key Validation String : MXZQ-7MM5-9A58