A draft of an early system, for example only.
Cert-Header = System FWS Arguments
For standard system "U"
Arguments = Key-Number ';' Signers-Key-Name ';' Options ';' Signature ';' Certificate Signers-Key-Name= Key-Name Certificate = Code in Usenet-Certificate-Language Key-Number = 1*Digit
FWS may be inserted within Signature, and between Options or around ';' delimiters.
Note: Currently work is being done on an alternative to this, based on SPKI. See my SPKI for USENET draft.
The key name and options follow the same rules as the "Signed" header, though only a small number of the options apply.
The Cert header provides a certificate for a public key which is, presumably, used elsewhere in the article to sign either parts of the article or another certificate.
The Key-Number is an integer, which is used elsewhere in the article, either in a "Signed" header or another "Cert" header. There MAY be several Cert headers in an article but each one MUST use a key-number unique within the article.
A certificate is simply a short message, naming a key and listing its attributes, that is signed by a party known as a certifier. The certifier has a key which, like all keys, has a key name. This key name is provided here. The rules for key names of the "Signed" header apply.
Systems SHOULD attempt to remember the keys of certifiers until those keys expire, and keep a local lookup database of the names of certifier's keys to allow the fetching of those keys and their own attributes and certificates.
In a "Cert" header, only the Certificate itself is signed, so most of the options from "Signed" about what gets hashed do not apply. However the +MD5 option applies.
When hashing a certificate, any newlines and surrounding whitespace MUST be collapsed to a single space.
This is provided as two 160 bit numbers, as in the Signed header.
The certificate is a list of attributes in a special language called the USENET certificate language. Every certificate starts with the name of the key, the key itself, the key's creation date and then various certified attributes about the key.
Most common attributes that will be certified include the keyholder's e-mail address, the expiration period of the key, and a statement as to the relationship between the certifier and the keyholder. (That is to say, how the certifier came to believe the things being certified.)
Other attributes that may be certified are the keyholders real name and other real-world attributes.
Perhaps most important will be "capabilities" the keyholder posesses, such as the power to issue certain control messages in various group hierarchies and subnets, or the ability to moderate or control a specific newsgroup.
For example, when accepting a message in a moderated group, a system SHOULD assure that the keyholder's certificate grants the keyholder the ability to either post, or approve postings in that group. When executing a "newgroup" control message, a system SHOULD assure that the sending keyholder is authorized to create a newsgroup of the type named. When executing a "cancel" control message, a system SHOULD assure that the keyholder who signed the cancel message is certified as holding the E-mail address used in the original message, or perhaps that the keyholder is certified with the ability to cancel any message.
Full details of this are in documentation for the USENET Certification Language. However, just about any certificate language could be chosen that can handle the attributes needed for certification in USENET, which is compact, and which is extensible.
The certification language system is complex and involved and sure to be subject to debate.
This system is designed to be as compact as possible for reasonable use in USENET. As such it differs from existing E-mail certification systems.
Rather than allow choice, which complicates matters for implementers, it is possible that the standard should dictate just one hashing and signing algorithm, leaving open the possibility of others only for the event that the designated algorithm becomes obsolete.
It is actually anticipated by the author that almost no USENET articles will come with a Cert header. Rather, those headers would be placed on articles by authors, moderators and other article sources, and then sent (perhaps via E-mail) to special "certificate collapse" daemons, which read and check the certificates, and re-sign the article with just one short "Signed" header. The daemon's keys would be known to all sites, and be designated as all-powerful by those sites.
Certificate collpase could also be done redundantly by main USENET hubs. The hubs, if they have top level keys, could do it directly, or they could use live connections to servers that have top level keys to collapse un-collapsed articles that arrive. The hub system matches the way USENET works today, though some articles will traverse portions of the network without collapse (and thus larger in size.)
This means it is possible the spec could allow a site to not have to implement any certificate processing unless it intends to particpate in private subnets which will have private certifying needs.
Here is the form a typical certificate for an ordinary user might have.
Cert: U 1;ca2@ca.com;;xxxxxxxxxxxxxxxxxxxxxxxxxxx,xxxxxxxxxxxxxxxxxxxxxxxxxxx; Key yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy, zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz; U %f;Date 30 Jan 98;Life 128;Keyname %f
The "xxx...,xxx..." is the signature of the certificate, signed by authority "ca2@ca.com"
The "yyy..." and "zzz..." are the owner's key.