Re: [netconf] draft-ietf-netconf-trust-anchors and unconstrained public keys

Kent Watsen <kent+ietf@watsen.net> Thu, 28 April 2022 01:08 UTC

Return-Path: <010001806db66855-ed0c9dda-0ae1-49ae-97cf-a20db73e23f8-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0368C15E6EC for <netconf@ietfa.amsl.com>; Wed, 27 Apr 2022 18:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN-Qbnn7v0vT for <netconf@ietfa.amsl.com>; Wed, 27 Apr 2022 18:08:34 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E90C15E6EB for <netconf@ietf.org>; Wed, 27 Apr 2022 18:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1651108112; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=gFTwof11dZMOK5REyQRcDD0leTbSdpoTrew6y5iSE28=; b=P484MK9Ro//KwDN9ELCiEXuG2ue8xvuIhn/HnhHeQ/LpLMqcCl1vLVa2qr2KkDXk XMcDD9W+yrVTw3Lgbcjka09mTVCp156SbQxSy3kS/ZYutktil6BXRJJAx28X8znDIKT weSskbDVkAeGK3x5eGv0grNfwKFASx+yMuzy/2Xk=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001806db66855-ed0c9dda-0ae1-49ae-97cf-a20db73e23f8-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DFB0721E-9DC0-44D9-91E3-6550BBC3F8A3"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Thu, 28 Apr 2022 01:08:32 +0000
In-Reply-To: <B2403E78-407C-4DDA-A089-7A7F4DC45DEC@redhoundsoftware.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Carl Wallace <carl@redhoundsoftware.com>
References: <B2403E78-407C-4DDA-A089-7A7F4DC45DEC@redhoundsoftware.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.04.28-54.240.8.96
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/cuMDW32GENF2L9lMLxqsUWjtDus>
Subject: Re: [netconf] draft-ietf-netconf-trust-anchors and unconstrained public keys
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 01:08:36 -0000

Hi Carl,

It's always nice to see authors promote their drafts!  ;)

> Section 4.2 states:
> 
> 	This module also enables the configuration of certificates, where each certificate may constrain the usage of the public key according to local policy.
> 
> Assuming local policy means relying party defined policy, this won't work unless the signature on the certificate is ignored. Defining or using a structure in this draft that supports local application of constraints may help avoid reliance on public keys that are unnecessarily broad. RFC 5914 defines a structure that allows for associating constraints with raw public keys or certificates. The default representation of the TA structure in 5914 is simply a certificate, so it'd fit here pretty easily. Historically, trust anchors have been essentially unconstrained but that may not always be the case going forward. 

Reading RFC 5914, the impact of what you're suggesting seems to be that the truststore should also contain a list of TrustAnchorInfo structures...is this correct?

Can this be augmented into the truststore by a future effort, or does it have to be in the first release of the truststore format?

I've never heard of RFC 5914 before, is it widely used?

Kent // author