Approved header field content (was: Protocol changes in draft-allbery-usefor-usepro-00)

[Russ Allbery <[e-mail]>]

Charles Lindsey <[e-mail]> writes:
> Russ Allbery <[e-mail]> writes:
>> Charles Lindsey <[e-mail]> writes:

>>> 30. [-1] (5.2) Nothing said about content of Approved header.

>>> Surely, it SHOULD identify the person/identity/role of the issuer, ...

>> Intentional change.

>> The content of the Approved header serves no protocol purpose, and
>> USEFOR already adequately covers the definition of its content.
>> Control message authorization is done on the basis of the Sender or
>> From header (preferrably in combination with a digital signature).

> It asserts that this is an "authorized" message (just what "authorized"
> means is a separate issue which I shall raise later).

The description in USEFOR is:

   The Approved header field indicates the mailing addresses (and
   possibly the full names) of the persons or entities approving the
   article for posting.  Its principal uses are in moderated articles
   and in group control messages; see [I-D.ietf-usefor-usepro].

The Netnews protocol currently does not deal with authorization at all (an
obvious flaw noted in Security Considerations).  Any authorization
information you want to use has to be derived from the underlying
transport protocol or from unstandardized extensions such as digital
signatures.

> As such, it is pretty pointless unless it identifies the entity that is
> authorized, and all news servers that I know of can be configured with
> the identity that is to be recognized for each hierarchy.

If you're referring to group control mesages, said identity is checked
against the *From or Sender* header field, not the Approved header, at
least in INN.  INN ignores the contents of the Approved header.  I don't
know if C News uses the contents of the Approved header field for control
message permissions, but my impression from having maintained control.ctl
for some years is that most everyone uses From/Sender.

> Of course, it really needs to be digitally signed to make it effective,
> but that again is a separate issue.

> I think the WG early on took the view that the Approved header would
> simply fall into disrepute if one could always get away with
>    Approved: kibo
> and that it therefore needed some firmer language (digitally signed in due
> course). I remain of that view.

We can add firmer language when there's some meaning to the contents, such
as when digital signatures are added.  Right now, placing any stricter
requirements would contradict existing practice and be pointless since
there's no possible protocol check on the contents of Approved.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>