[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
- [secdir] Secdir review of draft-housley-ltans-oid… Tero Kivinen
- Re: [secdir] Secdir review of draft-housley-ltans… Russ Housley
- Re: [secdir] Secdir review of draft-housley-ltans… Jeffrey Hutzelman