ietf-smime
[Top] [All Lists]

RE: Problem for public CAs

2000-02-07 13:32:51
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?


                                Al Arsenault

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

Bill,
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 ?
(to
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
access
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
all
sorts of bespoke solutions for public Directories. I suspect this will
also
lead to many interoperability problems later.

Best Regards
Graham

-----Original Message-----
From: Bill Brice (listserv) 
[mailto:list(_dot_)bill(_dot_)brice(_at_)AlphaTrust(_dot_)com]
Sent: 07 February 2000 15:54
To: 'Graham Laws'
Subject: RE: Problem for public CAs

Graham,

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
incorporate
common names and email addresses into their certificates.
2) Our Members pledge, as part of their Member Agreement, not to use
another
Members information for purposes such as spam.
3) Our directory entries are not open to the public, unless the Member has
agreed
to publish such information publicly.
4) Relying parties have agreed to respect the privacy rights of our
Members
and
not to use personally identifiable information without the Member's
permission.

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
the
sticky issues of privacy, legality and transaction risk.

Food for thought.

Bill Brice, CEO
http://alphatrust.com

-----Original Message-----
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
certificate
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
list
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.
Use
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
a
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.

Best Regards
Graham Laws

______________________________________________
Graham Laws
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
Chesterfield
S41 7TD

Public Key Validation String : MXZQ-7MM5-9A58

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