From: Russ Allbery (rra@stanford.edu)
Date: Sat Jul 11 1998 - 14:55:54 CDT
Brad Templeton <brad@templetons.com> writes:
> All this body in fact really talks about is:
> a) How to sign a message (any message, control or otherwise)
> b) How to write a certificate
> c) How to verify a signature
> The rest does not need to be in this spec. The only complex part turns
> out to be "b" because when writing a certificate, you have to have a way
> of expressing what the certificate enables
I disagree with this statement. "How to sign a message" is a very complex
part, because other than some vague references that you've mentioned here,
*we do not have a functioning, exportable cryptosystem in mind for article
signatures*. What are the parameters of the ones that you've mentioned?
How hard/easy are they to implement? How fast are they? What's the IETF
direction on this in general?
I realize that you don't want to discuss details with people who don't
have a strong knowledge of how cryptosystems work, but I'm trying to
explain to you that people like me are the people we have to convince with
this standard. The people who actually write news software. You have to
give us something that we, as people who do not follow cryptosystems on a
daily basis, can understand and turn into code.
There are dozens of issues surrounding signing articles, including how to
sign headers, whether to do body munging, and the like that *have not yet
been addressed*.
> All it needs are:
> a) Predicates (attributes you certify)
> b) Modifiers (limitations on the attributes, notably newsgroup
> patterns and distributions/subnets)
> You can start with a very small number of predictes, namely:
> Control <regexp> -- power to issue control msg
> Cancel -- cancel, replaces, supersedes
> User -- email address
> Date -- date of cert issue
> Lifetime -- expire time of cert
> Actas -- power to act as any userid
> matching pattern (for sites)
> Post -- power to post in moderated grp
> Head -- Genera header regexp
> Keep -- this is a top level cert
> Approve -- Power to approve in mod group
> Repudiate -- Power to repudiate cert
> Name -- Power to post named article
> Cert (optional if you really want it simple)
I'm extremely leery of some sort of central authority system for all of
Usenet. We don't have that now, and I don't expect that we'll ever have
that. So right off the bat, we're going to have to have multiple
overlapping certificate authorities.
Individual sites will have to be able to override any and all of this, of
course, but that's a no-brainer.
How does this handle open-newgroup hierarchies like alt.* where anyone can
create or remove a group?
How are you going to explain to sites that they now have to go obtain a
certificate in order to be able to govern what comes out of their site?
What makes you think they're not going to just ignore you?
How are we going to get moderators to all obtain certificates? What about
moderators who are moderating via PC and Mac software packages and cut and
paste? There are a *lot* of those.
What's the transition plan?
It seems to me like you're proposing a central authentication and
authorization authority of a complexity level comperable to that of
InterNIC. I honestly think the chances of that succeeding for Usenet are
slim to none.
-- Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>