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

Russ Housley <> Fri, 12 July 2013 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 211E421F9FE7; Fri, 12 Jul 2013 14:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aMn5DQJ4MW0T; Fri, 12 Jul 2013 14:57:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D98BB21F9FE9; Fri, 12 Jul 2013 14:57:43 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTP id A362AF240B0; Fri, 12 Jul 2013 17:58:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RgeRjoHDeLQ6; Fri, 12 Jul 2013 17:57:26 -0400 (EDT)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id CEB02F2408B; Fri, 12 Jul 2013 17:58:27 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <>
In-Reply-To: <>
Date: Fri, 12 Jul 2013 17:57:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Tero Kivinen <>
X-Mailer: Apple Mail (2.1085)
Cc: IESG <>, IETF SecDir <>
Subject: Re: [secdir] Secdir review of draft-housley-ltans-oids-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2013 21:57:49 -0000


Thanks for the review.

There are two ASN.1 flavors, and the documents provide a module for each of them.  Yes, the ITU-T really did make a second flavor without considering backward compatibility.  People that implement with ASN.1 know which flavor their tools use.

I do not think that the document that established a registry ought to point to the security considerations of the protocols that make use of the registry.  A protocol implementor needs to read the protocol document.

Since the IESG designates all experts (and may also remove them), Expert Review is sufficient.


On Jul 12, 2013, at 5:40 PM, Tero Kivinen wrote:

> 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.
> -- 
> _______________________________________________
> secdir mailing list
> wiki: