[icnrg] recursive key Lookup in CCNX

Ken Calvert <calvert@netlab.uky.edu> Sun, 26 April 2020 23:36 UTC

Return-Path: <calvert@netlab.uky.edu>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21DE3A164A for <icnrg@ietfa.amsl.com>; Sun, 26 Apr 2020 16:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netlab.uky.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjZsftz8YecH for <icnrg@ietfa.amsl.com>; Sun, 26 Apr 2020 16:36:55 -0700 (PDT)
Received: from mail.netlab.uky.edu (mail.netlab.uky.edu [128.163.140.42]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069473A1648 for <icnrg@irtf.org>; Sun, 26 Apr 2020 16:36:54 -0700 (PDT)
Received: from culp.local (cpe-96-29-182-38.kya.res.rr.com [96.29.182.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netlab.uky.edu (Postfix) with ESMTPSA id A8F6F1813B for <icnrg@irtf.org>; Sun, 26 Apr 2020 19:36:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netlab.uky.edu; s=default; t=1587944211; bh=xF7n5er/upmwiCWRo7cjgOqcZ7xJBV/ODJkPNchHnD0=; h=From:Subject:Date:To:From; b=d+Edc1bDoClXU31nzbcJG4DoUwZVrJdnqPbSCNvf4ZN/6Q7qTnXPVPij1/d0UJDDY rC0xjtU0pbJZ48353r0Sk0ZhFWtJRz7Rhqs9GHFt+br2WvEM24LPo4FfcvhM6+go9B vQeAGxj8V0C4cKrUYX+GdTnOixLE3XhR/rMwUHQ0/bS/Xx95GZO58r7KnQdrSfQ7xE d5tUYe5oWTNcYeKFDPCgRgsKC+yVQwPjqpKyy1AHm3L8DH0RKck6vO3m12Zx6dREBx jrYesZ+umhQy+IcchA679whDBdnlLp+7dM8Muf+9x/SC3VrMorzX6LuTxQIFzSrORk 6XSZgTPcAwumw==
From: Ken Calvert <calvert@netlab.uky.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Message-Id: <91F2CCB5-F962-4DEF-A8C2-B8BCCD32F185@netlab.uky.edu>
Date: Sun, 26 Apr 2020 19:36:48 -0400
To: icnrg@irtf.org
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/1kHBtV0G16Shs4YXCGCxPMqjUmE>
Subject: [icnrg] recursive key Lookup in CCNX
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2020 23:36:57 -0000

Why is recursive key lookup prohibited in CCNx 1.0?

I am really surprised that Section 8.1 of RFC 8569 says "we do not allow for recursive key lookup".

First, this seems to dictate a single policy for all applications using the CCNx network layer. That seems like a Big Deal, so I would expect to see some reason given in the RFC, but there's no justification.

I always thought being able to just "turn the crank" and retrieve the key that signed a content object,then the key that signed that, and so on (as long as the names match a trust schema, as described in the Yu et al ICN '15 paper) until you reach a trust anchor was one of the very best things about CCN/NDN.
What am I missing?

Related question:  What is the essential security difference between an X.509 certificate and a KeyLink?  If there's no difference, why require that trust chains be of length one, and end in X.509 certs (or known keys)?  And if there is a security difference, why define a separate Key object at all?

Thanks,

Ken