Subject: RE: Problem for public CAs

From: "Graham Laws" <[email-masked]>
Date: Mon, 7 Feb 2000 17:03:56 -0000

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:[email-masked]]
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:[email-masked]]
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.  [email-masked]

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

---

From: HORII Naoto <[email-masked]>
Date: Mon, 07 Feb 2000 19:32:57 +0100

Item 3 would typically be implemented by restricting the type of questions a client can ask to the CA:

1) S/MIME certificates would be returned only if the subjectAltname is unambiguously specified - e.g.

client: search certificate for subjectAltname=[email-masked]
server: OK, certificate=blah

client: search certificate for subjectAltname=[email-masked]
server: ERROR, inavlid search key

For such a protection scheme to work, your directory server must obviously be able to validate/
sanitize a search key against access rules — e.g. "no wildcards allowed in search keys" — before
forwarding the search to your directory's backend engine.

2) Certificate revocation status would be returned only for explicitly specified serial numbers:

client: search revocationStatus for serialNumber=12:34:56:78:9a:bc:de:f0
server: OK, revocationStatus=false

client: search revocationStatus for serialNumber=12:34:56:*
server: ERROR, inavlid search key

Note that to prevent a trivial exploration of the certificate space by a spy intent on
determining the number of certificates issued by a particular CA, the certificate's serial
numbers should probably be derived from a hash of the Subject's data.
A 64- or 80-bit long hash would give a serial number space large enough to prevent brute-
force scans of the CRL subtree, while yielding serial numbers small enough to be accepted
by most X.509 implementations.

Cheers,
Naoto