[Sidrops] Request for Call for WG Adoption (Was: New Version Notification for draft-snijders-constraining-rpki-trust-anchors-08.txt)

Job Snijders <job@sobornost.net> Mon, 05 May 2025 12:32 UTC

Return-Path: <job@instituut.net>
X-Original-To: sidrops@mail2.ietf.org
Delivered-To: sidrops@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 1976E24CB381 for <sidrops@mail2.ietf.org>; Mon, 5 May 2025 05:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20230601.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrYxZCEdKaIj for <sidrops@mail2.ietf.org>; Mon, 5 May 2025 05:32:44 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3A72824CB37C for <sidrops@ietf.org>; Mon, 5 May 2025 05:32:43 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5e677f59438so6397523a12.2 for <sidrops@ietf.org>; Mon, 05 May 2025 05:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20230601.gappssmtp.com; s=20230601; t=1746448362; x=1747053162; darn=ietf.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=U2UzPFajwBjc9z8SwT/xU1hE0SXzqHgWndDxnNchQnM=; b=BQQVH4eHr9i330qJoZScZpHly2LV7JR3YrIKjHyOwt5BZLTWYRB/w1VSnaGCeuumq2 P79J7gzmsmN3QFLjqqwk18nkEx5Pu8kzJzYm/4+b+IDUmBXpo6JGZNJjdgdDjU6vXQXK 7288bJ3mGgLvibtqNtHjwyF+JhtVZ3qbQ0gNfUd+B5IIz9Q6fuUCPo2OfiDkx6XnfKM9 KmW1t98spaD3CPDODYdLOKJtza3AifjshwmA2mh0dDw8uEjs3qP8nUweeBGn8DZK10A6 F9sEgD2GfgAEYuhrX9TaaIbHBiDyyfs3emRWBUyIrKRZhY0y/VdPV38Ux9Jx2CCk9mpp 8xNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746448362; x=1747053162; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=U2UzPFajwBjc9z8SwT/xU1hE0SXzqHgWndDxnNchQnM=; b=VetrPBSqnoAG785niPzH06exkfHot5TLlGx5164eqmozBDbadAkLQX+nH0LcXRmmSi Vs1Do5brlPVZL72PJofD4r+ozXsvBOIVHTWPwQIJr5VwZL15mAFIzhQ/tZe2buvzRG1y +hpiK88s6mvQOTKEOka4FGk0pUTfWKh2HfquVTKZUcfEEn4h2XvH6MnTi5NxzAxoP2XK D4g7vXPiRc/zD4tc+y10sxsOCdS/zZDOWAFxeuhhHbPEGZWs3r7pwlrrSqZRKAQoYCwr LyWmdrc98QW4izFaQX8q4WCGHJEnRQAz8kci4BuBtFJN2Ntc0ZMqYtKaj3XHKEsqCFJp iogQ==
X-Gm-Message-State: AOJu0YxPV9123T9HbestEvUeOZMPvT1lW5XNgkG4PQzmvTF0msFW77Rm GB4PG5RUhrAmNQ1iTajTV/a49X/1TC/9CGTsdmUrcOPClt8Ipi/RSiOvyON53QvgJbJC6jCEPR9 bOZY=
X-Gm-Gg: ASbGncvlJYVGb/QRtPC4rZd3vsRCA/9Tbd7RozPCOsY5TM1YjXLiZxjUl+EsLD4VK/Y /agtIQxXvwfdkQyU4Hcs7OC0C3+aAxeOYHgl79g/CmnjhWBfbl2xx6EWwkOOJVO7XoOX10a57BE rtfkuPTNAs1wZvpfuRHV+3pdBxt6YCB2HM+PDwYh0FmmaxSwxf1L+lDuNDHV+4gY3cLKvVi6rTu iLF7ZSoScZcAl5BIshBxxjm9fK8T9aPxlw9Q8wr+d/3s/11Rtwd87uQSQeBatVSLLEpLVS18Byt uMuXs5yPfvYQ6awnm/10Psj5m/TMgHUTaCQe07Aj1f+yfj1ckdszq3ruYAnDfUpEnLrj
X-Google-Smtp-Source: AGHT+IEuk9L2hcc8yNihVDNzMz5ggVzGgwbxwX1BtwzrY4HO6RmQ+u5FcwX/cqufqon14g2EimmJAg==
X-Received: by 2002:a17:906:9c94:b0:aca:cb18:9ad0 with SMTP id a640c23a62f3a-ad1a4a8dabbmr614815066b.45.1746448361663; Mon, 05 May 2025 05:32:41 -0700 (PDT)
Received: from anton.sobornost.net (anton.sobornost.net. [192.147.168.5]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad189508dd9sm487833666b.144.2025.05.05.05.32.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 May 2025 05:32:40 -0700 (PDT)
Date: Mon, 05 May 2025 12:32:39 +0000
From: Job Snijders <job@sobornost.net>
To: sidrops@ietf.org
Message-ID: <aBiv5-0DEuvA-u8n@anton.sobornost.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Erik Bais
Message-ID-Hash: HGOX7HSDU2JVSU7HSEGUPAKDZJOFQZRV
X-Message-ID-Hash: HGOX7HSDU2JVSU7HSEGUPAKDZJOFQZRV
X-MailFrom: job@instituut.net
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Sidrops] Request for Call for WG Adoption (Was: New Version Notification for draft-snijders-constraining-rpki-trust-anchors-08.txt)
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/R94FKw4I6ffSRzkhsPVMyEP9hG8>
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 all,

