Re: Problem for public CAs

[HORII Naoto <Naoto.Horii@xxxxxxxxx>]

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

client: search certificate for subjectAltname=*@it.postoffice.co.uk
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


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.bill.brice@xxxxxxxxxxxxxx]
> 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@xxxxxxxxxxxxxxxxxxx]
> 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.laws@xxxxxxxxxxxxxxxx
>
> 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