[secdir] Secdir last call review of draft-ietf-secevent-token-09

Russ Housley <housley@vigilsec.com> Fri, 20 April 2018 18:03 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3701212D88B; Fri, 20 Apr 2018 11:03:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Russ Housley <housley@vigilsec.com>
To: secdir@ietf.org
Cc: draft-ietf-secevent-token.all@ietf.org, ietf@ietf.org, id-event@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152424742315.3484.7625515486296411114@ietfa.amsl.com>
Date: Fri, 20 Apr 2018 11:03:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/WxUCOnWNFq5RnfCXFoA9ilVwMZY>
Subject: [secdir] Secdir last call review of draft-ietf-secevent-token-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 20 Apr 2018 18:03:43 -0000

Reviewer: Russ Housley
Review result: Has Issues

I 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 authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-secevent-token-09
Reviewer: Russ Housley
Review Date: 2018-04-20
IETF LC End Date: unknown
IESG Telechat date: 2018-05-10

Summary: Has Issues

Major Concerns

I do not understand the first paragraph of Section 3.  I made this
comment on version -07, and some words were added, but I still do
not understand this paragraph.  I think you are trying to impose some
rules on future specifications that use SET to define events.  Let me
ask a couple of questions that may help.  I understand that a
profiling specification MUST specify the syntax and semantics for a
collection of security event tokens, including the claims and payloads
that are expected.  What MUST a profiling specification include?  What
MUST a profiling specification NOT include?