An article to be signed MUST be generated using the MIME "multipart/signed" structure as defined in RFC1847, with the following restrictions and added rules.
A MIME multipart/signed consists first of a body part, and then a signature part.
When setting the MIME boundary for a multipart/signed, the agent performing the signing SHOULD pick a boundary that will be visually unobtrusive to users of newsreader that do not support MIME. As such, a boundary of "-" (Ie. "---" when in the body) or similar is recommended.
The Content-Type: header MUST have an attribute of "application/usenet-sign". The "Micalg" attribute MUST be "sha1" at present. Should any options become enabled that affect hashing, they will be present here, however they may only be used within cooperating subnets. Systems which find attributes here they do not understand may attempt to verify the signature, but if it does not verify, the articles MUST be treated as though it were unsigned.
MIME headers at the start of the body SHOULD be kept to a minimum. For ordinary articles of "text/plain" in the standard character set that thus need no MIME headers, the MIME header at the start of the body part SHOULD thus be blank.
The body part consists of its MIME headers, a blank line, the text of the article, an optional personal signature, a header delimiter, and then the "signed headers" of the article.
The signed headers are items that belong in the header of the article but which are digitally signed to provide security and authentication. As old software requires that many headers be present in the primary (unsigned) header, this will involve in many cases duplications of headers. The MIME headers are not duplicated in the signed header block, though the master MIME-Version header may be.
If a header is present in the signed section and the primary (unsigned) header, it MUST be identical. While generally such a mismatch would cause rejection of the article, software MAY elect to use the signed header but MUST NOT use any primary header which differs from the signed header.
Any header found in the primary header that is not either:
SHOULD be treated as a header not generated by the signer of the article, and possibly not to be trusted.
The headers in the signed header are invariant and may not be changed or re-ordered.
The boundary of the personal signature from the text of the article SHOULD be delimited by the MIME boundary of the encloding mime block, but prefaced with "==" instead of "--". If this boundary is NOT present, readers MAY search for the last occurence of the personal signature delimiter ("-- ") but this is deprecated.
The boundary between the article text and signed header shall be delimited by the MIME boundary of the enclosing MIME block, but prefaced with "__" instead of "--".
This means that when selecting a MIME boundary for a multipart/signed, signing tools MUST pick a boundary such that none of the lines "--<boundary>", "__<boundary> or "==<boundary>" exist within the body (or signed header) of the article.
The special header "May-Ad" MAY be present in the signed header. This special header consists of a comma delimited list of prefix strings which match header names that may be found in the primary header.
This indicates that any header matching (case-insensitive) one of those prefix strings was presumably added with the permission of the signer. For example, a signer may be willing to allow another party to generate a Message-ID for their message.
The special header "Powers" is used by agents which collapse certificates and re-sign articles. Such a header will contain information in the certificate encoding language defining attributes that were associated with an original signer and present in his or her certificates before they were collapsed. If no collapse is done on non-basic articles (ie. messages that are other than a post or cancel or perhaps named article) then this header could be removed from the spec.
The signature block consists of any MIME headers, a blank line, and then signature information. The signature information itself is provided in USENET header style.
Fields in the Signature Block may consist of:
The headers "Signed" and "Cert" and "Powers" were defined in the original proposal and will be moved here if this plan is preferred. The optins, primarily affecting hashing, would not be valid in such a system
A push is being made to extend the multipart/signed type to allow not just 2, but several parts, with the first parts being the signed parts and the last part being the signature. However, until such time, the only conformant means to lay out an article that is not of a text type is as follows:
The first part of the multipart/signed shall be a MIME multipart/related, consisting of two parts.
The first part of the multipart related shall be the article. If the article is itself a multipart, there will of course be another multipart within the structure. The proper MIME headers for the article's unusual content-type will be provided.
The second part of the multipart/related shall be the block of signed headers. They shall be of the default type text/plain.
As usual, the second part of the multipart signed will sign the entire first part, namely the multipart/related.
Here is an example of a signed article, though the signature itself is a meaningless string:
Path: foo.com:bar.org:clari.net%originator-info From: firstname.lastname@example.org (Frodo Baggins) Subject: Hello there Message-ID: <email@example.com> Newsgroups: alt.fan.rings Date: Mon, 09 Feb 1998 06:57:31 GMT Mime-Version: 1.0 Content-Type: multipart/signed; boundary="-"; protocol="application/usenet-signed; micalg="sha1"
Hi folks. This message is from me, and you know it!
==- Frodo Baggins. "The road goes ever on." __- From: firstname.lastname@example.org (Frodo Baggins) Subject: Hello there Message-ID: <email@example.com> Newsgroups: alt.fan.rings Date: Mon, 09 Feb 1998 06:57:31 GMT --- Content-type: application/usenet-signed
Signed: U; +1; ; xjxxjxxjxxjxxjxxjxxjxxjxxjx, o48o48o48o48o48o48o48o48o48 Cert: U; 1; http://sign.com/gandalf.txt; ; asadf98wer08asd08fwer098098, asd0f980a8d09d8f0a98adf0ljl; Keyname %f; Key 0980asd0980asdf09ad80a8d08dfad09fxvxcv098d 0980jlkjlj234lkj2l34j2l34jk2l3jk4lk34jlkj3j; U %f; Relate id-weak; Realname "%F"; [Moderator][G alt.fan.rings]; Date 9 Feb 98; Life 365 ---
As we see in this example, for users of newsreaders only supporting MIME, the only intrusion is the extra "---" at the start of the article, and of course lots of extra stuff at the bottom.
Most of the headers are duplicated, as will normally be the case.
This article is signed with an certificate. Normally it is expected that certificate collapse would be used, and no "Cert" header would be needed.
The Signed: header indicates the signature key is found in Certificate #1. The signature itself is two 27 character base64 strings.
The Certificate here is typical, with one extra tag. In common use, people with tags giving extra powers would probably get multiple certificates, for the combinations of attributes they wish to use, so that they need not use a full certificate with all attributes at all times. Certification authority daemons can readily shrink an existing certificate down to a subset of parameters at any time.
In this certificate we see, in order
This is here only because this certificate happens to be an identity certificate containing the keyholder's "real name." More common are attribute certificates which don't have a real name, and use different means to verify the attributes they certify.
As noted, Frodo might have another more ordinary certificate, with no identity information, and no moderator attribute, for postings to other groups. Or he could use this one.
Do people like varying the mime seperator, or would you prefer either another seperator (can we put on on the content-type line or does this force another mime header in the first part?) Or should we put the delimiting info at the end of the signed header -- requires parsing backwards
As you can see, I have come up with another way to formalize personal sigs, saying *if* it's a mime article, use this.
This follows the RFC spec, but is bulkier and messier than the in-the-headers form I proposed.