ietf-smime
[Top] [All Lists]

RE: Problem for public CAs

2000-02-07 10:05:40
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>