Re: [netconf] draft-ietf-netconf-trust-anchors, deleting or:system certificates

Kent Watsen <kent+ietf@watsen.net> Mon, 18 November 2019 17:44 UTC

Return-Path: <0100016e7f9d6131-c242e4a9-f6a5-4488-92b9-998108b349a6-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 25D92120074 for <netconf@ietfa.amsl.com>; Mon, 18 Nov 2019 09:44:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMbmsPxftLC2 for <netconf@ietfa.amsl.com>; Mon, 18 Nov 2019 09:44:12 -0800 (PST)
Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28E3120019 for <netconf@ietf.org>; Mon, 18 Nov 2019 09:44:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574099051; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LXNjhmucY/VUVZbzHuWy2PQ3Mw7F2XDXNadlpvTVshg=; b=UkqC43KTvmM5sxAyfRWqAOMEBpLiMhTDHZ+2+55gCT/T6Y7EWlj6ius2uceQezyp DS5LuVh2zmJ9pZfTh60CQZuTQLr5cmxqMtPhRNvI7BxSM4C1TA1vfYqNENxKmIfUXfy brf971b6nB8A6J8U4QVRufbUQxYe2WJnp9pHz248=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016e7f9d6131-c242e4a9-f6a5-4488-92b9-998108b349a6-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7898C32F-3E24-4659-B885-45A324A398FB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 18 Nov 2019 17:44:11 +0000
In-Reply-To: <MN2PR11MB43660F403072E460AF2FE12AB54D0@MN2PR11MB4366.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
References: <MN2PR11MB43660F403072E460AF2FE12AB54D0@MN2PR11MB4366.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.18-54.240.8.64
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0IeKUOQAmtFkTbQ0EqQFjGQccvY>
Subject: Re: [netconf] draft-ietf-netconf-trust-anchors, deleting or:system certificates
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 18 Nov 2019 17:44:14 -0000

Hi Rob,

> In the examples in the draft-ietf-netconf-trust-anchors draft, there are examples of certificates that are “origin: system”.

As a quick recap, since it hasn't been discussed in awhile, the intention is to support built-in keys and trust anchors, which would have origin "system".

Inconsistently, the Truststore example shows "operational state" while the Keystore example shows "configuration" (though the paragraph preceding it mistaking says otherwise).  Perhaps two examples (one for each view) should be in both drafts.  It may be better to just have the configuration view in the main body while adding a new section to each draft discussing support for built-in values...


> Should it be possible for clients to explicitly delete some of these certificates

Maybe, but not likely for the driving use-cases:

 1) a TPM-protected key and its associated IDevID certificates
       - values persisted in hardware (the TPM)
       - values presented in Keystore

 2) any trusted-by-default certificates
       - values persisted in firmware/OS (can vary release-to-release)
       - values presented in Truststore

It may be that an implementation allows these values to be "removed" from <operational>, but it seems more plausible that operators would just NOT copy them into <intended>.


> , and if so what mechanism/configuration would they use to achieve this?

If possible at all, how such "deletions" are realized is outside the scope of these documents.   The new sections mentioned above, discussing the support for built-in values, could say this, but it might be better to not say anything.


Kent // contributor