Proving membership online

If you’re a member of some organization, or have some certification that entitles you to sign up for services somewhere, you need to be able to prove that you have that credential somehow. In real life, you’d carry a plastic card issued by a reliable organization and that you could flash in the face of whomever needs to see it. But how do you do this in the Etherworld?

To get started, assume you have a login account on a certain site that provides you with your legal status or license. If you can login to that site, you are assumed to be a “good guy” and have a valid license (which, from now on, I’m using as an example). So this site, the “Site Zero” is the one that has to tell other sites that you are a good guy and should be allowed to join discussion groups, register for events or join in orgies, all dependent on what the license is all about.

In what follows, I’ll use short names for the different players and terms:

  • Site Zero: The site that contains a database of people with a license and that can testify to their status. This is the site OtherSites trust for this information. I used the idea of a “license” since using the more frequent “certification”, as in CISSP or MSDE, turns out to be confusing once we get into public key certificates.
  • OtherSite(s): The site or sites providing a service to licensed individuals. These sites trust Site Zero to tell them which individuals are licensed and should be let it.
  • User: The person that is licensed and wishes to prove that to OtherSites.
  • PKCS: Public Key Crypto System, as a general term, not implying any particular system.

Generally speaking, the Site Zero can either provide an online service of some kind that other sites can connect to and check your credentials, or it can provide you with credentials that you can pass on to sites of your choice.

Online service

Site Zero can provide a web service that allows other sites (“OtherSite”, in what follows) to check if a certain individual is currently licensed. But this has a load of drawbacks:

  • The Site Zero server needs to be online all the time. It increases the fragility of the total system. Even if the OtherSite only checks the first time the user registers, the risk of non-functioning is greater than in the offline system.
  • Access to the Site Zero database should be limited to avoid abuse. That implies that either the OtherSite must be preregistered with Site Zero, or that the user registering with OtherSite must hand over a token that allows OtherSite to query Site Zero on his behalf. That token can be a one-time password, for instance. (You wouldn’t want to give OtherSite a password that can be used in the future for nefarious purposes, do you?)
  • OtherSites must implement a client for the service that Site Zero provides. Chances are great that Site Zero will implement its service in a way that is unique, so for each kind of Site Zero OtherSites want to work with, they have to implement and maintain yet one more client application. And getting all Site Zero’s together to define a standard sounds like a job for another year to me.
  • Since Site Zero has a database and provides an Internet-facing service that gives some measure of access to that database, it will be a target for attacks. There is no way to guarantee that the service will withstand all attacks and it remains a risk and a maintenance headache.
  • It will be very difficult to keep information from trickling back to Site Zero. If you want to join a group, Site Zero will know about it and that is not always what you want. For instance, you may get a reduction in licensing fees from a competing license if you can prove you have a certain license already and you don’t want your first licensing organisation to know about your unfaithfulness. It is also very difficult to arrange a scheme whereby you can register at an OtherSite anonymously. The requirements on the web service soon become really complicated if you try.

Offline service

Another way of solving this problem is to have Site Zero provide the user with some kind of token he can present to any OtherSite he chooses to. If the token is carefully crafted, it would allow the OtherSite to verify the user’s license status securely without any need to contact the Site Zero at all. Since the user only hands out the token to the sites he chooses, there is no way a random cracker can get at membership data or license status of large number of users through weaknesses in this mechanism. So, how can this magic work? There are several possible scenarios. Each one is based on public key crypto systems. Any such PKCS should work, so I’ll leave it out of the discussion if you need to use PGP or S/MIME, for instance. In what follows I do assume you have a good working knowledge of how PKCS’s function and what their requirements are.

Certified public keys

The user produces his own keypair using any of the available public key crypto systems and sends in his public key to Site Zero. Site Zero then signs that public key with its own private key and sends it back. What the user now holds is a “certificate” that he can use to prove that Site Zero approves of him in some fashion.

But how do you put a time limit on such a certificate? Well, you can choose between a couple of ways to do it:

PKCS Certificates

  • Site Zero signs the user’s public key with a private key that expires as the user’s professional license expires or is up for renewal. This is a hassle, since Site Zero will need to handle a lot of private keys, each one for a certain year, or month or even day, depending on the granularity of the license expiration system. To allow OtherSites to verify these signatures, another common private key is needed, allowing Site Zero to sign each of these expiration dependent private keys. Yes, it can work, but it’s not straightforward by any means.
  • The user creates a public/private keypair with an expiration that corresponds to the expiration date of his license, then submits the public key to Site Zero. Site Zero checks that the expiration is correct and signs the public key with its own private key. The disadvantage of this system is that the user needs to have a separate keypair for each license he wants to prove, increasing his hasslefactor a bit. On the other hand, this is also an advantage, since he may not want to divulge his license status to just anyone he sends a signed document to.
  • The ideal solution would be that the application of Site Zero’s signature to the user’s public key would itself carry an expiration date, but this is not supported by current public key crypto systems.