We'd like to request the chairs to issue a call for WG Adoption for
draft-snijders-constraining-rpki-trust-anchors.

At IETF 121 I presented on the concept of "Constraining RPKI Trust
Anchors", as implemented in rpki-client.

VIDEO: https://youtu.be/pXBPjNQFJmI?si=UJv9braA9Cs3jz99&t=3034
SLIDES: https://datatracker.ietf.org/meeting/121/materials/slides-121-sidrops-constraining-rpki-trust-anchors-00

By now (May 2025) we have some experience with the approach: the
proposed functionality has been available (and enabled by default) since
rpki-client version 8.7 (released in December 2023).

The document is not yet ready for RFC publication as-is. For example,
the constraints listed in "Appendix A" likely would be out-of-date by
the time the document gets to the RFC editor, therefor appendix A
probably ought to be removed before publication.

We'd like to jointly work with SIDROPS towards the following objectives:

* Standardize a domain-specific language for RP implementations in order
  to constrain RPKI Trust Anchors.
* Standardize how the information expressed in the DSL can be applied to
  RPKI validation (e.g. the constraints apply to End-Entity certificates).
* Document how RIR resource transfer policies (or lack thereof) impact
  a Trust Anchor operator's effective signing authority.

Kind regards,

Job

----- Forwarded message from internet-drafts@ietf.org -----

Date: Mon, 05 May 2025 03:33:06 -0700
From: internet-drafts@ietf.org
To: Job Snijders <job@sobornost.net>, Theo Buehler <tb@openbsd.org>
Subject: New Version Notification for
	draft-snijders-constraining-rpki-trust-anchors-08.txt

A new version of Internet-Draft
draft-snijders-constraining-rpki-trust-anchors-08.txt has been successfully
submitted by Job Snijders and posted to the
IETF repository.

Name:     draft-snijders-constraining-rpki-trust-anchors
Revision: 08
Title:    Constraining RPKI Trust Anchors
Date:     2025-05-05
Group:    Individual Submission
Pages:    103
URL:      https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-anchors-08.txt
Status:   https://datatracker.ietf.org/doc/draft-snijders-constraining-rpki-trust-anchors/
HTML:     https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-anchors-08.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-snijders-constraining-rpki-trust-anchors
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-snijders-constraining-rpki-trust-anchors-08

Abstract:

   This document describes an approach for Resource Public Key
   Infrastructure (RPKI) Relying Parties (RPs) to impose locally
   configured Constraints on cryptographic products subordinate to
   publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's
   rpki-client validator.  The ability to constrain a Trust Anchor
   operator's effective signing authority to a limited set of Internet
   Number Resources (INRs) allows Relying Parties to enjoy the potential
   benefits of assuming trust - within a bounded scope.



The IETF Secretariat



----- End forwarded message -----