Re: [pkix] RFC 5280 interpretation of trust anchor certificates
Corey Bonnell <Corey.Bonnell@digicert.com> Wed, 12 October 2022 00:34 UTC
Return-Path: <Corey.Bonnell@digicert.com>
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 39C9CC1524DE for <pkix@ietfa.amsl.com>; Tue, 11 Oct 2022 17:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.678
X-Spam-Level:
X-Spam-Status: No, score=-7.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=digicert.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 LdtI7MKe4GDE for <pkix@ietfa.amsl.com>; Tue, 11 Oct 2022 17:33:58 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02on2118.outbound.protection.outlook.com [40.107.96.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71802C14CE35 for <pkix@ietf.org>; Tue, 11 Oct 2022 17:33:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KndRTYTy69BXxa8XMh2cHh5E09aWAUsYj5Lih9VoDErQdIwG8saGU5HtgVag9NkUlcbLWKix0o6XrsdYZbN/aEnSjUIWNrgRNedS7idWEjBBpPCs6AFMsQGuGlwJAa/lk84q+ouvL3GM1dKO+nMi1i0RpS9XLPB9OkMifyy8XsXDwBAMHIOS+oKhxCEA77w/LGqVAHCpQN0tyf7cT3IY6zhIev/v73OPdeampTfKTsDHjnO5G4NiBK979otkb0474rv54XoYDjcxbVQyNlKts08gTIdr3fGHSN3AjoGkM7tASbsCGqFXXMD2gIOYd3VdSSYECZm7RqOVv0okRH83Tw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UYfXprOQ/Cf8x89a7N28+hQe2XA2km0KoreFXCbIaHY=; b=ij4KYMP/IczpMkML6U1jnetVbV0giki2WqSjEsjZ8nILXPMBJNnsMB6UU0icgsK38DL4rSRIWInA0MKmfiKkoJ3pGZow05we+yvozZ2n9dZOiEssD7AESkLZONbeXldt7a8yegzZ32Bz897jlrkL4k5nvYhuF5LGFvwBwTBf2Ss7IUcNUpvB6W5FtqpmanYKyzC+6IFBCMrvalU1P+ZVkz/8PAGAM4UgoYA2johB+AJZSM4PzttoIjhUrTCyYI5t8Gnv8AK9pH2+gAAfP66wDfFNyfY3lftsrLRvWC4vcSou8NpBTKrkwtsoCD4mZn96gniVd4Ldmg2L11v6e/4sLQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UYfXprOQ/Cf8x89a7N28+hQe2XA2km0KoreFXCbIaHY=; b=TMwhDumJyRL5eZYf/T9BriRF58MTmQO2z4Egr62tL2ZRcM4ak/1ogFaYTQTvF4y6gqXefGles2Ur5Xean4aCW90Fq2pqDJnSitALyDrYiv8s4il/qje4DhLk63udxuQqVUDTtq+xYWfc2ejUyi5+hz//RqnLRUL78DdT216loPqk1eQrb3ulwfLmYlqoYUghQx7D+a538rn6uBMdGbKYHNsSnMxITEmBs2CtA5BvooLAZYBrR2pPbh7NUO2qRgfO2ZcKSyBoeVMstDDK/8GzJZwyzx6BVETA8Pk3o/pCJW9qql/rAHYa4tFzoWLLApmSWkfB5/L1FLl6iIoOBZylVA==
Received: from DM6PR14MB2186.namprd14.prod.outlook.com (2603:10b6:5:b6::16) by BN8PR14MB3458.namprd14.prod.outlook.com (2603:10b6:408:7d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5709.21; Wed, 12 Oct 2022 00:33:53 +0000
Received: from DM6PR14MB2186.namprd14.prod.outlook.com ([fe80::b5c4:bdcd:f8dd:588c]) by DM6PR14MB2186.namprd14.prod.outlook.com ([fe80::b5c4:bdcd:f8dd:588c%5]) with mapi id 15.20.5709.021; Wed, 12 Oct 2022 00:33:53 +0000
From: Corey Bonnell <Corey.Bonnell@digicert.com>
To: Niklas Matthies <pkix@nmhq.net>, "pkix@ietf.org" <pkix@ietf.org>
Thread-Topic: [pkix] RFC 5280 interpretation of trust anchor certificates
Thread-Index: AQHY3Af9AG1v0u+ItEGpwtMZsRKnra4HzkUAgAHZJACAAENEcA==
Date: Wed, 12 Oct 2022 00:33:53 +0000
Message-ID: <DM6PR14MB21868B7C9A9B64867490FCB792229@DM6PR14MB2186.namprd14.prod.outlook.com>
References: <Y0MKZ/LkgnDcOY1z@nmhq.net> <EC0F50DD-6ED8-4C06-917A-EA0F3737BAFB@vigilsec.com> <Y0XRchBA1Lpaclj4@nmhq.net>
In-Reply-To: <Y0XRchBA1Lpaclj4@nmhq.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=digicert.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR14MB2186:EE_|BN8PR14MB3458:EE_
x-ms-office365-filtering-correlation-id: c690edb6-466d-44df-de64-08daabe970e6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: KVybcHfKBREOW4RBiJ9z5kc1lQjZRoJS2rwEPbHI8KzvPeoOGLUZB0M83AAvGnbjEPz+MbqzhSY8IP5J9NGl5VPDFWbWqdZuOWCqSqlrUr+75gh2OPMC0wn4DvrCxeqY3lvbzArRS6Nfb4hNZ91KmxhEdNFmvCR5Gml+P9klNblKbq2StwY4It4qL4uEcQflgNezk6NOhIzqORSGfO3yt+L3c84r/n94sZGMdOYDJpK4dRw9bbr55wApbr+wljEqeX0iEcI8dlB0Uw9syMlU+hLoLk7HoEzjeaOjupvPE0CKQc+BI8VD46LW3bYb+ZI2UXPI0Hacf8gXgLJdbgW+qDlM43uf1IDNWfzXE1kMkX1SCTbv2vs0vkkT9iyZoQ+8ExUXabbz0esIn23fx1TRPAivjtDtE8112MwW0vBr7W3QPoIPi1OjE5Kfq45Hg58oktQWHPdpJxvuj3eG40hHx+fjtYpYRWI0LXgrT/mdHIsx2Xx4fz3dDgMij43TfqMpCad5Drt+6DIC/Pw33vrfERV4bo1U9WtbfkxRR0W/oI1ALfBvZldX43V7TantZSmHtAiRcmDHdeNfLbRM1wmxdyrrCZkVRV8EGBB5+G5wo73Swm7craRzq0qX+JeDurKfqa1xwJHcqB0u7H9N68K36B4nntpU9LJH1iHnxrfVXmTWWdQaB1abZO169TPfum+05TF4QHXzpU/sH10ez0FPmdVLLB4NtxEtUhjwG27YBROb1gUijbnJcEoTyppvdYRGXE6sP/cQn3tkZQcqc8K1rNJjQT40bPfTgB/RKtOlMXE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR14MB2186.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(39850400004)(346002)(136003)(396003)(366004)(376002)(451199015)(38100700002)(9686003)(99936003)(122000001)(86362001)(7696005)(6506007)(53546011)(478600001)(66446008)(66476007)(66556008)(8676002)(66946007)(966005)(71200400001)(76116006)(64756008)(110136005)(2906002)(316002)(4001150100001)(5660300002)(8936002)(186003)(52536014)(38070700005)(83380400001)(26005)(33656002)(55016003)(41300700001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: a4cz4bqKEsSz0MzT38ILwaBIl2O7oXHoINC8s9DA0/yl+TIwdgx1DXELgckFQ9A6EcgIRXAw5r21xL8RrGQzf5uIwYR8n22SbB2aezDEk6mJ8xewuA3/UhnK/8yyc+KP/wxmlkHXX57fedfEJ3ZtNIrXCrk9ENHpOgiflHr0ypHw73amKMocKBrhL1xr3OBA6eR2T+LkeetuJ1kKf+BwPaIu4NCiGufAKd3eBV1jPyKx4yQoerSTJXVy7I8PwF44JtR6MUmL84C396rZP04SYcqLXC5Fx4bWFa557HbFdlOVuTytVOHPe5Zx2JeOP9c/j/dRUCxedX5/Thsmv9kcjawLqaBJ1b/o4dloIKVnuY1VDcqkH3ltk8dCbZGq24bulfjdE8hXpm7geNPwz+wPrVq2wD1iS1jAFfCANfiTypYvzielF2sMOJ6CdL/NErJkHFizfY7HPOsDR2TSdeuVJHfOT9jqOEgggyAIWcCC9O3jL/i4AaT5Wcr4hAev2e7O8v+xuJdW37Fn3eYw0k9zWjz7akOKIVVHczowHVlJs4Qi3PhvLPh52uhgw7UknPPqhAZNMmUvNT/uoDRGAFCANq9E77NnCTIwOthSnEvqkJPha8hrac5KU8h/cnPKOnyNKPF8s/Wy8Q57Jtba0QEgQYPLQH9qr9Ye5FnlHpt7aZuLZ/qBmmpiV/h9WrDgvNzP0L41ji/zvtpbCahKjt1C7cZZOse09L947SvM8hXlDuC0SaRULWp9w3tbE6v1W/sU2JPJiBvFKtcetVDTVwxuEgllUzJ2hvrtgm2SyUQzcIxH4IYu8+0Ov3dmAQoBpFK1sf2ebkEV3YVhZDM6vahvm20HLctrJMSBhaxqxPobKDcOmxtBfCs0f0EEaB7F0Yp/3jjoeGkWLb+BpjniG+jTjzdnsBIrNYBWjXeRzskPvvJz/rNpQacAg2Eypk62wDBCL3ULmRx3vFU1h3uvKkb7oz9zBn130+JYoIq4Lmg9DocKkWwPjnJ5OaJR6PYzrJHfFVx31EYv6/BC2CpODpEWjPF4qelJnX/IcPyjY1TXY5FvDg3jhi/x/B9hZ8Rz5p98UmXdPGRP6O/xV4i47xP6cWe/LW1dutSPtwnxEG4w+bSJMGCPsO+Xn0DBOylEuFsqmh4FaFa5tOV63jZZtnmJeU9QBlMm832MoIJ11eLUwF2losORniQuq02Caj7Ij2Xn9nm7fr9qlHHvAZwrpjfahmfa8lOLof+hfjtLv237azESTmlmuq/EnT1liBsv6jJwSDWR1hD3DOPnjPqzJiNq1nWrBsH3FMHT15+zp+Dq/kfNXSUhz88zZyAfnB5lrjhhRGIomjzF60yG08/ctONNriLgcltfQV+YswIoEeGbDZEWfHTLDCk1DHAdlTu/8bm9yt++vqelaLtfb5LZ3Kp1szNs4q7dI3XXQr6GjKOzDMzBP5fMcgSXZ9TF/6ciSgVeIJtUGb72onp+Zwl9UIvr1yVBtc8TfHrh+ylilcozIMKVzPf2GJ9EZ7eKcWvlQEKt7UUm1/CMYga2gMaG03OX3iP0zKy7JCKbo652/35+gl8s/cDQXr7G6AU47OrIuNj9YJ6zufGe3ebUtp9BsQui+w==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_00DE_01D8DDB0.C62DE9F0"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR14MB2186.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c690edb6-466d-44df-de64-08daabe970e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2022 00:33:53.5942 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: d3PJwHYiuVXxf0vRc+yhr+ollmnJZRy/UMH2gLab+22lWOg1iOPeZ4npd7S0df0YWccYdIuTwstXyYK2EJptTcRw1s/iIjs/xYaTCRHoR0A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR14MB3458
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/pWANkM4IqzM4yKubHkod028wc14>
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: Wed, 12 Oct 2022 00:34:02 -0000
Hi Niklas, Section 6.1.1 (d) says: " 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 provides an illustrative example how trust anchor information can be distributed. The second sentence describes how the name and public key can be extracted from a certificate. Note that the second sentence does not say "self-signed certificate", but rather merely says "certificate". Given this, I believe this sentence is also applicable to non- self-signed (or even non- self-issued) certificates that are used as trust anchors. Thanks, Corey -----Original Message----- From: pkix <pkix-bounces@ietf.org> On Behalf Of Niklas Matthies Sent: Tuesday, October 11, 2022 4:26 PM To: pkix@ietf.org Subject: Re: [pkix] RFC 5280 interpretation of trust anchor certificates Russ, The context of this thread concerns the European Trusted Lists, which are intended to provide a set of trust anchors for various services. The service entries in a Trusted List contain trusted certificates, however it remains unspecified how to map those certificates (plus, potentially, associated metadata in the service entries) to the specific form of trust anchor information required as input for the RFC 5280 path validation algorithm (item (d) on page 76). Most of those certificates are not self-signed. The argument has been made on the ESI mailing list that RCF 5280 actually does specify how to do that mapping, but in my reading it only does that for self-signed certificates, if at all. Hence I started this thread to get a clarification on that point. My current conclusion is still that RFC 5280 at best only specifies a mapping for self-signed certificates. Even for those, it's not clear whether the use of that specific mapping is mandatory, due to the lack of "shall" or of other keywords indicating the requirement level. This to me indicates a technical gap in the ETSI specifications regarding the use of the Trusted Lists. Niklas On Mon 2022-10-10 at 12:13h, Russ Housley wrote on pkix: >Niklas: > >The relying party gets to decide the set of trust anchors that it will accept. > >A very common way to distribute trust anchors is self-signed >certificates. This provides the public key, the algorithm identifier >for the public key, and the distinguished name for the trust anchor. >As noted by others, RFC 5914 defines an alternative format to supply >the trust anchor public key, the algorithm identifier for the public >key, and the distinguished name. This information are needed to >validate certification paths that terminate at the trust anchor. > >The relying party can use a self-signed certificate or any other >certificate or any other source to update their trust anchor store. >In practice, a self-signed certificate is normally used; the creation >of a self-signed certificate illustrates an expectation for it to be >used as a trust anchor. > >Russ > > >> On Oct 9, 2022, at 1:52 PM, Niklas Matthies <pkix@nmhq.net> wrote: >> >> Dear all, >> >> On the ESI (ETSI) mailing list, the question came up whether RFC 5280 says anything about trust anchors provided in the form of certificates that are _not_ self-signed. >> >> 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? >> >> 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. >> >> 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? >> >> Kind regards, >> Niklas >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix
- Re: [pkix] RFC 5280 interpretation of trust ancho… Michael StJohns
- [pkix] RFC 5280 interpretation of trust anchor ce… Niklas Matthies
- Re: [pkix] RFC 5280 interpretation of trust ancho… Jeffrey Walton
- Re: [pkix] RFC 5280 interpretation of trust ancho… Niklas Matthies
- Re: [pkix] RFC 5280 interpretation of trust ancho… Michael StJohns
- Re: [pkix] RFC 5280 interpretation of trust ancho… George Michaelson
- Re: [pkix] RFC 5280 interpretation of trust ancho… Niklas Matthies
- Re: [pkix] RFC 5280 interpretation of trust ancho… Carl Wallace
- Re: [pkix] RFC 5280 interpretation of trust ancho… Niklas Matthies
- Re: [pkix] RFC 5280 interpretation of trust ancho… Russ Housley
- Re: [pkix] RFC 5280 interpretation of trust ancho… Niklas Matthies
- Re: [pkix] RFC 5280 interpretation of trust ancho… Corey Bonnell
- Re: [pkix] RFC 5280 interpretation of trust ancho… Niklas Matthies