Re: [pkix] RFC 5280 interpretation of trust anchor certificates

Niklas Matthies <pkix@nmhq.net> Sun, 09 October 2022 20:03 UTC

Return-Path: <pkix@nmhq.net>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3B3C14CF19 for <pkix@ietfa.amsl.com>; Sun, 9 Oct 2022 13:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 uvJM9Xumqp-3 for <pkix@ietfa.amsl.com>; Sun, 9 Oct 2022 13:03:27 -0700 (PDT)
Received: from mail.nmhq.net (mail.nmhq.net [95.129.49.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D4FC14F728 for <pkix@ietf.org>; Sun, 9 Oct 2022 13:03:26 -0700 (PDT)
Received: from matthies by mail.nmhq.net with local (Exim 4.94.2) (envelope-from <pkix@nmhq.net>) id 1ohcWB-0018EF-9T for pkix@ietf.org; Sun, 09 Oct 2022 22:03:23 +0200
Date: Sun, 09 Oct 2022 22:03:23 +0200
From: Niklas Matthies <pkix@nmhq.net>
To: pkix@ietf.org
Message-ID: <Y0MpC50ARNV8QhB0@nmhq.net>
Mail-Followup-To: pkix@ietf.org
References: <Y0MKZ/LkgnDcOY1z@nmhq.net> <182e19f5-a630-7830-3011-0ed9fc62ea81@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <182e19f5-a630-7830-3011-0ed9fc62ea81@nthpermutation.com>
X-Clacks-Overhead: GNU Terry Pratchett
X-Editor: VIM - Vi IMproved 8.2
X-Operating-System: Linux 4.4.268 x86_64
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/FFzOox4D8ky8MCGBgF83DZOlsC0>
Subject: Re: [pkix] RFC 5280 interpretation of trust anchor certificates
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Oct 2022 20:03:29 -0000

Hi Michael,

On Sun 2022-10-09 at 14:21h, Michael StJohns wrote on pkix:
>On 10/9/2022 1:52 PM, Niklas Matthies wrote:
:
>>In section 6.1.1, there is the following wording on page 76:
>>
>>      The trust anchor information may be provided to the path
>>      processing procedure in the form of a self-signed certificate.
>>      When the trust anchor information is provided in the form of a
>>      certificate, the name in the subject field is used as the trusted
>>      issuer name and the contents of the subjectPublicKeyInfo field is
>>      used as the source of the trusted public key algorithm and the
>>      trusted public key.
>>
>>The first sentence seems to indicate that the case of providing a 
>>trust anchor in the form of a non-self-signed certicate is not 
>>considered here. But the second sentence doesn't repeat the 
>>"self-signed" bit, which can be interpreted as that sentence also 
>>applying to non-self-signed certificates. However, if that is the 
>>case, why does the first sentence restrict itself to specifically 
>>self-signed certificates?
>
>In the above, it's basically because it didn't really need to be 
>repeated to be understood to refer to the same certificate which was 
>referenced in the first paragraph.

So, if I understand correctly, the intent is that the second sentence 
also only applies to self-signed certificates. Hence, the 
specification given by the second sentence of how to reduce a 
certificate to a "plain" trust anchor is, strictly speaking, only 
applicable to self-signed certificates, as far as RFC 5280 is 
concerned.


>>On page 74 there is also the following wording:
>>      When the trust anchor is provided in the form of a self-signed
>>      certificate, this self-signed certificate is not included as 
>>      part of the prospective certification path.
>>
>>If RFC 5280 also allows the possibility of trust anchors being 
>>provided in the form of non-self-signed certificates, then it would
>>seem that the above restriction would not apply to those, i.e., that 
>>they may be included as part of the prospective certifcation path. 
>>However, I don't see how that would make any sense.
>
>Look at the Certificate Path Validation algorithm described in 
>RFC5280.  A self-signed certificate provides the information needed to 
>initialize that algorithm, as does an intermediate CA. There's also 
>RFC5914 which describes a non-self-signed ASN1 structure which 
>provides basically the same level of information. It's pretty trivial 
>to transform a self-signed certificate or other CA certificate into an 
>RFC5914 format TrustAnchorInfo object.

Yes, that's clear to me. My point is, if another specification (ETSI 
specifications, in this case) refers to RFC 5280 for path validation
using trust anchors in the form of non-self-signed certificates, then 
that specification would have to specify how to map non-self-signed 
certificates to trust anchors as understood by RFC 5280, because RFC 
5280 only addresses self-signed certificates.

Specifying that mapping is trivial, of course (it's the same as for 
self-signed certificates), but without specifying it there is a formal 
disconnect between the two specifications.


>>All the wording taken together, my conclusion up to now was that RFC 
>>5280 simply does not consider the possibility that the trust anchor 
>>could be provided in the form of a non-self-signed certificate, and 
>>that therefore, specifications which *do* allow for that possibility 
>>(such as in the context of ETSI trusted lists) have to clarify how 
>>that case maps onto what RFC 5280 expects.
>>
>>If that interpretation is incorrect, that is, if RFC 5280 doesn't 
>>actually care about whether a trust-anchor-representing certificate 
>>provided as input to the path validation algorithm is self-signed or 
>>not, then maybe an erratum is in order?
>
>See RFC5914, section 3 - TrustAnchorList/TrustAnchorChoice - a 
>Certificate (of any form, including X.509) is one form of a 
>TrustAnchor.  I think we're good.

Just to clarify: There is no particular reason why RFC 5280 should 
restrict certificate-represented trust anchors to self-signed 
certificates, but it just happens to do so for historical reasons?

Niklas