Brad Templeton's
USENET-Format Pages

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 documented here.

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:

  1. The certification method, usually U for USENET-1
  2. A "certificate number" when multiple certificates are found in one document. This allows quick reference to the key being certified.
  3. Any flags on the certification, modifying the behaviour of other fields, most notably the hashing algorithm.
  4. 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.
  5. A signature, using the named key, of the certificate language instructions, following rules specified in the flags.
  6. Instructions in the certification language, which describe attributes of what is certified. There are a few mandatory attributes any certificate must contain:
    1. 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.
    2. 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 certificate.

Optional but highly likely to be required by users of the certificate are:

  1. Either the creation time/date of the certificate, with an optional expiration period, or an explicit expiration time for the certificate.
  2. 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.

Certificate Language

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 groups.)

For example:

[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 powers.

[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 pattern.

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 newsgroups.

[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]
This user is given somewhat godlike powers over the 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 that pattern.


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 as follows:

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 " (Brad Templeton)" would be expanded to "U" 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 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 expiration date.


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] 

Gives the keyholder the ability to use the "Magical" header in the 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.

Volume 9999 

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 real 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 clause.


The ceritifer is the keyholder. Often done when certifiers have special keys used only for certifying, and they create other keys for other activities.


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 post directly.


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:

Limits none 
Volume 9999 
Control cancel 
Control newtopic 

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.

[Xpost][G comp.*|rec.*] 

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 never had.

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 certificate.

A simple Grammar

Cert		= Tagset *(';' Tagset ) 
Tagset		= Tag | Taglist 
Taglist		= '[' Tag 0*(';' 1* Tag) ']' 
Mod		= '[' Modifier ']' 
Tag		= Keyword *(Argument) 
Argument	= number | 
		  keyword | 
		  quoted-string | 
		  sim-pat | 
Modifier	= keyword *(Argument) 
sim-pat		= pterm '|' pterm | 
		  pterm '&' pterm | 
pterm		= Newsgroup | 
		  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 the chain. 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 discard it.



Most people would get a certificate for their name. For example,

U; 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 might get a certificate of the form:

ActAs ^.*@.*$; Date 1 Jan 98; Life 365 

This would allow this keyholder to post, cancel or otherwise act as any user at the domain. This key would actually belong to a server at the 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.

  1. The ability to issue any control message, including cancel, in the moderated group: control ".*"
  2. The ability to "approve" postings in the group: Approve
  3. The ability to post in the group: Post (This is redundant with Approve, but useful to delegate.)
  4. The ability to delegate these powers, notably "post", one level: Cert
  5. A requirement that any delegated keys have names that end in "": Namepat ".*$"

The resulting certificate, including the required attributes, looks like this:

[Control ".*"; Approve; Post; Cert][G foo.moderated];Date 30 Jan 98;Life 128; 
Key sdf90sadf09adf0as9d8f0asd8f0sd8f0asd8f0sd98f0sd8f0asd9f8asdfasdfdsf 
Keyname; Namepat ".*$" 

Certificate Collapse

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.

Missing Issues

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.