IETF Logo Mail Archive

Re: [Sidrops] What are the RFC 5280 § 6.1.1 inputs for (c) (e) (f) (g) in context of RFC 8360?

Job Snijders <job@fastly.com> Tue, 17 October 2023 23:19 UTC

Return-Path: <job@fastly.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6314C15107C for <sidrops@ietfa.amsl.com>; Tue, 17 Oct 2023 16:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=fastly.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 wPjKelTktuVD for <sidrops@ietfa.amsl.com>; Tue, 17 Oct 2023 16:19:29 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 894F7C14F726 for <sidrops@ietf.org>; Tue, 17 Oct 2023 16:19:29 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-99bdeae1d0aso1011707966b.1 for <sidrops@ietf.org>; Tue, 17 Oct 2023 16:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1697584767; x=1698189567; darn=ietf.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gsurz4QkJhpwdXZ5pM7ZlxR8xBOFTNgEcPIWbYFf9to=; b=ND3cyw9Gsx4kWzp4ZZGKtj2Z4p4jgUe7j3fcN93hzEdmByPqjYx+l7hLcnuhdiN7N/ LrPMpXoA+hyoXTgppFOCp40G018+I1mXxTNImRPNdaThDLCTbkXp2il8owzIIcMDuufJ RwvAHTnPQNrvmn/veG9YKxajLB1q07Rv/s00U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697584767; x=1698189567; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gsurz4QkJhpwdXZ5pM7ZlxR8xBOFTNgEcPIWbYFf9to=; b=A1PBK+/K55d68GDl0j/tV8jFf/bPI/98DDVtFvR53BNmeI7FCwSFoz5vmf5TFVm/lU Ehmy+cIg+RCL829JjaMMPJ9segYZbEraX5+hhX2Rq0/XOz4KlJEUO5h0qUb8qpmkchKS G9RVGLXcTFbxNhYBDJpJiiqdQGS+jIQDt10sY47V0PAg+5K4R9m4bJsDwe5zf3t/eax0 1ZNecKmCITw6YrRd2hhRMuI91rMIAaoan57ezx4suD5X5nTkWT06MmepUe3NoxIi+5qn CVg1H3BKX7kSeKN3N/atvINSCjIw1Tj9GY48q/bmGRPaBaXWJA44b6J10PcfgROSUSMx MuLQ==
X-Gm-Message-State: AOJu0YyFHbVNNiSBnNKvafKqGOS3AzudQZqQtLvBLUe7FGnd8WaABZub Noy97xV46llOtN9ChitE4b7XIA==
X-Google-Smtp-Source: AGHT+IG5yKD5npkWGc7SbUx2BRqp1sRq8f06IwlzRexePQlM7nIYP/Two/+zpJyuSq336PZQeqqVeg==
X-Received: by 2002:a17:907:3f1c:b0:9ba:65e:752b with SMTP id hq28-20020a1709073f1c00b009ba065e752bmr3042951ejc.39.1697584766650; Tue, 17 Oct 2023 16:19:26 -0700 (PDT)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id s2-20020a170906454200b009b977bea1dcsm529879ejq.23.2023.10.17.16.19.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 16:19:26 -0700 (PDT)
Date: Wed, 18 Oct 2023 01:19:24 +0200
From: Job Snijders <job@fastly.com>
To: George Michaelson <ggm@algebras.org>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <ZS8WfGi67RZv2A94@snel>
References: <CAMFGGcAftQp0fG+mZw5nASF4hcWYaR13Q+wLHLXu2SUCjrUcAg@mail.gmail.com> <D1C82A61-7766-46BF-B334-7E7C79F20BF0@apnic.net> <CAKr6gn3GzOPftoBP_hnK_1m5QeAcP0OyC5KKV_9x1odj=kRdZA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKr6gn3GzOPftoBP_hnK_1m5QeAcP0OyC5KKV_9x1odj=kRdZA@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/SEjh0cwuS3Csy2O9WJVryRLjwRI>
Subject: Re: [Sidrops] What are the RFC 5280 § 6.1.1 inputs for (c) (e) (f) (g) in context of RFC 8360?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2023 23:19:34 -0000

On Wed, Oct 18, 2023 at 08:40:45AM +1000, George Michaelson wrote:
> I also believe strongly we should be defining a clearer mechanism
> permitting intermediate overclaim, and reduce risk in the validation
> process.
> 
> In effect, this is about minimising "third party damage" to unassociated
> RPs and resource holders which we could be avoiding.
> 
> If doing that demands better clarity in associated inputs then yes, that
> should be documented. I think this should be looked at.
> 
> Thanks for bringing this up Job.

Recommended related reading:
https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-policy-graph/

Given the complexity of correctly and safely implementing policy
checking in X.509 validators, I'd like to encourage the working group to
contemplate alternative mechanisms to permit intermediate CAs to
overclaim.

Ideally the such a mechanism does not depend on cooperation from and
coordination with the signer side of the house.

Kind regards,

Job

v2.46.0 | Report a Bug | By Email | System Status