Re: [Sidrops] Making ASPA AFI-Agnostic - coordination (Was: WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023))

Job Snijders <job@fastly.com> Wed, 07 June 2023 16:58 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 5C316C1519BB for <sidrops@ietfa.amsl.com>; Wed, 7 Jun 2023 09:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 hdklGyt9RlKX for <sidrops@ietfa.amsl.com>; Wed, 7 Jun 2023 09:58:12 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 BF986C1519A7 for <sidrops@ietf.org>; Wed, 7 Jun 2023 09:58:12 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-9745ba45cd1so1011478466b.1 for <sidrops@ietf.org>; Wed, 07 Jun 2023 09:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1686157091; x=1688749091; 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=o98nrjIQFjVBvIeAzBx3iprzei2imnwENqpu0JBQzLw=; b=wODFKrImeZfDAwLNSwVBl25Mp4MAXX6Vbrw0UrQB47ac2nZvM+H3Pwe+2PjrE0KgXk aE7C1ABH/AVkFDdRKi7tqr6ArTVLkAfE3gZAbAJJyfYmFcOfXqm8x6ib+WX3Klqb9qOC kajG+abnfRwJoyzb1VAhGhkt07c4VEs9t37vU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686157091; x=1688749091; 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=o98nrjIQFjVBvIeAzBx3iprzei2imnwENqpu0JBQzLw=; b=BIMTyVM9+cZ1qZbVwL2/Sc1KBSjZy6Ghx1GNghVHo/h0Bsirq6yQFQscQEaK116eII rec1XwyQZS9y+rnXi8lZ1o93Im5DxI/asyh2JUi/Arsrg/TZshdjXRNeZ0kAG9QtLzCb /FGEDiUxJjMTJRK78xSwjH4Z1H2KlgQo8PclerRKn4CZ7w6+G7HavQmhx3yZLsQ8v9lB DxO44lLkG4KiACKrI401JFYPVgrXNA4Nf10jEuKxPMg8T8RfHpNy7dJVMRDjUKXk+PIG 1SawToidPeRYX3I+JFsMRNIexJ9rqP7sCVrkPnDwBO4uZz1dFwO1BEv6xjh5CVd3Cf1a GGUA==
X-Gm-Message-State: AC+VfDwN8K9BtO9+T3GK97RT3HBdfXw29flPpnCwApsvOuIt3BUT5zuI pxZmC+K86xPx95wh+Mo2VY6YeQ==
X-Google-Smtp-Source: ACHHUZ7IdHgswBUHp5lyWCvGtcpZDtMD/SJxE+2ilClLRljVik4kK6JCdjDQzIQk86bRZhMXNajGpw==
X-Received: by 2002:a17:906:6a15:b0:970:c9f:2db6 with SMTP id qw21-20020a1709066a1500b009700c9f2db6mr6589138ejc.63.1686157090814; Wed, 07 Jun 2023 09:58:10 -0700 (PDT)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id u23-20020aa7d897000000b0050cc4461fc5sm6349932edq.92.2023.06.07.09.58.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 09:58:10 -0700 (PDT)
Date: Wed, 07 Jun 2023 18:58:08 +0200
From: Job Snijders <job@fastly.com>
To: Martin Hoffmann <martin@nlnetlabs.nl>
Cc: Russ Housley <housley@vigilsec.com>, "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-8210bis@ietf.org" <draft-ietf-sidrops-8210bis@ietf.org>
Message-ID: <ZIC3INsvwZNJAWhH@snel>
References: <20230502124540.6bc662ba@glaurung.nlnetlabs.nl> <CAL9jLaaL2vvRYL6+ftu8vP9fDWWBoF5NFCGGL_nDj+_VSc5E4Q@mail.gmail.com> <ZH+hdvAwuZ7nN3vK@snel> <4dbb0ef4-91fc-6bbd-d979-2d0b736295ac@tu-dresden.de> <ZIBJUycE10HjIfAP@diehard.n-r-g.com> <BLAPR09MB63226569F3349669ABBEA60D9853A@BLAPR09MB6322.namprd09.prod.outlook.com> <62C121A4-DD89-477A-98EC-4356420F4888@vigilsec.com> <BLAPR09MB63223FFA678A45B6530265B49853A@BLAPR09MB6322.namprd09.prod.outlook.com> <AEE28B86-CACA-4280-99C4-505EC4A16963@vigilsec.com> <20230607184927.56a48b58@glaurung.nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230607184927.56a48b58@glaurung.nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-j2AGDou4THj7dwMLvQFuFrR2rc>
Subject: Re: [Sidrops] Making ASPA AFI-Agnostic - coordination (Was: WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023))
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: Wed, 07 Jun 2023 16:58:16 -0000

On Wed, Jun 07, 2023 at 06:49:27PM +0200, Martin Hoffmann wrote:
> Russ Housley wrote:
> > 
> > 3.  What are the consequences if those implementations if the RFC
> > uses the same version number with a different structure?
> 
> Hm, this raises in interesting point not about RTR but about the ASPA
> profile. Have there been ASN.1 defined protocol structures where a
> version change triggers an entirely different definition rather than
> just extending the original? E.g., in X.509 certificates, the version
> number just mandates different extensions or limits certain optional
> values.
>
> Maybe a better approach would be to use a different content type OID?

The first approach that came to my mind was to bump the ASPA version
field in the eContent, as can be seen in the likely next version of the
draft here: https://github.com/QratorLabs/ASPA/pull/15/files
(I assume nobody is surprised by mod-rpki-aspa-2023)

A new content-type OID certainly is another valid approach. This might
make it easier for DER deserializers to earlier on recognize which of
the two flavours the eContent is going to be.

Do people have a preference one way or another?

Kind regards,

Job