IETF Logo Mail Archive

Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt

Ties de Kock <tdekock@ripe.net> Tue, 10 August 2021 13:35 UTC

Return-Path: <tdekock@ripe.net>
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 05D9B3A0A7E for <sidrops@ietfa.amsl.com>; Tue, 10 Aug 2021 06:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSlriFZkBHvv for <sidrops@ietfa.amsl.com>; Tue, 10 Aug 2021 06:34:58 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 14E743A0A88 for <sidrops@ietf.org>; Tue, 10 Aug 2021 06:34:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=LNfOrOUSErve4bUbK5HcIHEL8mgpJ+m68DMJeAge9dA=; b=ll2EjdENvk0aqD/6EwdF/HPE PopuH5icaOdtWuTGfcbasrYtdPTr5SWwrU0t6NQEwsFPqvaozUiYoDjrMHWQgjgP2TgXHfQn871AM HrZ/ytn6ae79FAnN0NvMc144eCJ90GelUXjnwhhZHZDq7lz4bBBTwjEfPXSPn1IwUOwqyT1QrD/03 GrPYn7oYNBarRCS3M+oFYEuzfabC78KbDOzfQZDosXHN0jFsgWUIBdR7saLoc2h/De6NLeO4Ul0eU oEAvSf/ubymZQD6ay6YvJOUAjxrsebxl05RSLeGR0ZIibgipnAEGIPUcLP3FwRmK18eI9HWbjPtzr ReLp1njt2g==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:40410) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mDRu5-0006Ck-He; Tue, 10 Aug 2021 15:34:49 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mDRu5-0000d7-EM; Tue, 10 Aug 2021 15:34:49 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <m25ywemmn5.wl-randy@psg.com>
Date: Tue, 10 Aug 2021 15:34:49 +0200
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8170EFA9-8832-4B7A-816D-9829790C23FA@ripe.net>
References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> <m2bl671xbk.wl-randy@psg.com> <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net> <m25ywemmn5.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e14d60464cadbb85b8b7ac57ed3ff1844c
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/AzlYAyHpUFMMx4ZqoOp5mP0wCHo>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Aug 2021 13:35:04 -0000


> On 9 Aug 2021, at 21:41, Randy Bush <randy@psg.com> wrote:
> 
>>> In large organizations, INR management is often compartmentalized
>>> with no authority over anything beyond dealing with INR registration.
>>> The INR manager for Bill's Bait and Sushi is unlikely to be
>>> authorized to conduct bank transactions for BB&S, or even to
>>> authorize access to BB&S's servers in some colocation facility.
>> 
>> About this paragraph: This may even need to be more specific.
>> 
>> I think that the department performing INR _management_ often may not
>> even have legal authority to change INR _registration_s. I imagine a
>> department that can change the data related to the INR registration
>> (“update the ROAs”) but not manage the INR registration (“garage sale
>> of the IPv4”).
>> 
>> For the latter you (hopefully) need legal signing power.
> 
> yes, but ...
> 
> i do not see where rsc/mta/... and folk wanting to sign bank statements
> with registry data are asking to change the registry database.  clue
> bat, please.
> 
> randy

I was thinking about the situation where an actor uses an RPKI object to lead
people to believe they have legal authority to sign contracts concerning the
resources.

RPKI does not have identity but it does not imply being an legal representative
either? I was wondering if we needed to clarify that as well.

-Ties

v2.23.0 | Report a Bug | By Email