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

Carl Wallace <carl@redhoundsoftware.com> Thu, 28 April 2022 14:39 UTC

Return-Path: <carl@redhoundsoftware.com>
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 F3485C15E6C3 for <netconf@ietfa.amsl.com>; Thu, 28 Apr 2022 07:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 i78_E_9lertE for <netconf@ietfa.amsl.com>; Thu, 28 Apr 2022 07:39:47 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AFFC159A23 for <netconf@ietf.org>; Thu, 28 Apr 2022 07:39:47 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id p4so3051018qtq.12 for <netconf@ietf.org>; Thu, 28 Apr 2022 07:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=j2uFD4Jt5KIib4mXdCrNOJFEGGMIvZvTMlj8uBtSImk=; b=a+Ic+yeaKrI0oSYXbcnb5odhqMG6rmhUX+m8Cs3yUq9O4tHYMJ2s1GXV65AnT3P+vX FgahMAHsbJUAugTGQIvIL6gH8PaF1gXlBUa+B63Z9/j4B/zDGcywIY3XkHt6oTG0jRir wM3q5J5JdqJHie3EoEnjYRMfvRLndU1QhROps=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=j2uFD4Jt5KIib4mXdCrNOJFEGGMIvZvTMlj8uBtSImk=; b=1ohwJntluUisyk9MoTp6QYjJQl1MyXWsSuKhoh/k6vfVo4BJI+V+9TaTJgX73+uwrl Zfnje+iN+8Lp5w7sKO162GtgljLj6QGJDpDV/PaJIKVvWGcpWPk6nljAYmuCRf2LRyvb CT5J3uZ0r9lHWaf2q3pKrffyOFZkVdBaQW2IU6DIkROrh9lsuS5m4nRX69waw/fpa/n9 /rn6tjmufa6v7KqsSTUh89hTcYKIJWz5fT+rMqddiYhYjkB7WPphHK6R580RkCX7KhMC SB0j1OQO4CMt9ZbdmRIzXAoJQovb+9EOS22mbE8Dw8UlcggOotUhzKWcFH6Pwq/mDHYc 02PQ==
X-Gm-Message-State: AOAM532LySf7ZOfy4ILX5swbc3STQHMLmc5UqVJPIHzJ1jTaMXcJFq9D M4g6acfF2AyVBj215HoXteIgO72pYnrJdw==
X-Google-Smtp-Source: ABdhPJyfio/uGRihTVw3uVi9qEVuzF0R10skvnzQACWVIk82wHVk8pvvUCkd9gXVIQzJF1xY+G88gQ==
X-Received: by 2002:ac8:5893:0:b0:2e1:c7f6:9992 with SMTP id t19-20020ac85893000000b002e1c7f69992mr23305456qta.23.1651156785301; Thu, 28 Apr 2022 07:39:45 -0700 (PDT)
Received: from smtpclient.apple ([2600:1003:b135:9f9c:2802:44fe:b916:46e4]) by smtp.gmail.com with ESMTPSA id z22-20020a05620a101600b0069f8c0b6538sm53092qkj.50.2022.04.28.07.39.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Apr 2022 07:39:44 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail-37924ABE-47AC-4D89-BA7F-8B65F4908BD2"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Carl Wallace <carl@redhoundsoftware.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 28 Apr 2022 10:39:43 -0400
Message-Id: <7E9F3FFB-F1A9-471C-ADB5-9737DC89CD5B@redhoundsoftware.com>
References: <01000180707b3915-1e536572-d788-44f3-abf6-fe1140b2f3ac-000000@email.amazonses.com>
Cc: netconf@ietf.org
In-Reply-To: <01000180707b3915-1e536572-d788-44f3-abf6-fe1140b2f3ac-000000@email.amazonses.com>
To: Kent Watsen <kent+ietf@watsen.net>
X-Mailer: iPhone Mail (19E258)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Y7H1Z3uU4vQMVoKRyo4hryezb0w>
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 14:39:52 -0000

in-line…

> On Apr 28, 2022, at 10:02 AM, Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> Hi Carl,
> 
>   
>> 
>> [CW] The main point is I would like to see unconstrained trust anchors not be the only option (or at least if they are to call that out). If you don’t want to use a format that allows expression of locally defined constraints, don’t state that constraints are a “local policy”. That creates a misimpression. It’s a “certificate issuer policy” or a “local policy to use another structure”. 
> 
> Given that RFC 5914 is not widely used, and given that it (or other) structures can be added later, I feel it best to simply ensure the language in the text is as accurate as can be.  Can you help with that (e.g., OLD/NEW text)?
> 
Here’s a whack. 

>> OLD
>> This module also enables the configuration of certificates, where each certificate may constrain the usage of the public key according to local policy.
>> 
>> NEW
>> Trust anchors configured via this module are implicitly trusted to validate certification paths that may include any name, be used for any purpose and etc., subject to constraints imposed by an intermediate CA or by context in which the TA store is used. Implementations are free to use alternative or auxiliary structures and validation rules to define constraints that limit the applicability of any trust anchor. 



> To clarify the intention of the quoted text, it seems that how the v3-extensions (basicConstraints, keuUsage, etc.) in a certificate are set is a matter of local policy (to the Issuer of the certificate), but maybe "local policy" has a more narrow meaning?
> 
I don’t think basic constraints or key usage are interesting for local policy. I was thinking more in terms of names (which is how I’ve used 5914 structures for past ~dozen years) and possible future constraints to limit trust anchors used to validate endorsements or attestations (which is what brought me to read the draft). More generally, unconstrained trust anchors seem over broad to me and I’d like not to see them propagated in new work. 

> Kent
> 
> 
>> 
>> 
>>> 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?
>>  
>> [CW] Yes, I am suggesting the basic structure in the store would be a TrustAnchorInfo. I suggested 5914 because in its basic form it simply is a certificate (so it’s a drop in replacement with an option to use constraints if desired). The structure is just part of the story. Even in the “local policy” scenario, verification implementations would need to support enforcing whatever constraints were defined.
>>  
>> 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?
>>  
>> [CW] Structures can always be changed. I would minimally stop saying certificates provide a means of expressing constraints as a local policy, however, and either state that trust anchors are unconstrained or that locally-defined formats may be used to express constraints. 
>>  
>> I've never heard of RFC 5914 before, is it widely used?
>>  
>> [CW] No, it is not widely used. 
>>  
>>  
>> Kent // author
>