[Sidrops] Re: Notification for draft-spaghetti-sidrops-rpki-ta-tiebreaker

Job Snijders <job@fastly.com> Thu, 20 June 2024 18:13 UTC

Return-Path: <jsnijders@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 E01FFC151548 for <sidrops@ietfa.amsl.com>; Thu, 20 Jun 2024 11:13:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 6qm2296eoDTL for <sidrops@ietfa.amsl.com>; Thu, 20 Jun 2024 11:13:25 -0700 (PDT)
Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 DAD40C151543 for <sidrops@ietf.org>; Thu, 20 Jun 2024 11:13:25 -0700 (PDT)
Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-5c1cabcb0c1so445481eaf.0 for <sidrops@ietf.org>; Thu, 20 Jun 2024 11:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1718907205; x=1719512005; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T/FW7ZESic3LsdE/51cY9HY9VVQEt7E+NzdUCK7cwUc=; b=LAVYqee8e4ktU0LbBimNX3WZZXYcu0+KRTpC1Crid/P3JiQnhUV/2lCjG2IAAtpA5j jOI3YhEOmt4la6Ps+tEByqJTQn7rb+FFK+I7OSy355WdbO5PA5XUdbUQCNAVDW7edbiV 4D0NZh9vXSqe4aoEjcxpHh3kYJrIu7q1fmOEA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718907205; x=1719512005; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T/FW7ZESic3LsdE/51cY9HY9VVQEt7E+NzdUCK7cwUc=; b=rikaK0feI6gOm6gcy3000LhtLMZ/HMVddFvC70fo6umJmgAlTqs2zkGpPoh2fv7Q+d bOiFzDFtIwO1/di6czvo7WFyARZ7tJZJQQkjTZXiqNG1krRLwoW+zZFiJY5SaONi52YR h2rk1T3l2Lf/5XJVJgj5QAsXjdUYG7FEXQnMYGgARvaQycquXBzFmuYICyrD8T9Y0JeG nPvw2UWVMukOvLdImuQ7BUbbSKDkoQdcWRKzQVfQ2BQWINYVyMsTx41BtDYSqmOmY4VU gHlJNx7QmHV+6SMqI6MMao6J2rxPP+8/H8+TyW/kPgptHahLRhvoqR0D8oTKxawM2Yf0 qRTg==
X-Gm-Message-State: AOJu0Yy1e1jHW/+NF7neJcvlzgBXsW0t6cNSQDkiFiUKJlY+br3GG0ev qSQ8fkva4BO1ecUVcsgIg7MmAQ2s+yi5RO7ICgk3Sn4aSLx4OYG4nhnomXCmHaGmb1f/e9xoRP6 78x+cbsvu4FqlQRi77kmQboIMmRFc75WlQ9XHbA==
X-Google-Smtp-Source: AGHT+IF+tN025l/mzrigA0ueg2tpnOGKPA8iVD46+cceNVmujpKzFspT24Y5PrmUZAtTUDXIfL9zFGxzuGkm7mZJ5mo=
X-Received: by 2002:a05:6870:d8c6:b0:250:8769:4d5c with SMTP id 586e51a60fabf-25c94db7da5mr6546949fac.53.1718907204765; Thu, 20 Jun 2024 11:13:24 -0700 (PDT)
MIME-Version: 1.0
References: <ZnNtl9d7cnkMtK-1@snel> <6CC9BD6A-8CF7-4647-9D3F-60AE0DEDC512@vigilsec.com>
In-Reply-To: <6CC9BD6A-8CF7-4647-9D3F-60AE0DEDC512@vigilsec.com>
From: Job Snijders <job@fastly.com>
Date: Thu, 20 Jun 2024 20:13:13 +0200
Message-ID: <CAMFGGcB1zhLx6iE_0jA1yWCSgQq_LxCOO=CA0TttzGenhUzVSQ@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="00000000000057a81d061b564548"
Message-ID-Hash: XXXQ6C3B7FQFFECKUXN4R7ZCBVFGIHAO
X-Message-ID-Hash: XXXQ6C3B7FQFFECKUXN4R7ZCBVFGIHAO
X-MailFrom: jsnijders@fastly.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-sidrops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF SIDRops <sidrops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Sidrops] Re: Notification for draft-spaghetti-sidrops-rpki-ta-tiebreaker
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/hRH-IFk1siq4n9dkMODSHhO31T4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Owner: <mailto:sidrops-owner@ietf.org>
List-Post: <mailto:sidrops@ietf.org>
List-Subscribe: <mailto:sidrops-join@ietf.org>
List-Unsubscribe: <mailto:sidrops-leave@ietf.org>

Dear Russ,

Are you sure TA’s can rekey themselves using RFc 6489? I thought that’s a
CA-only procedure.

Kind regards,

Job

On Thu, 20 Jun 2024 at 19:56, Russ Housley <housley@vigilsec.com> wrote:

> Job and co-authors:
>
> I think that this document needs to be clear that this is talking about a
> TA renewing its own certificate.  If a TA does a rekey in accordance with
> RFC 6489, there is no need for tiebreaking.
>
> Russ
>
> > On Jun 19, 2024, at 7:45 PM, Job Snijders <job=
> 40fastly.com@dmarc.ietf.org> wrote:
> >
> > Dear SIDROPS,
> >
> > In context of Relying Parties maybe having acquired access to multiple
> > different valid issuances of a Trust Anchor certificate, Ties de Kock
> > pointed out potential issues relating to certification path validation.
> >
> > An implementation to demonstrate a tiebreaking scheme in the presence of
> > another TA certificate was instrumented in OpenBSD rpki-client, and we
> > documented our effort in this internet-draft.
> >
> > Your feedback is most welcome!
> >
> > Kind regards,
> >
> > Job
> >
> > ----- Forwarded message from internet-drafts@ietf.org -----
> >
> > Date: Wed, 19 Jun 2024 16:11:54 -0700
> > From: internet-drafts@ietf.org
> > To: Job Snijders <job@fastly.com>, Theo Buehler <tb@openbsd.org>, Ties
> de Kock
> >       <tdekock@ripe.net>
> > Subject: New Version Notification for
> >       draft-spaghetti-sidrops-rpki-ta-tiebreaker-00.txt
> >
> > A new version of Internet-Draft
> > draft-spaghetti-sidrops-rpki-ta-tiebreaker-00.txt has been successfully
> > submitted by Job Snijders and posted to the
> > IETF repository.
> >
> > Name:     draft-spaghetti-sidrops-rpki-ta-tiebreaker
> > Revision: 00
> > Title:    Tiebreaking Resource Public Key Infrastructure (RPKI) Trust
> Anchors
> > Date:     2024-06-19
> > Group:    Individual Submission
> > Pages:    7
> > URL:
> https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-ta-tiebreaker-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-ta-tiebreaker/
> > HTML:
> https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-ta-tiebreaker-00.html
> > HTMLized:
> https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-ta-tiebreaker
> >
> >
> > Abstract:
> >
> >   A Trust Anchor (TA) in the RPKI is represented by a self-signed X.509
> >   Certification Authority (CA) certificate.  Over time, Relying Parties
> >   (RP) may have acquired multiple different issuances of valid TA
> >   certificates from the same TA operator.  This document proposes a
> >   tiebreaking scheme to be used by RPs to select one TA certificate for
> >   certification path validation.  This document updates RFC 8630.
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> > ----- End forwarded message -----
> >
> > _______________________________________________
> > Sidrops mailing list -- sidrops@ietf.org
> > To unsubscribe send an email to sidrops-leave@ietf.org
>
>