From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Mon Oct 08 2001 - 07:03:31 CDT
In <20011006122348.D3986@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
>The way a certificate system works is you can delegate delgation. I
>expect typically that most sites would not want to track who they will trust
>to spam cancel (or perform other cancels.) Rather they will decide to
>delegate that to others.
I would not put it like that. I would say they decide whom they will trust
to give advice on whose cancels/whatever should be accepted. But I doubt
I would automate the system much beyond that.
>The default in fact will probably be to the author of their news software,
>though that's not a requirement. And that author will probably delegate
>to some reasonably trustworthy volunteer who then delegates to people who
>want to do spam cancels.
>You can has as many levels as you like, though I would expect it would
>gravitate to just 2 or 3.
I can see a little scope for that (esp. for moderators). But I am not sure
you want the full works of SPKI, or anything like that. Essentially, you
want a field within a key which states the intended function of that key.
People will sign that key if they think the key owner is a fit person to
exercise that funtion. There are spare, unallocated, fields within Open
PGP that could be used for such purposes.
>This debate has been going on for some time. The question is,
>what are you certifying to the software? You're certifying that the
>keyholder was trusted to cancel. Of course when you or your CA made this
>trust decision, you probably considered who they were and what you knew
>about them.
You don't need to "certify" anything to your own software. You just give
it a list of people/entities and what they are empowered to do. Your
software then checks digital signatures to ensure the
cancels/nocems/whatever indeed came from one of the listed entities.
>Some PKI designs (notably x.509) issue two certificates. One says
>"This keyholder is Brad Templeton, passport number x123456" and the
>other one says "Brad Templeton, passport number x123456 is authorized
>to issue cancels" and you combine them together.
>But that combination is meaningless if it's automatic. And worse it
>dictates an identity-based regime, in effect saying you must show WHO
>you are to do anything at all, even things where who you are doesn't
>matter.
Nonsense. There is nothing in X.509 or the PGP web-of-trust that requires
keys to belong to people (though one hopes that there is a real person
ultimately behind it). A key can belong to an entity which represents a
function (for example, there is an entity "control" within uk.* which does
newgroups and things; it has in the past been identified with 4 different
people, but usually only two at any one time).
But the question for an individual site should still be "do I trust this
person/entity/whatever to perform operation X on my system".
>Sometimes you need that level of security, and when you do, you can add
>whatever identity info you like to the certificate. But the system
>should be designed to _allow_ that, not to _require_ it.
Quite so, but noone is suggesting otherwise.
>> But in the real world of Usenet, people care very much what they will
>> let people dor to their machines on autopilot. Not only do they want to
>> know who is doing it, but they want to know why.
>Indeed, but they have to trust that person to reliably say why.
Yes, that is an inevitable part of the system.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5