Re: [secdir] draft-ietf-karp-crypto-key-table-07

Sam Hartman <> Fri, 19 April 2013 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A07C21F919D; Fri, 19 Apr 2013 07:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sAJMHn0Nee3q; Fri, 19 Apr 2013 07:22:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D0B2B21F90AC; Fri, 19 Apr 2013 07:22:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF37D202AC; Fri, 19 Apr 2013 10:22:25 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Su-7LzSh6lh; Fri, 19 Apr 2013 10:22:25 -0400 (EDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS; Fri, 19 Apr 2013 10:22:25 -0400 (EDT)
Received: by (Postfix, from userid 8042) id 6874F4499; Fri, 19 Apr 2013 10:22:26 -0400 (EDT)
From: Sam Hartman <>
To: "Klaas Wierenga \(kwiereng\)" <>
References: <>
Date: Fri, 19 Apr 2013 10:22:26 -0400
In-Reply-To: <> (Klaas Wierenga's message of "Fri, 19 Apr 2013 14:05:22 +0000")
Message-ID: <>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "" <>, The IESG <>, "" <>
Subject: Re: [secdir] draft-ietf-karp-crypto-key-table-07
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Apr 2013 14:22:32 -0000

>>>>> "Klaas" == Klaas Wierenga (kwiereng) <>; writes:

    Klaas> * 1 Intro

    Klaas> What is conceptual about it? Isn't this supposed to be a
    Klaas> specification of the format for a real database?

It's exactly to avoid getting into a discussion of normalization and
most of the comments you discuss in your comments on section two that we
want this to be conceptual.
We don't want to go there because there is no interoperability advantage
to specifying things at that level of detail .

    Klaas> * 2 Conceptual Database Structure

    Klaas> introductory paragraph: it is hard to grasp why or why not
    Klaas> you want to have the same key appear twice without
    Klaas> understanding what the format of the database will look
    Klaas> like. So I think you should move that part of the first
    Klaas> paragraph to below the column definition.

    Klaas> Peers: hmm, so now you have a multivalued column of arbitrary
    Klaas> length? What is the separator? And do you expect
    Klaas> normalisation into separate tables to happen?

Since we're a conceptual database we don't need to answer any of that:-)
To describe the key selection algorithm we need to say it's a set.
To have interoperability within protocols we need each protocol to
define the format of a member of the set, but *not* how to represent a
set as a whole.

If we defined a netconf schema we might well need to define  how to add
and remove members from this set.

The natural way to do this will be vendor specific; the way I'd define a
IOS-style CLI would be very different than what I'd do for something
grabbing configuration from an SQL database.

    Klaas> Protocol: So here you want only a single security protocol,
    Klaas> resulting in rows with the same key but different
    Klaas> protocols. Resulting in a more complex lookup but no
    Klaas> normalisation into separate tables necessary, I'd say best to
    Klaas> choose one solution and stick to it.

In general, the protocol value is very likely to influence what keys are
We also want to strongly discourage the same key being used between