IETF Logo Mail Archive

Re: [Last-Call] [lamps] Fwd: Last Call: <draft-ietf-sidrops-rpki-has-no-identity-04.txt> (The I in RPKI does not stand for Identity) to Proposed Standard

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 05 March 2022 18:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F53D3A0A42; Sat, 5 Mar 2022 10:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 g_7HgNzSmQAd; Sat, 5 Mar 2022 10:55:37 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746B83A0A40; Sat, 5 Mar 2022 10:55:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F6ED38CEB; Sat, 5 Mar 2022 14:04:46 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5sIfQz8uTGUi; Sat, 5 Mar 2022 14:04:45 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1374338CE9; Sat, 5 Mar 2022 14:04:45 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1646507085; bh=jIlrzv+4T/Ut/O8tVlm82CalDqfMRjiCUd4C+roDdiA=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=DWvP5BDQThXliLD/G2O04kGGm1NsBfSFGFqZyuW1Sva7nxbhHVu8zn1Sp+WGkQjbq Wy8vkHvBLEmSnkF2TRUx2eVcoQQLugAJrVhqvbWPPCcddmWidhAq0TpBRs/7z4SjQf ly+VZ1Io0gD3uPUvlSNT4m3WLxHX/ndiQRYEC87ejmmGk5N59bfSRuYU8tvhdlBaIo sRf93SNoGXCskQrwTyeQ7TQBbkNh7pI1rmjQdnDqpwjCXpfM0SIWZw/aIUZ1hKyoVj bmGrZ6LUy4reqy/H6g0yG5n/3dKydoh5h/B/7hYlwxg3ctXoid3fffC04UJYM+UlP5 /+fM0obOfSKxg==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CC4191D3; Sat, 5 Mar 2022 13:55:32 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Michael Jenkins <m.jenkins.364706@gmail.com>, last-call@ietf.org, sidrops@ietf.org
cc: Benjamin Kaduk <kaduk@mit.edu>, LAMPS WG <spasm@ietf.org>
In-Reply-To: <CAC2=hndffAKVtKCgLkiie_LjVH5R5uFQ02b3S_aH+B9OMqa+Yw@mail.gmail.com>
References: <164642447410.28300.14979172722907480601@ietfa.amsl.com> <20220305043121.GH22457@mit.edu> <CAC2=hndffAKVtKCgLkiie_LjVH5R5uFQ02b3S_aH+B9OMqa+Yw@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sat, 05 Mar 2022 13:55:32 -0500
Message-ID: <22829.1646506532@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/6S5RbkjgZOENMa7IQ6ttSB7MrRI>
Subject: Re: [Last-Call] [lamps] Fwd: Last Call: <draft-ietf-sidrops-rpki-has-no-identity-04.txt> (The I in RPKI does not stand for Identity) to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Mar 2022 18:55:43 -0000

Michael Jenkins <m.jenkins.364706@gmail.com> wrote:
    > It appears that RPKI certificates are actually authorization bearer tokens
    > issued by the CA. The CA holds the private key, and the INR holder doesn't?
    > But somehow does, and is somehow using it to sign invoices and love
    > letters.

I read that part too, and I was a bit confused as well.
It's not that the CA holds the private key to the EE RPKI certificate.

It's that, the EE RPKI certificate, being a certificate, is signed by the CA.
(Exactly as you'd expect any CA->EE certificate).
The RPKI certificate is a statement of ownership of INRs by that EE.
That certificate can be updated/replaced based upon somewhat weak
username/passwords logins to the RIR's web sites.

The EE certificate can then be used in various forms of BGP security (mostly
not yet well deployed), and also to sign policy objects about which ASN is
authoritative for which prefixes.

    > Ultimately, I'm not sure why anyone will pay attention to this RFC(-to-be)
    > any more than RFC 6480, which apparently already says "An important
    > property of this PKI is that certificates do not attest to the identity of
    > the subject" - which again calls into question whether these are
    > certificates at all (as opposed to authorization tokens). Maybe the
    > solution isn't more RFCs asserting the lack of identity binding, but more
    > token management?

I agree.
I don't think another RFC will help among those technical people who really
understand things, nor will help among the semi-technical lawyers who don't understand things.
It's only the people in between that might be impressed by an RFC.

If I want to sign an agreement with AS64512 for something, and my lawyer says
that I can obtain AS64512's public key from the RPKI, then it seems like
maybe that's between me and my lawyer.
Maybe we also want to exchange some hashes of SubjectPublicKeyInfo as well,
but that would really be a private discussion.

Should I be concerned that the people who control the HSM for AS64512 might
not be authoritative to sign contracts?  Sure.   Do I need an RFC to tell me
that?  I dunno.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.8.7 | Report a Bug | By Email