In all the above cases, the user needs to use a public key crypto system himself and be savvy to the use of it. The chosen crypto system must also play nice with other software the user has, such as email programs. None of all this is particularly difficult, but it isn’t trivial either.

Signed tickets

Another solution does not involve any cryptographic operations by the user himself, only by Site Zero. Site Zero produces “tickets”, that is textual or structured documents with selected information that it signs with its own private key and hands over to the user. The user is then free to pass this document on to any OtherSites he chooses. Each of these sites can verify Site Zero’s signature using its public key, without having to divulge to Site Zero that they are verifying a particular document or even how often they do this. Or even that they exist at all, since the public key can be retrieved from a third party.

There are different ways this ticket can be assembled.

License info, general

The document contains the following information:

  • User’s name
  • email address 1
  • email address 2
  • License expiration date
  • Site Zero’s digital signature on the above content

With this information, the OtherSite knows enough to allow the user to use its services. The major advantage with this system is that the user can reuse the same ticket any number of times. There is no particular need to protect this document either.

Often, the OtherSite needs to verify that a certain email address belongs to a given licensed person, so it is a good idea to include one or several email addresses in the structure. These are email addresses Site Zero can assert really belong to the given user.

License info plus dynamic email address

Many sophisticated users create separate email addresses for each site they register with. Site Zero can provide an entry field where a user can enter an email address and then request a signed document with that address included. This allows the user to produce a separate signed document for each OtherSite he wishes to register with, with each signed document containing only the customized email address to give to that site (plus his name and license expiration date, and Site Zero’s signature block).

Anonymous ticket

And what if the user doesn’t want the OtherSite to know who he is, beyond his license status?

  1. The user starts a registration process at an OtherSite and gets presented with a random token
  2. The user logs in to Site Zero with his username/password and copies the random token into a field
  3. Site Zero produces a document containing only the following:
    • The random token from OtherSite
    • The user’s license expiration date
    • Site Zero’s digital signature on the above data

    Note that there is no information in the document that can identify the user.

  4. The user copies the document into a field in the web page of OtherSite, which in turn can check the signature and accept the user as a licensed, but anonymous, individual.

When would this be useful? Well, consider:

  • A site where doctors report abuses by medical representatives from pharmaceutical companies
  • A site where doctors can watch naked pictures of each other or play medical poker.

Signed tickets in general could easily be implemented by having Site Zero present a logged in user with a page that allows him to select what information Site Zero should include in the signed document:

  • User’s name and/or license number: optional
  • expiration date of license: mandatory
  • one or more email addresses: optional
  • a text field where the user can enter other information to be signed: optional

Notes:

  • Any email addresses should be verified by Site Zero to exist and be formatted correctly. Site Zero doesn’t have to (can’t, actually) check that the logged in user owns those email addressed.
  • The free text field should be strictly limited to a relatively short string consisting of only letters and digits without any other characters or blanks.

The above constraints on user entered information is to make it more difficult to produce deceptive documents using the service. One can imagine that if the free text field allowed the entry of a text such as “The user identified above has received the Turing Award three times and is a candidate for the Nobel Prize in earthenware history”, any recipient of such a document could easily believe this is a statement made by, and signed by, Site Zero.

2 thoughts on “Proving membership online”

  1. Nice writeup. I believe this is also the federated identity problem… I personally think the CN field in a digital certificte could be an easy method to solve this problem. I get a cert (self-generated?) and have site zero sign it. Then I can present that digital ID to anyone who is interested. There are holes in this scenario, but none too big.

    Also see http://www.cacert.org/

    I am trying to fit cacert into the model above.

  2. Thanks, Javed. Well, the task of the CA is to be a trusted third party to both negotiating partners in a transaction of some kind. In this case, the transaction is between the user and OtherSites, with Site Zero as common trusted third party. So it would be entirely natural to have Site Zero as ultimate CA for this particular scenario. One more CA “above” Site Zero won’t contribute anything to the security. But, I admit, it may often be a political necessity.

Leave a Reply

Your email address will not be published. Required fields are marked *