USENET Certification Permission Language - Preliminary
USENET Certification Permission Language - Preliminary
Note: This was a draft done back in 1998 to show some ideas. It's not
a spec from which a system could be built. More lately I have felt
it would make sense to build on an existing working system like SPKI or
Keynote, even if they don't match USENET exactly.
Certificates on USENET grant permissions to the owners of the keys
certified by providing expressions in a "permissions language" as
It's possible as well that the format of the certificate should simply
be SPKI, with attributes as described below for USENET, and a few modifications
to keep things compact as USENET needs but E-mail doesn't. In fact, chances
are that a new certificate language is not likely to be adopted if another
language is workable.
As such I have prepared a document on how to use SPKI for USENET certificates. Right now SPKI certs are a bit larger than they
need to be, however they are not nearly as overlarge as X.509 certificates,
and they do have the right ideas in mind.
This document is retained here to describe some thoughts I had in this area.
A USENET certificate consists of:
- The certification method, usually U for USENET-1
- A "certificate number" when multiple certificates are found in one
document. This allows quick reference to the key being certified.
- Any flags on the certification, modifying the behaviour of other fields,
most notably the hashing algorithm.
- The key-name of the certifier, whose key will be available from public
sources, or certified in another certificate. May refer by shorthand to
the key certified in another numbered certificate in this document.
- A signature, using the named key, of the certificate language instructions,
following rules specified in the flags.
- Instructions in the certification language, which describe attributes of
what is certified. There are a few mandatory attributes any certificate
- The public-key of the entity being certified, expressed in the standard
ASCII format for that public key type. In format U, it is a MIME
base64 encoding, possibly with inserted line breaks.
- Instructions in the certification language specifying the abilities
and/or identity assigned to the owner of the key being certified. These
instructions may also set flags, and set the expiration date on the
Optional but highly likely to be required by users of the certificate are:
- Either the creation time/date of the certificate, with an optional
expiration period, or an explicit expiration time for the certificate.
- An encoding of the relationship between certifier and keyholder, ie.
why the certifier granted the certificate.
Encodings of the public key and the certifier's signature will include
any information needed to process them, such as signing algorithm,
hashing algorithm and key length. Default signing algorithm is DSS with
a 768 bit key. Default hash is 160 bit SHA.
The certificate language consists of terms, delmited by semicolons.
Each term has a keyword, optional modifiers and arguments which may
be patterns or strings. Patterns are:
- A simple pattern language using '*' to mean all strings. In addition,
the "|" character allows the selection of alternates, any of which may
match. "yes|no" matches either "yes" or "no".
A sim-pat may also include a pattern preceded by a "!" character. This
indicates the pattern must not match.
- Regular Expression (regexp)
- A full regular expression as matched by the popular Unix program "egrep"
or the popular "regexp" package by Henry Spencer.
- Anchored regular expression
- A regular expression with an implied '^' at the start, which must match
the beginning of the string being tested. Note that an anchored regexp
can be turned into an unanchored one by placing '.*' at the beginning.
- Fully anchored regular expression
- An anchored regular expression with an implied '$' and the end, so that
the entire expression must match the entire string being tested.
A modifier places limits on a term or set of terms. The term or set
of terms are surrounded in brackets. The closing bracket is followed
by the modifier.
Modifiers are also inherited from
the certifying agency. Thus if a certifier's own permissions only
include a specific set of newsgroups or subnet, they implicitly apply
that limit to all certificates granted by that certifier.
Modifiers are themselves enclosed in brackets, so a modified term
will have two or more adjacent sets of brackets. The first set contains
the term or terms. The latter ones are modifiers. Inside the brackets,
a modifier consists of a keyword, whitespace and any arguments.
G - Newsgroups
The presence of a newsgroup pattern in square brackets indicates the
permission in question is valid only in the set of newsgroups matching
the (sim-pat) pattern. If no newsgroup pattern is provided, the permission is
granted over the entire net, if that is applicable.
Normally this applies to the groups in which the message is posted. However,
for control messages, this modifier also applies to groups affected by the
control message. (A control message is posted to some newsgroups but may
contain other groups named in the message, or may affect messages in other
[Control "newgroup"][G comp.*]
bestows the right to issue "newgroup" messages in any group matching
the "comp.*" pattern. The pattern may be a comma-delimited list of
patterns, and the pattern matches if any of them match.
Special macros may be used in this modifier. "%n" should be replaced
with the list of newsgroups from the Newsgroups: header of the article
in question. "%n1", "%n2" and so on should be replaced with the
appropriate numbered entry from the Newsgroups: header of the article.
D - Subnets
A modifier of the form "D pattern" indicates the permission is valid only
at sites in a subnet matching the (sim-pat) pattern. Typically that means sites
which belong to a distribution which matches the pattern, however this
can also be used to set up any sort of administrative group for granting
[Control "rmgroup"; Control "newgroup"][D knights.*][G alt.*]
Establishes the permission to issue newgroup and rmgroup messages in Alt,
only at sites that are in any subnet matching "knights.*"
As can be seen, when more than one modifier is present, all modifiers apply.
(AND rather than OR.)
R - relate
Specifies the relationship behind the certification of these particular
terms. The argument is identical to that of the "Relate" term (which
sets terms globally for the certificate.) This can be used to apply
relate terms only to certain aspects of the certificate. For example,
a certifier might be very certain about a person's height, but only
be making an estimate about their age, and want to say that.
The public key of the keyholder. Required in any certificate. Expressed
as the MIME-base64 encoding of the key. Keys will typically be 512 or
768 bits. Occasionally they will be 1024 bits but this level of
security is overkill for most USENET signing. A 768 bit key takes 128
base64 characters. Folding white space may be inserted in the key.
The unique name of the key, for use in database lookups. May match the
syntax of a message-id (or e-mail address), or that of a URL. In any
event must match any "Namepat" attributes of higher level certificates.
The E-mail address macros such as "%f" apply here.
Here are keywords that grant permissions.
Takes as argument which is an anchored regular expression.
Bestows the power to execute any control message matching that
A special rule for this tag: If the control message affects a particular
newsgroup, then that newsgroup must match any G modifiers on this tag.
Normally, the G modifier affects the groups the message is posted to.
This means, for example, that for a cancel message, the original message's
groups should be retrieved, and the cancel executed only in groups that
match the G modifiers on this tag.
- [Control "^newgroup"][G comp.*]
- This keyholder can issue newgroup control messages only in the comp
- [Control "^cancel "][G news.announce.newusers][D moose]
- This keyholder has the right to issue cancels of messages that appear in
the newsgroup news.announce.newusers. However, only sites that
consider themselves in the "moose" subnet should execute this cancel.
- [Control "^checkgroups"][G clari.*]
- This would allow this keyholder to issue checkgroups that describe only
groups in the "clari" hierarchy. Any groups not in that hierarchy contained
in the checkgroups message would be discarded.
- [Control "."][G foo.bar]
- This user is given somewhat godlike powers over the foo.bar
newsgroup -- they can issue any control message there, cancel any message
there, adjust named articles there, etc.
This special tag takes a regexp which describes a message-id, including
angle brackets. The keyholder may cancel any message-id which matches
This special tag takes a string argument which is a site name. The keyholder
may cancel any message for which the specified site is the article's
injection point, as defined in the syntax for the "Path" header.
This special tag takes a sim-pat argument which is a site name. The keyholder
may cancel any article which has a "Path" entry which matches the sim-pat,
including the injection site.
Takes a set of comma-delimited E-mail addresses as arguments.
Bestows the power to post, cancel and otherwise use the provided E-mail
addresses in headers where such are used. Special "macros" may be used
as arguments that do not have an "@" in them. They should be expanded
- Insert the first E-mail address found in the From: line of this message.
- Insert the first E-mail address found in the Reply-to: line of this message.
- Insert the first E-mail address found in the Sender: line of this message.
- Insert the first E-mail address found in the Approved: line of this message.
- Insert the first E-mail address found on the header specified in "[Header]"
- Inserts a percent sign.
Example: The token "U %f" in a message with a From line of
"email@example.com (Brad Templeton)" would be expanded to
"U firstname.lastname@example.org" before hashing the certificate to test its validity.
If it tests valid, it thus indicates the keyholder is enabled to post under
that address, generally taken to mean the message is really from
email@example.com. This short four character expression, in fact, would be
the most common type of certificate.
See also the "ActAs" tag which is like "U" but allows a pattern.
Indicates that this key should be kept locally, as it will be frequently
used. Common for certifier's keys. Optional date parameter specifies
an expiration date for keeping the key, if different from the key's own
Takes as an argument a regular expression matching a header line in an
article. This general header can accomodate almost all future generated
headers that require authorization. Most other items are special cases of
this. The expression must match the header line entirely.
[Head "^Magical:.*$"][G comp.foo.bar]
Gives the keyholder the ability to use the "Magical" header in the comp.foo.bar
newsgroup. It is presumed that if this header has special powers, any
software that implemented those special powers would check to see that
the signer of the message is able to use this header.
Takes as an argument a regexp matching article names this
keyholder is permitted to use in a "Control Name" message
[Name faq][G rec.humor]
The holder of this certificate is allowed to issue "Control name * faq"
messages in the newsgroup rec.humor. This means they can set,
delete or add to the FAQ file.
Takes a numerical argument, indicating a volume of articles per hour
the poster is allowed to post. Needed by users who generate posts using
autoposting programs, such as those who post FAQs and stats. Other users
may be subject to posting volume throttles limiting them to what a typing
human being would be likely to need to post. Programs that check for or
throttle high posting volumes would check for such an attribute in the
signer's certificate, and alter the limits for such posters. Most sites
wouldn't do this checking, but instead would leave it to special checkers.
Effectively gives this keyholder the ability to post as fast as she wants.
Takes as an argument a quoted string which is certified to be the keyholder's
name. Takes optional 2nd argument indicating a name for the level of
security in that certification. The default is the keyholder appeared in person
with adequate photo ID to a certifying agent. The same "%" macros used
in the "U" keyword apply here, however only the comment portion of the
E-mail address line is inserted.
[Realname "Brad Templeton"]
Indicates the keyholder is certified to have that real name. On USENET, it
may be unlikley that real names are commonly certified, but some newsgroups
may wish this.
Relationship of the certifier to the keyholder. This provides information
about how convinced the certifier was about the certified aspects of the
keyholder's identity. More than one relation may appear. Some relations
can only be used on certain fields. Usually it's obvious which ones work
for E-mail, addresses, real names, sexes and so on.
In each instance, unless specified otherwise, the certifier has made
best efforts to verify identity to the level specified. In addition,
by default it is warranted that the certifier has a valid contract with
the keyholder wherein the keyholder warrants that all the information
he/she has provided is true, and that the keyholder will cease to use the
key if it becomes untrue. (For example, if the keyholder moves, they will
not use a certificate for their old address.) In the case of certification
methods involving meeting the keyholder in person, or exchange of postal
mail, the contract must provide a $3,000 penalty for violation of this
The ceritifer is the keyholder. Often done when certifiers have special
keys used only for certifying, and they create other keys for other
Members of immediate family who have known keyholder since birth.
General party who has known the keyholder since birth.
Party who has had a personal relationship with the keyholder for NN years.
Party who has had a business or professional relationship with the keyholder
for NN years.
The certificate is from the keyholder's employer
The certificate is from a government agency, typically one involved in
the assignment of or verification of identities, addresses.
Party who was unknown to the keyholder, but has performed a careful ID check
including examination of photographic IDs (passport, driver's licence,
birth certificate etc.) and interviews with trusted parties known to the
keyholder and the certifier. Can only be used by certifiers authorized to
apply this tag.
The attribute is something that can be subject to physical verification,
such as a height, weight, sex. A keyholder need not be known to the
certifier for the certifier to confirm she is 1.7 metres tall, for example.
Party who was unknown to the keyholder, but has performed a general ID
check, including examination of photographic and other IDs, but no
interviews or rigourous checking.
Party unknown to the keyholder who has done a basic check of an existing
standard ID form such as driver's licence or passport.
Party unknown to the keyholder. The keyholder simply certifies that this
party is the first ever party to claim the identity attributes in this
certificate. (Generally non-identity attributes would not be allowed.)
A pretty insecure means of certifying, but possibly suitable for anonymous
groups and loose-knit groups. With such certificates, keys are simply
established by using them and then fetching them from the certifier's server,
or mailing them to the certifier with a claim of some identity.
This relation should be placed on any certificate which has an identity
attribute but is considered anonymous. This means the certifier does not
know or has erased any true identity information, and is creating an
artificial identity for the keyholder. See the Count attribute.
This relation should be placed on any certificate which has an identity
attribute, but the identity is a deliberate pseudonym. The certificate
holder will strongly resist any attempts to discover the true identity
of the keyholder. However, the pseudonym is persistent, and mail back
to the keyholder is forwarded, and there is some channel for complaint.
Verification was done over the telephone, the keyholder can be reached
via the phone number in the certificate. A "Sex" field may be certified
in this way but should be considered of minimal trustability, it simply
indicates the person who answered sounded male or female to the certifier.
Verification was done via the phonebook. The keyholder provided a name
and phone number. The certifier looked these up in the phonebook and
confirmed the number, and called it to speak to the keyholder, who was
available at the phone number.
The certificate was sent by postal mail to the name and address specified.
Verifies the keyholder receives mail at that address.
If anybody at that address objected to the assignment of
the certificate, it will be revoked.
A charge was made to a credit card in the name (and optionally
address) of the keyholder. It passed. If more than 90 days old and not
revoked, it can be presumed the charge has cleared, though identity is
not certainly established.
For verification of E-mail addresses. The certificate was E-mailed to
the E-mail address it certifies. The keyholder is able to read the E-mail
of that address (which may not be because they own it, of course.) In
addition, if anybody at that address objected to the assignment of
the certificate, it will be revoked.
The certifier created the E-mail address of the keyholder (ie. is an ISP
or E-mail provider) and certifies the match. May also add other tags to
certify other fields.
The certifier simply assigned the specified identity to the keyholder. It
may or not be any form of "real" identity. The certifier simply warrants
the keyholder has this identity, and barring transmission of private keys,
is the only one to have it.
This is another assigned identity, but in this case the certifier warrants
that no only is the keyholder the only one with this identity, but that
the certifier has taken some steps to assure this keyholder has no other
active identities certified by the certifier.
Takes an argument of M, F or O. Indicates the certifying agent verified
the sex of the keyholder. How they did this is left as an exercise to the
reader! O stands for "other" and may be used, if a certifier deems it
appropriate, for people who do not have a sex. Note that this tag is
for places where the poster wants to prove their sex, such as singles
newsgroups or personal ads. It would never be required to be revealed.
This is a phone number of the keyholder. Syntax of the phone number is
unspecified, and may contain other attributes like the word "fax" or
"cell" or "pager" etc.
A postal address for the keyholder.
Takes a pattern, may cancel any message from a user matching that pattern.
Takes and argument which is a regexp, typically one that matches a
particular domain. Provides the power to act as any address whose address
matches the pattern. (Ie. to act as though the U tag is set to that user,
and thus to post, cancel, supersede or replace as that user.)
As a special case, if combined with the Cert tag, this keyholder can issue
"U" certificates to userids that match the pattern.
Indicates the keyholder can post to the groups specified in their
modifiers. (Always used with modifiers) Works even if they are moderated.
This allows moderators the power to grant some people the right to
Allows the keyholder to approve posts. Generally used with modifiers to
specify a group. Sites should check postings in moderated groups for
either a "Post" attribute or "Approve" attribute by one of the signers.
Grants the power to issue a revocation message for this public key.
Users may not wish this power by default. If their private key is stolen,
the thief can act as the victim. It may be that the denial of service
attack, where the thief revokes the victim's key, is worse than other
impersonations. Users can always revoke by contacting a higher level
certificate owner -- they need to do that to get a new certificate after
revocation anyway. Thus this power is not normally granted.
This keyholder can issue "revocation digest" articles, which list the
160 bit secure hashes of keys that have been revoked and how long the
revocation records should be kept for. Sites must listen for these digests
and store a local database of revoked keys. Any key used to check a
signature should first be looked up in the revoked keys database, and
not used if found there.
The keys to be revoked must, of course, have been issued directly or
indirectly under authority of the signer of the digest. All keys
authenticated by a revoked key become invalid.
This keyholder can vote to revoke a ROOT key. At least 3 different
revocation digests from 3 different holders of Rootrevoke certificates are
required to enact such a revocation. This number may be increased at
the discretion of individual system implementors. Once a root key is
revoked all keys issued under it are invalid.
This keyholder has the power to violate crossposting restrictions within the
groups and subnets specified for this header. This presumes these groups
have crossposting restrictions.
Defines the common subset of powers for a moderator. Namely:
It is expected that any other generally accepted moderator powers SHOULD
be added to this group as they are defined.
With the special argument of "none," the keyholder can violate all policy
rules for the newsgroups and other parameters specified. Arguments will
refer to specific rules and their own parameters to define new limits.
These limits are not defined, they are up to the rules checkers, which
must register their names is a rules registry to keep them unique, but
otherwise are free to act as they wish. It's expected many groups will
put on limits on article size, article types, use of anonymity.
Allows the keyholder to do crossposts among all of those groups.
Bestows the power to grant certificates delegating the powers in this
certificate. Takes an argument which is a number, default of "1".
This number is the number of delegations allowed, and must be decremented
in every certificate that issues the power to further certify. Delegates
may only set this number to one lower than their own certification number
or less. A level of 1 (the default) implies the owner can delegate
its powers, but the delgates all are at level 0, and can't delegate theirs.
Applies to keys with the "Cert" attribute.
In any certificates issued
under this key, the "Keyname" must match this regexp, typically one
which mandates a specific suffix.
This allows chains of unique key names in a similar
pattern to the DNS hierarchy.
The date of issuance of the certificate, in USENET date format, with the
exception that a time of day is optional. This
field is required or a certificate is invalid.
A number of days (floating point number if fractional days are needed)
from the certification date that the certificate is valid. Default of 60
days. Certificates should be rejected after their lifespan has expired.
Due to the inheritance rule, certifiers will get longer lifespan certificates,
and renew well before the end of their lifespan, as they can't issue
a certificate that lasts beyond their lifespan.
No certificate may last for more than 366 days, even the root one. New
root certificates, signed by an earlier root, will be issued.
For anonymous identities, indicates the number of identities the
keyholder has acquired to the best of the knowledge of the certifyer.
Note that this is not mandatory, but it is presumed that some systems which
grant anonymous identities will be more palatable to some users if this
count is present, and accurate.
Takes a numeric argument N. Indicates that what this keyholder is signing
is not valid unless at least N other certifers also sign it. Thus if
You see a key or article certified or signed by a signer that has "Multi 3"
in their certificate, it must also be co-signed by 2 other parties with
a Multi of 3 or less. All of them must have the power to enact the
attribute in question.
For example, the revocation of a very high level key, such as a root key,
may require some number of other root certificates, all signing the
revocation. This is primarily intended for root powers, so that one can
give away root powers not to a single keyholder, but to a group.
This keyholder may include a special "Powers" header in a News
article. A permissions header includes statements in the certificate
language, and is signed as part of the general article header. However
they are not part of a certificate.
A Re-Signer takes an article which has a chain of certificates and "collapses"
them down, signing the whole article with its own key, and adding its own
certificate if need be. (Normally, the keys of the few re-signers would
be cached at all sites to avoid the bulk of adding the Re-signers's
certificate.) It checks all attributes of the article that it knows about
and assures that the certificates that came with the article permit them.
Any headers it does not know about (there should normally be none) it
lists in a header named "Unverified" as a comma delmited list of header
names. (In the case of headers like From which have an E-mail address and
comment, there is a special syntax.)
This will include any headers outside the spec, unknown control
messages or any headers which fail to be authorized by a certificate.
Any permissions in the certificate that it did not understand will be
listed in a Powers header. (Unless "Date" and "Life" parameters
are to expire within 4 days, they are not included.) Their placement
there is the re-signer's assurance that the original poster did have these
tags in their valid certificate, even though their meaning was unknown
to the re-signer.
When sites receive a re-signed article, they can assume that the
headers not listed in the Unverified list are issued by the re-signer,
with all the re-signer's powers.
For unverified headers, if they have a meaning to the recipient site or
reader, they may be checked using any of the tags on the Permissions lines.
It is possible that this feature may be not-needed, if the rule that
messages with unknown attributes are not collapsed is applied. This means
that users with special certificates will want to also have more ordinary
certificates for use in ordinary postings.
It is expected that most articles on the net would go through a re-signer.
As such, their only authentication information will be the authentication
method, re-signer's key name and the re-signers's signature of a hash of
the article and all its verified headers.
As such, the signature overhead is small, and in addition, ordinary sites
do not even need to understand the certificate language if they don't
want to. They simply know that if the re-signer signed it, it's valid
according to any global rules that the site trusts the re-signer to
check. Any rules specific to the local site must still be checked
there. (This would require the Powers header.)
Certificates are bulky, and as such, their collapse into a single
signature by a re-signer allows the entire system to be space-efficient
but still fully powerful with authority fully distributed. The re-signer
will in fact be an automated machine that interprets the formalized rules
and issues and confirms they are being followed.
This key has the power to issue any certificate at all. Itself it has
no powers, it uses powers by creating certificates for those powers.
The certifier makes a declaration of trust in the keyholder for the
attributes in this certificate. This is not really different from an
ordinary certificate, but indicates it was possibly issued without the
awareness of the keyholder. As such, keyholders are unlikely to include
certificates of trust in their own postings. Instead, sites should store
certificates of trust (that they themselves trust) locally. When they
encounter an article and have no information on the signers and certificate
signers, they can check their database (or other databases they trust) for
certificates of trust from accepted parties.
All systems that test signatures need to enable at least one root signer.
A database of trust certificates is one way to do this.
Multiple trust certificates can exist, though the creation of multi-level
webs of trust is up the security administrator of a site.
This certificate has all powers -- usually present with modifiers for
a subnet or set of newsgroups. Not sure if we need this independent of
the Root tag.
When one keyholder (who has the "Cert" tag) delegates power to another
by signing a certificate, the two certificates must be combined together.
Any command executed using the delegates certificate must be legal for
all certificates used to authorize it, ie. the AND of the permissions test
for each certificate. This prohibits delegation of powers a certifier
This means that one certificate in the chain must have the "All" tag.
However, this could be one the local site administrators installed, and not
an external certificate.
As a special case, a ROOT certificate is not tested in combination with
certificates it signed, though most chains will end up at a root
A simple Grammar
Cert = Tagset *(';' Tagset )
Tagset = Tag | Taglist
Taglist = '[' Tag 0*(';' 1* Tag) ']'
Mod = '[' Modifier ']'
Tag = Keyword *(Argument)
Argument = number |
Modifier = keyword *(Argument)
sim-pat = pterm '|' pterm |
pterm '&' pterm |
pterm = Newsgroup |
quoted-string = '"' 1*(any except double-quote) '"'
quoted-regexp = quoted-string
keyword = Alpha [A-Za-z0-9_-]
number = 1*([0-9])
Regular expressions are as defined in regexp package of Henry Spencer.
Tag and modifier keywords as defined above.
How it all works
Say a newgroup message comes in. As with any article, you order the
certificates based on how they reference one another, leading to the top
one that you recognize. For the signer that you recognize you will need to
fetch their own certificate from your own database. Chances are that
there, you have appended it with any certificates used to verify it.
You will also have stored a list of trust certificates for your site,
most notably some that trust one or more commonly used root keys.
Then you verify all the certificates down from the highest one that you
haven't already verified (the ones in your database are already verified).
Assuming they all verify, you will have developed a series of strings
in the certification language, the final one verifying the key of the signer
of the actual message. Using that verified key, you can then test the
signature on the actual message to assure it is good. This list of
certificate strings includes certificates fetched from the local database.
If there is anything invalid, you probably will reject the message.
You must also assure that no certificate has expired or been revoked.
To test revocation, you must have your own database of revoked
keys (or simply secure hashes of those keys to keep it compact.)
Any higher level certificate must have the "Cert" attribute with enough
levels of authority to issue the certificates underneath it.
One must also add the text from any "Powers" line (which will contain the
non-standard attributes) and test that the signer of that header has
the "ReSign" attribute.
You can then use this list to test if the signer is authorized to perform
the operation in question. The test must pass for every certificate in
At the end you have a list of permissions for the actual poster, and the
poster's key. You check the article using the poster's key -- if it checks
out that, poster really sent it out.
For an ordinary message to an ordinary newsgroup,
all you are likely to test is whether the user is authorized to use the
address on the "From:" line or similar lines. For this test, you will
chain downwards, testing for either a "U" attribute, or an "ActAs" attribute
that matches the from line, or of course the "All" attribute. Any attribute
must be tested against its modifiers -- all modifiers must match parameters
from the article.
(Thus if the top level certifier has permissions on comp.* and the middle
certificate grants that power on *, permssions remain only on comp.*.)
For a more complex operation, like a "newgroup" control message, you would
check that every certificate has either the "all" attribute or a
"control" attribute whose pattern matches the control line of the message.
Once again, the modifiers on these attributes must also be tested.
If all certificates test positive, you execute the command, if not, you
Most people would get a certificate for their name. For example,
U firstname.lastname@example.org; Date 10 Oct 97 GMT; Life 180
This allows posting, reply-to and cancel as this user. It would usually
be written as "U %f" in any message with a From: line of this address,
for brevity, but the actual certificate, when signed by the certifier
has the real address, and after expansion, the one checked by the
destination does too.
A site like aol.com might get a certificate of the form:
ActAs ^.*@.*.aol.com$; Date 1 Jan 98; Life 365
This would allow this keyholder to post, cancel or otherwise act as any
user at the AOL.com domain. This key would actually belong to a server
at the aol.com site, which would verify its own users using the site's
own security and validation method, and sign their articles. This would
avoid any need for the individual users to have their own keys. Such
certificates would only be handed out to sites that had decent internal
security. Nothing would prohibit AOL users from getting their own
certificates, but the main AOL server would still have a key that let it
act on the net as (and we presume for) any AOL user.
A moderator might get a certificate that allows "All" but with a modifier
of the moderated group. This is quite simple, but grants the moderator
certain powers you might not want to grant, such as the ability to forge
postings from other users.
A better scheme would grant the moderator specific powers.
- The ability to issue any control message, including cancel, in the moderated
group: control ".*"
- The ability to "approve" postings in the group: Approve
- The ability to post in the group: Post (This is redundant with
Approve, but useful to delegate.)
- The ability to delegate these powers, notably "post", one level: Cert
- A requirement that any delegated keys have names that end in "foo.com":
The resulting certificate, including the required attributes, looks like this:
[Control ".*"; Approve; Post; Cert][G foo.moderated];Date 30 Jan 98;Life 128;
Keyname email@example.com; Namepat ".*foo.com$"
As noted, it is expected that most articles will go through a
"certificate collapse" process. In this process, an article with a chain
of certificates is sent to a daemon which performs the collapse.
This daemon performs all checks to assure all signatures and certificates
are valid. Permission for standard operations described in this spec
are tested -- Control messages, newsgroups, e-mail addresses, full names,
crossposting etc. Tests for subnets are only performed for a subnet
in which the daemon is authorized to operate.
If all checks out the daemon will remove all certificates from the
article, and may remove the original poster's signature as well. It will
then place its own signature on the article, using its own key.
Its own key will have a powerful set of attributes, possibly "all," at
least for the groups or subnets it is handling. This key will also have
the "ReSign" attribute.
Any unknown attributes, or attributes with special modifiers not processed
by the collapse daemon will be collected and written out to a special
header entitled "Powers:" Appropriate certificate strings will be
appended with a double-semicolon between them. Typically this should
not be necessary.
As such articles will arrive with one signature and no certificates. A site
can accept them, if it trusts the signature of the collapse-daemon, with
no further checks.
Revocation messages and forms
Subset revocation, how to grant a power globally but exclude it within
a subset -- ie. can post to anywhere but not in a specific group, or
revocation within a specific subset or group.