[stir] stir-certs-01: Expert Review?
Eric Burger <eburger@standardstrack.com> Mon, 20 April 2020 17:26 UTC
Return-Path: <eburger@standardstrack.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 29B1B3A0D90
for <stir@ietfa.amsl.com>; Mon, 20 Apr 2020 10:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.212
X-Spam-Level:
X-Spam-Status: No, score=0.212 tagged_above=-999 required=5
tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001,
T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001]
autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral
reason="invalid (public key: not available)"
header.d=standardstrack.com
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 dBE79rj9Dz4N for <stir@ietfa.amsl.com>;
Mon, 20 Apr 2020 10:26:43 -0700 (PDT)
Received: from se3b-lax1.servconfig.com (se3b-lax1.servconfig.com
[192.249.122.52])
(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 38F073A094F
for <stir@ietf.org>; Mon, 20 Apr 2020 10:24:57 -0700 (PDT)
Received: from biz221.inmotionhosting.com ([192.145.239.201])
by se3-lax1.servconfig.com with esmtps
(TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92)
(envelope-from <eburger@standardstrack.com>) id 1jQaA4-00158P-JR
for stir@ietf.org; Mon, 20 Apr 2020 13:24:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=standardstrack.com; s=default; h=To:Date:Message-Id:Subject:Mime-Version:
Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=VrTtW8wc5ENev5gyIb2W48CrfU/1DlFhS619PbYnWS4=; b=Bd+haB/xtm/pG0OOEcXfhbtEGg
eg46OzrSzDykFeAzmE/i4bKnjvZQOUiTjpnB5uK56BJHcwIfYOwN65onN8auByTbAfWBOxn0YvmC/
hQQ5tXk25OlSrmkj2nX4+8gibhZW4CsikmhvYm0Gl0gzHHguEqlVhwmoquxWRttlgawU=;
Received: from [68.100.101.142] (port=50898 helo=[192.168.10.31])
by biz221.inmotionhosting.com with esmtpsa (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93)
(envelope-from <eburger@standardstrack.com>) id 1jQa9t-000ZGm-FY
for stir@ietf.org; Mon, 20 Apr 2020 10:24:38 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_BE591C79-1665-4403-BAAD-1CAAFC5AD6EB";
protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <FC4D5270-23BB-4DB4-9770-92C452E44AA8@standardstrack.com>
Date: Mon, 20 Apr 2020 13:24:36 -0400
To: stir@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-OutGoing-Spam-Status: No, score=-1.0
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id:
eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
X-Originating-IP: 192.145.239.201
X-SpamExperts-Domain: biz221.inmotionhosting.com
X-SpamExperts-Username: 192.145.239.201
Authentication-Results: servconfig.com; auth=pass
smtp.auth=192.145.239.201@biz221.inmotionhosting.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.23)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0c6d8zDasFm/nDPEg7mmhmypSDasLI4SayDByyq9LIhV80FebxDGQ3hk
KC7NGwmQWUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD+8X2eAtGOeP0Z7XEw4vpH7gN
zB/4Jkrw1eDLcif59fuY98JE9j0uSuXxPJTdyPN5U7Tmz6iKnkQL9gqsxD3473Y3lsYPr3virg95
tZ609xdKJaSO6x9h2WTFfkPgGUz1Sq2swcqdmOMtvfhrEkAbG/8vT6Pv5EmK9Y3QKXNOxPMnUiya
RmA46OGY+YsgOdbd3VAnSZlBxACg67tWDDh3WMpOFwbgZzA7SHJpgzfyrZMpuUU9pQmhp2NdRojj
VXAB3i4EXXSueZzMCpX2tfOqKM5soQ0R2jS4GxDcxPFGC79DsyPhMEwz2OC3hXjXYvpwQy17Ychx
ni5a2VYVYiL6p0zFIS4eFFedtqTPxkQeRTMManwrT2CVoVKwL3beb5/7R86t2EiC6GwMws7Gvvoz
wOxTyssp4L0plUGigax8zy4LpVxP5YFZg5fgueXLf6LKHDJ71JSXKkUqfqsTqwEEUOidX4Ts4xdG
+C13IyWeZaKeZonfhSS5rkKZop8UxONQt/RjRaooN74bt/9RkI3xQgdb9bovQJYN4df8tBGzfisF
VVikJYXKyGo2lFnLPaHwOuqJPPu/Mw4caI9hNjB7gP3QzxUBjDlIxq/CY6GWA8+LBDMrD7q/cJog
wbqzsuoksATD6B4YJw/xkJTvi2DZT2gxaUBTIJceeww0VXdyJ0ndbXSgkufh1ojus/5BUx9USFs8
QJ1HZ0YgjVUEghT1aTwJWw42swm4bO6gacpMpzJJAaQB6RGfbERqROM6OR63chyvPJpL6DooRBPw
XkYc1RNWLRL0zEKCV1rC6yEoKMXwY8LwTJ3glwd29LcBySVMm98OiyQ6+7o3FFiI0zRNn0gvzxVp
TGvrZrKdIxaZrH3oREI39Ng7w+jWwVgutjGnuuve+J5DMBKo4X0ih5QNkGE9sb8xJz7YLbS4YH6b
pqcEiBscwRdrth+1+oWTDTjsecoU4vapvCGSUh6RXSeW2w==
X-Report-Abuse-To: spam@se1-lax1.servconfig.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/pGqoPDxk3r9r6aw9PLRVo9YLfBo>
Subject: [stir] stir-certs-01: Expert Review?
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>,
<mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>,
<mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2020 17:27:03 -0000
I heard two broad schools of thought on expert review. One theory is that since making determinations of who is authorized to update registrations is fraught with unsolvable Layer-9 issues, and since IANA is ill equipped to solve unsolvable Layer-9 issues, that IANA should take an extreme hands-off position and register anything that comes their way that meets the “identify the registrant” criteria specified in the draft. The other theory is that IANA can pass off requests to an expert that can triage registrations that would pass the “identify the registrant” criteria yet be obviously bogus. E.g., 10,000 registrations come in at once from the same place registering things that have a globally accepted, well-known authority, and it would be obvious the registrant does not have those authorities. However, we would “know it when we see it” and stay clear of the many jurisdictions where various governments, some UN recognized and others not, lay claim to a particular resource. In those instances, as laid out in the draft, we could have multiple registrations and not have IANA get into the Layer-9 (Layer-10, as now we’re talking governments of governments?) unsolvable problem. Opinions? I did hear Alyssa say that if we lay out easy to follow, clear, uncontroversial steps, IANA can cleanly execute them. So, if you’ve got an algorithm, put it forth now.
- [stir] stir-certs-01: Expert Review? Eric Burger
- Re: [stir] stir-certs-01: Expert Review? Brian Rosen