[secdir] Secdir review of draft-housley-ltans-oids-00

Tero Kivinen <kivinen@iki.fi> Fri, 12 July 2013 21:40 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B27F11E8111; Fri, 12 Jul 2013 14:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3RayeOFYzwE; Fri, 12 Jul 2013 14:40:26 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7153F21F9FFE; Fri, 12 Jul 2013 14:40:26 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6CLeI35001027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Jul 2013 00:40:18 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6CLeFpR002904; Sat, 13 Jul 2013 00:40:15 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20960.30655.526275.938616@fireball.kivinen.iki.fi>
Date: Sat, 13 Jul 2013 00:40:15 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-housley-ltans-oids.all@tools.ietf.org
X-Mailer: VM 7.19 under Emacs 24.3.1
X-Edit-Time: 16 min
X-Total-Time: 15 min
Subject: [secdir] Secdir review of draft-housley-ltans-oids-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 12 Jul 2013 21:40:27 -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 document fills up the LTANS ASN.1 OID arc in the IANA registry.
It adds some values and points them to published RFCs, and also
reserves some values where there was never RFC published for those
protocols.

For some reason some of values include two OIDs, one for the 1997  and
another 1988 ASN.1 syntax. I do not know enough of LTANS to understand
why this distinction needs to be made in the OIDs themselves, I only
assumed this affected the compilers and textual descriptions of the
ASN.1 stuff, but perhaps OIDs here are used to indicate some ASN.1
text module or something.

The security considerations section is very short:

   This document populates an IANA registry, and it raise no new
   security considerations.  The protocols that specify these values
   include the security considerations associated with their usage.

While this is true, it might be helpful to add references to the
actual protocols it is refering here. The list of relevant RFCs can be
found in the IANA considerations section, but adding pointers here
might be helpful. I have not checked out whether the security
considerations sections in those documents contain anything useful.

One odd thing is that all registries are marked as "Expert Review or
IESG Approval", but which one of those is used? Is this supposed to
mean that if IESG appoints a designed expert for these, then he does
checks the updates, but if not, then IESG approval is needed? Or is it
mean to say that even when there is designated expert, the IESG and
ignore him and do the approval themselves (in which case I Would ask
what is the point of having the designated expert)?

Usually there is only one way of doing the IANA updates.
-- 
kivinen@iki.fi