Brad Templeton Internal Page

Digital Signature using MIME

Digital Signature using MIME

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:

  1. A variant header, namely Path:, Xref: or any header beginning with "US-" in its prefixes.
  2. Present in the signed header, or
  3. A MIME header affecting the enclosing MIME block, or
  4. Named as a valid add-on header through the use of the "May-Ad" signed header

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.

Boundary

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.

Special Headers

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.

Signature Block

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:

  1. Signatures, which sign the body block. There can be more than one signature. (For example, a poster's and a moderator's)
  2. Certificates, which authenticate other public keys.
  3. Options controlling the signature calculation process. (Note that options controlling the hashing process must appear in the MICALG attribute to allow one-pass verification of articles.) Should such option headers begin with an exclamation point, this indicates that software testing the signature MUST understand the header, or consider the articles as unsigned. For example, an option changing the signature algorithm from DSA to RSA would need to use such a tag. All other options MAY be ignored if not understood.

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

Articles that are not of text type

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.

Example

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: fbaggins@shire.midearth.org (Frodo Baggins) 
Subject: Hello there 
Message-ID: <123@shire.midearth.org> 
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: fbaggins@shire.midearth.org (Frodo Baggins) 
Subject: Hello there 
Message-ID: <123@shire.midearth.org> 
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

1
An indication that this is certificate #1, as referred to in the +1 in the signature.

http://sign.com/gandalf.txt
This is the name of the signer's key, not strictly a URL. The signer is a certificate authority. Most sites will have its key on record locally. If not, the URL can be used to fetch the key, after which it should probably be stored.

The signature
Two 27 character strings represent two 160 bit numbers, which are the SHA-1 signature in base64 of the certificate

Keyname
Provides a name for this key if it is to be stored. The macro '%f' means "insert the E-mail address from the From line of this article" and so the user's key name is their e-mail address, which is typical.

Key
A base64 encoding of the author's public key. In this case a 512 bit key.

U %f
The '%f' macro is used again. This attribute is thus expanded to "U fbaggins@shire.midearth.org" which means the keyholder is enabled to post or cancel as that user. (Which doesn't mean the keyholder is that person, but they can act as them.)

Relate
Indicates the relation of the certifier and the keyholder. In this case, it means that Frodo showed Galdalf some typical ID, such as his Driver's licence, and that some other means was used to confirm the E-mail address, probably a challenge-response.

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.

Realname
As noted, this is an identity certificate. The '%F' expands to the full name from the comment of the From field, for compactness, since almost always they will match. So it will be hashed as 'Realname "Frodo Baggins"'

Moderator
Frodo has a special attribute -- moderator powers, but only in messages posted to "alt.fan.rings." That means that Frodo's key can be used to approve postings, issue various control messages and so on but only in that newsgroup.

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.

Issues

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.