[Top] [All Lists]

Re: Problem for public CAs

2000-02-07 11:30:07

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 
server: OK, certificate=blah

client: search certificate for 
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.


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 ? (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

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

-----Original Message-----
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 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
to publish such information publicly.
4) Relying parties have agreed to respect the privacy rights of our Members
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

-----Original Message-----
From: Graham Laws [mailto:lawsg(_at_)it(_dot_)postoffice(_dot_)co(_dot_)uk]
Sent: Monday, February 07, 2000 8:24 AM
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
S41 7TD

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

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