On 2/05/12 05:18 AM, Martin Paljak wrote:
On Sat, Apr 28, 2012 at 05:25, ianG<[email protected]> wrote:
Well, to the extent above. My db has a table for all certs, and a table for
all users, with a join by cert identifiers between the two tables.
I hope you actually bind the actual public key instead of any kind of
identifiers?
Binding the public key to the user name? No, I use the serial to
indicate the cert identity [0] and I use the name to indicate the account.
The reason for this is that fundamentally the CA makes a claim. I am
sort of expecting that claim to be that the name is right, whatever that
means. So, I should "rely" on that name.
And public keys should be replaceable, as are the certs and other
fields. In practice, what this means is that when a new cert comes
along, I use some basic heuristics to analyse which account it belongs
to, by for e.g., "relying" on the name or email address.
However, the CA doesn't claim that the name is unique :) Nor does it
claim that the email belongs to that person always, tomorrow, today or
even yesterday. Nor does it claim that the person has only one name or
one email ...
Which brings me to part 2: this whole thing is an experiment in using
client cert certificates in code to finesse the whole login experience away.
(So, I'm also careful not to have high value data in there ;) )
Or would that not be against the single principle of an enduser
controlling a private key, in which case the "normal CA" guarantee of
a unique identifier (serial) under a given CA (which, in practice,
should be out of picture) ?
CAs are supposed to:
* make the serial a unique identifier. Over on Mozilla lists that
argument is going on, because the rules have recently shifted from
"probably serial therefore unique" to "hopefully unique, and now
includes 20 bits of unpredictable uniqueness." I think this might be
agreeing with your point - relying on fields written by corporate man
might not be the smartest idea.
* test for control of private key that matches the public key.
* test for control of an email address, and/or holding of some
documents that match a human name.
Now, all these are part marketing claims, part hopes & dreams. Rather
than grumble more, what I and others had been doing was experimenting.
We had a small community using client certs, and I knocked up a demo
site. To test to see how hard or easy it was.
In the end it is not hard. But it's not so hugely reliable, because of
the inherent limit in PKI/CA claims. Be warned; don't let serious
amounts of value ride on this stuff. Great for small / admin sites. And
a whole lot easier to administrate than say passwords, once you get the
cert into the user's browser.
iang
[0] Funnily enough, over on Mozilla I just recommended against doing this.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
