[secdir] Secdir review of draft-johansson-loa-registry-04

Vincent Roca <vincent.roca@inria.fr> Tue, 03 April 2012 09:20 UTC

Return-Path: <vincent.roca@inria.fr>
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 5E79E21F8691; Tue, 3 Apr 2012 02:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Level:
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 nnj96vgaqD6P; Tue, 3 Apr 2012 02:20:19 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id F271A21F868C; Tue, 3 Apr 2012 02:20:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,362,1330902000"; d="scan'208";a="152448324"
Received: from ral057r.vpn.inria.fr ([128.93.178.57]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Apr 2012 11:20:16 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 03 Apr 2012 11:18:29 +0200
Message-Id: <2BAEF3F1-9FDD-4D45-B03D-57A12CAF515F@inria.fr>
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-johansson-loa-registry.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [secdir] Secdir review of draft-johansson-loa-registry-04
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: Tue, 03 Apr 2012 09:20:20 -0000

Hello,

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.

I have two comments WRT to section 7: 

1/ It is said:
  "An implementor of MUST NOT treat the registry as a trust framework or
  federation [...]"

As I understand the IANA registry is a record of LOA definitions that are
part of a trust framework. So that's a different concept, I agree. But why
is this sentence in the "Security Considerations" section? It could be moved
to section 3 for instance.

2/ The rest of the sentence is confusing IMHO:
  "An implementor [...] MUST NOT make any assumptions about the properties of
  any of the listed level of assurance URIs or their associated trust
  frameworks or federations based on their presense in the IANA registry."

Do you mean that the fact an IANA registry exists, by itself, does not garranty
the trust framework actually provides the expected security features (i.e. the
IANA registry is merely a definition record)?
I don't like the term "any assumption". If a LOA tells me I can achieve some
security level by using it, I'll first **assume** it's true and in a second step
I'll verify it's indeed the case.


Typos and general comments:

** section 7:            
- In the first sentence, something is missing:
       "An implementor of MUST NOT"
Of what?

- Later:
       "...based on their presense in the IANA registry"
Don't you mean presence (with a "c")?


** section 3.1: in the example, it is said:
                  "Defines Level 1 of FAF"
I didn't understand what FAF stands for. I think you'd better avoid using
an acronym here.

** section 3. There's a missing "." before "This" in:
  "URI:  A URI referencing a Level of Assurance Profile This is the
     registry key."


Regards,

Vincent