Re: URN request for HbbTV

[Ted Hardie <[e-mail]>]

Hi Paul,

I took a quick look at this, and there is one potential concern.  The draft
currently says:

Declaration of structure:

      URNs assigned by HbbTV will have the following structure based on
      the organizational structure of the resources specified in the
      HbbTV specifications:

         urn:hbbtv:<NSS>

      where the syntax of "<NSS>" is specified in Section 2.2 of the
      URN Syntax requirements ([RFC2141]).

First, this is slightly oddly stated, since it would be much clearer to say
that the NSS is 1*<URN chars>; second, this implies but does not state that
the URN is not structured within the namespace.  There certainly are
unstructured URNs, but the examples you give look very structured:

      urn:hbbtv:dash:profile:isoff-live:2012
      urn:hbbtv:sync:timeline:ebu-tt-d
      urn:hbbtv:config:oitf:oitfCapabilities:2014-1

Perhaps you would prefer to simply state that first order structure is an
hbbtv application as set out in TS 102 796 and that subsequent elements
relate to the application?

As an aside unrelated to the URN NID matters, when reviewing the ETSI
documentation, I was quite concerned to note the following:

11.2 TLS and SSL Root Certificates
A list of root certificates is maintained at
http://www.hbbtv.or/spec/certificates.html. The policy by which this list
has been derived is outlined in annex D. Terminals shall trust all root
certificates identified as mandatory and may support those certificates
identified as optional on that list, subject to the conditions in this
clause. Terminals should not trust any other root certificates.

NOTE: Including root certificates that are not on the list increases the
risk of a man in the middle attack if those root certificates have not been
audited to a similar or greater level than those on the list.

This mechanism of proposing a set of root certificates is dangerous:
first, the site at which the list is maintained is not itself protected by
TLS; second, devices which are implementing this specification in concert
with other applications will end up with the union of this list and their
own internal lists.  This increases, rather than decreases, the risk.

regards,

Ted Hardie




On Tue, Sep 2, 2014 at 5:08 AM, Paul Higgs <[e-mail]> wrote:

>  Hello
>
>
>
> In accordance with the instructions RFC 3406, the HbbTV Association kindly
> requests IETF to approve the assignment of “hbbtv” as a Formal Namespace.
>
> The draft application is draft-higgs-hbbtv-urn-00,
> http://www.ietf.org/id/draft-higgs-hbbtv-urn-00.txt
>
>
>
> Thanks in advance
>
>
>
> [image: Ericsson] <http://www.ericsson.com/>
>
>  *PAUL HIGGS *
> Technical Solutions Manager
> Ericsson Inc
>
>
> *Ericsson*
> 6 Concourse Parkway, suite 400
> Atlanta, GA 30075, United States of America
> Phone [phone]
> [e-mail]
> www.ericsson.com
>
>
>
> [image: http://www.ericsson.com/current_campaign]
> <http://www.ericsson.com/current_campaign>
>
>
>
> Legal entity: Ericsson AB, registered office in Kista, Sweden. This
> Communication is Confidential. We only send and receive email on the basis
> of the terms set out at www.ericsson.com/email_disclaimer
>
>
>