From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Thu Oct 11 2001 - 11:32:17 CDT
In <20011010140606.C19129@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
>CANCEL
> o) If somebody forges an article in my name, I should be able to
> cancel it quickly and easily.
Challenge/response is the only solution I can see here.
> o) If somebody posts an article from a site, the site admin should be
> able to cancel it.
Cancel-Lock
> o) If somebody forges a spam attack appearing to come from my site,
> I should be able to cancel it.
As case 1
> o) If I was not running a brand-new newsreader/poster when I posted
> an article, I should still be able to cancel it
That is the present situation. There are no overnight cures.
> o) As above, without having to install a new newsreader/poster to do
> the cancel
Ditto
> o) It's nice if most cancels can mostly be acted on without needing to get
> the original first, both because it may not have arrived and to
> avoid the disk I/O of fetching it if it has.
"Most" cancels are spam cancels, which will be signed. You act immediately
on a signed cancel; you defer an unsigned cancel that arrives before the
article.
> o) The amount of material added to the net to support cancels should be
> minimized.
Yes.
> o) It should be possible to authorize 3rd parties to issue cancels in
> various subsets of the net. This includes netwide powers for
> spam cancellers, and the ablity to cancel just in a specific
> newsgroup (allowing a group that's not pre-moderated, but
> post-moderated, which is in fact what most of the world uses and
> what some would like on USENET.)
Yes, but this can be done in a key-database system just as well as in your
certificated system.
>GENERAL:
> o) I should not be constrained from using the injector at my own ISP
Eh?
> o) As I may use my key for other puroses, I should never have to
> disclose it to somebody to delegate or transfer an authority.
Keys used for spam cancelling, newgrouping and moderation should be unique
to that purpose (so people can sign them to say they are suitable for that
purpose).
> o) It must be possible to immediately revoke a delegated authority
> when the key has been compromised or the holder of the key has
> gone rogue.
Yes
> o) It must be possible to quickly transfer a delegated authority,
> in the even the holder of it dies (or goes rogue.)
Maybe
> o) Where possible, the benefits of added security should accrue to all
> users of the net, not simply those that have upgraded to the latest
> software. Where possible, if the system can be made to work with
> legacy software, this is beneficial.
The greatest benefit will be that more sites will honour signed spam
cancels
> o) The system should be generally designed and extensible, to allow
> new authentications to be granted, and any authentication to be
> delegated.
Yes
> o) It must be possible for authorizations to expire and be renewed
> without action by sysadmins.
But reissuing an expired key is definitely for humans to do
> o) No single party or nation should get de facto or de jure control
> of general authorizations for USENET. There should not be a list
> of keys maintained by a single individual with root control.
Yes
> o) It must require a minimum of active maintenance by local news admins,
> if they so choose (and they will so choose!)
Yes, but minimum .ne. zero
> o) The authority structure should be capable of being hierarchical,
> just like USENET, so that each hierarchy and sub-hierarchy can have
> its own authorizations for all actions.
Maybe
>FORGERY:
> o) It should not be possible, at least in groups which are adopting
> authentication regimens, for another to post an article with
> my E-mail address in it as From or Reply-to.
That is for the moderator to negotiate with his posters
> o) It should not be possible for somebody unauthorized by a domain
> owner to post an article with that domain in the From or Reply-to.
Impossible
> o) It should not be possible to alter an article in transit and have
> it appear to still come from me.
Unlikely; not an issue at the current time
> o) It should not be possible for another to block the posting of my
> articles by posting 'block' articles upstream with identical
> message-ids to mine.
Ditto
>SPECIAL POWERS
> o) It should be possible to allow trusted posters to bypass limits
> placed on untrusted or anonymous posters, such as limits on
> crossposting, article size, mime-types, posting volume, sendsys,
> checkgroups
Maybe
> o) Only trusted parties should be able to newgroup/rmgroup/etc.
Yes
> o) When a new hierarchy or sub-hierarchy is created, the person
> authorized to newgroup should have that authority immediately.
No. Trust has to be earned. Look at the shenanigins that went on when
wales.* was formed.
> o) Only trusted parties should be able to do special named articles,
> topic lists etc. if they are implemented.
Probably
>MODERATED GROUPS:
> o) Only the moderator(s) or those authorized by them should be able
> to post in a moderated group
Yes
> o) The moderator should be able to cancel any post to a moderated group.
Yes
> o) The moderator should be able to delegate the ability to post drectly in
> a moderated group. (As many robomoderated groups do today) And
> to delegate sub-moderators
Maybe
> o) When a new moderated group is created, the moderator's key should
> be immediately accepted anywhere that the group is being accepted.
Possibly
-- 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