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

From: Tero Kivinen <[email-masked]>
Date: Sat, 13 Jul 2013 00:40:15 +0300

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.
-- 
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2013 17:57:40 -0400

Tero:

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.

Russ

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

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview