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

sim-pat

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.

Modifiers

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

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

[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

Key

Keyname

Keywords

Here are keywords that grant permissions.

Control

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

cancel

sitecancel

relaycancel

U

%f

Insert the first E-mail address found in the From: line of this message.

%r

Insert the first E-mail address found in the Reply-to: line of this message.

%s

Insert the first E-mail address found in the Sender: line of this message.

%a

Insert the first E-mail address found in the Approved: line of this message.

%H[Header]

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@clari.net (Brad Templeton)" would be expanded to "U brad@clari.net" 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 brad@clari.net. 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.

Keep

Head

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

Name

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

Volume

Volume 9999 

Effectively gives this keyholder the ability to post as fast as she wants.

Realname

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

Relate

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.

self

family

birthfriend

friend-NN

business-NN

id-employer

id-government

id-strong

verified

id-moderate

id-weak

id-first

anon

pseudo

id-phone-num

id-phone-name

id-mail

id-credit

id-email

id-email-giver

id-assigned

id-unique

Sex

Telno

Address

CancelAs

ActAs

As a special case, if combined with the Cert tag, this keyholder can issue "U" certificates to userids that match the pattern.

Post

Approve

Revoke

Repdigest

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.

RootRevoke

XPost

Moderator

Post 
Approve 
Limits none 
Volume 9999 
Name 
Control cancel 
Control newtopic 

It is expected that any other generally accepted moderator powers SHOULD be added to this group as they are defined.

Limits

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

Allows the keyholder to do crossposts among all of those groups.

Cert

Namepat

Date

Life

No certificate may last for more than 366 days, even the root one. New root certificates, signed by an earlier root, will be issued.

Count

Multi

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.

ReSign

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.

Re-signing

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.

Root

Trust

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.

All

Inheritance

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 | 
		  quoted-regexp 
Modifier	= keyword *(Argument) 
sim-pat		= pterm '|' 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.

Examples

User

U brad@clari.net; 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.

Site

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.

Moderator

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 "foo.com": Namepat ".*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; 
Key sdf90sadf09adf0as9d8f0asd8f0sd8f0asd8f0sd98f0sd8f0asd9f8asdfasdfdsf 
asdfasdfasdasdfasdfasdf098as0d8fs098sadfasdf09898a0sd8fasdfadsf; 
Keyname foomoderator@foo.com; Namepat ".*foo.com$" 

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.