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

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:

> 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 mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview