[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.
- [secdir] Review of draft-denenberg-mods-etc-media… Rob Austein
- Re: [secdir] Review of draft-denenberg-mods-etc-m… Ray Denenberg, Library of Congress