[secdir] Review of draft-denenberg-mods-etc-media-types-01

Rob Austein <sra@hactrn.net> Wed, 28 April 2010 15:01 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7AA3A6B65; Wed, 28 Apr 2010 08:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sblHC+l4gsYl; Wed, 28 Apr 2010 08:01:11 -0700 (PDT)
Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id BC9413A6B88; Wed, 28 Apr 2010 07:57:32 -0700 (PDT)
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 26EC128431; Wed, 28 Apr 2010 14:57:18 +0000 (UTC)
Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D230322831; Wed, 28 Apr 2010 10:57:17 -0400 (EDT)
Date: Wed, 28 Apr 2010 10:57:17 -0400
From: Rob Austein <sra@hactrn.net>
To: iesg@ietf.org, secdir@ietf.org
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20100428145717.D230322831@thrintun.hactrn.net>
Cc: draft-denenberg-mods-etc-media-types.all@tools.ietf.org
Subject: [secdir] Review of draft-denenberg-mods-etc-media-types-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 15:01:12 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This draft is a non-WG standards track submission whose sole purpose
is registration of four MIME types for use with XML schemata developed
by the (US) Library of Congress.  The document has a number of
nit-level issues which the sponsoring AD proposes to have fixed at the
RFC Editor stage, so I won't elaborate on them here, other than to
note that the document includes no Security Considerations section.

The MIME type registration templates that make up the body of the
document all reference the Security Considerations from RFC 3023,
which is a general (and, necessarily, rather vague and alarming)
discussion of potential security issues that might be found in any XML
document.  XML schemata are encoded as XML documents, so this
reference is correct, as far as it goes.  Nothing about XML schemata
in general or these schemata in particular.

Just about everything referenced by this document is external to the
IETF, it's either a W3C standard, work being done by the Library of
Congress, or in the case of the SRU specification, OASIS.  It's not
obvious to me why this document has been proposed for the IETF
standards track, given that MIME type registrations do not appear (as
far as I can tell) to require an RFC at all.  Informational status
might be more appropriate, but I'll leave that up to the IESG.

I don't see any security issues with the MIME type registrations per
se.  I don't know enough about the (non-IETF) protocols sitting behind
the proposed MIME types to have an informed opinion on them.

The one (non-security) part of this that I don't understand is why a
separate MIME types is necessary for each individual schema.  This
seems weird to me, but perhaps it's just the way things are done over
in Apps.  I don't consider this a blocking issue, just odd.