Post-facto reporting of media type security considerations

[ned.freed at mrochek.com]

> [This message has been sent to the ietf-types mailing list with a courtesy
> copy to IANA (as IANA issues are raised); I have suggested responses
> be directed to the ietf-types list]

> There are some media types for which security issues have become known
> since the original type registrations. RFC 2048 has a provision for reporting
> such issues:

> 2.2.6.  Security Requirements
> [...]
>    The security considerations section of all registrations is subject
>    to continuing evaluation and modification, and in particular may be
>    extended by use of the "comments on media types" mechanism described
>    in subsequent sections.

> and

> 2.4.  Comments on Media Type Registrations

>    Comments on registered media types may be submitted by members of the
>    community to IANA.  These comments will be passed on to the "owner"
>    of the media type if possible.  Submitters of comments may request
>    that their comment be attached to the media type registration itself,
>    and if IANA approves of this the comment will be made accessible in
>    conjunction with the type registration itself.

> RFC 2048 was issued nearly eight years ago, so I wonder if the procedure
> listed there is still considered appropriate.  In particular, I have several
> questions that members of this list might be qualified to answer:

> 1. Has this mechanism ever been used? [I have scanned several dozen
>     media registrations, but could find no example of anything that
>     looks like commentary attached to the media type registration]

AFAIK nobody has ever used the commentary mechanism. Media type registrations
have been revised on several occasions, however, without incident or
undue fuss.

> 2. Media types can be registered via a textual form alone, or in an RFC.
>     It seems unlikely that IANA can attach comments to an RFC, as RFCs
>     are supposed to remain unchanged once published.  There is a
>     somewhat obscure errata page, but that's managed by the RFC
>     Editor, not IANA.  I therefore believe that the RFC 2048 procedure
>    as written is not entirely adequate. Comments?

I disagree. The process for revising an RFC is to issue a revised RFC. I see no
reason to create yet another process to put this information elsewhere.

> 3. Does IANA itself currently have the expertise to evaluate accuracy
>     and applicability of submitted comments?  If not, who will IANA
>     turn to for advice, and would it be prudent/advisable/acceptable
>     for "submitters of comments" to copy them (assuming that
>     submission of comments to IANA is still considered the applicable
>     procedure)?

The IANA has the good sense to appoint expert reviewers as needed. There
are literally dozens of examples of this "running code".

> 4. The RFC 2048 text mentions that comments will be forwarded to the
>     media type "owner", and mentions IANA approval of comments.
>     What procedures exist for conflict resolution?

Conflict resolution mechanism are practically impossible to define and
get right in the absencce of experience with actual conflict. And since
this particular mechanism hasn't even been used once in the past 8 years
I view it as highly inappropriate to specify such a mechanism at this
time.

>     For example, suppose
>     that the submitter of a textual registration which claimed "no
>     known security issues" believes in security through obscurity (or
>     is constrained by such a corporate employer's policy) and objects
>     to having security comments attached to the registration (assume
>     that substantial third-party corroboration of real security issues
>     is provided with the comments); does the type "owner" have
>     final say in the matter, does IANA have the authority to override
>     such non-substantive objections, is there provision for IETF AD or
>     IESG review if necessary, etc.?

The IANA gets to decide, and if necessary the decision could be appealed
using the normal appeals process. Again, there's no need to create
additional process and formalism.

				Ned