Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00

Russ Housley <housley@vigilsec.com> Wed, 12 May 2021 15:07 UTC

Return-Path: <housley@vigilsec.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 50A403A0930 for <sidrops@ietfa.amsl.com>; Wed, 12 May 2021 08:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 q-gIAS2N5IQY for <sidrops@ietfa.amsl.com>; Wed, 12 May 2021 08:07:34 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A0C3A0925 for <sidrops@ietf.org>; Wed, 12 May 2021 08:07:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 664CC300BE1 for <sidrops@ietf.org>; Wed, 12 May 2021 11:07:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3Yq20vMNmp5T for <sidrops@ietf.org>; Wed, 12 May 2021 11:07:27 -0400 (EDT)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id B20EC300B38; Wed, 12 May 2021 11:07:26 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CAKr6gn2tRD1M=MmZLxHraJHW2iYbn=_hAmyPke3fdpKJSnVRBw@mail.gmail.com>
Date: Wed, 12 May 2021 11:07:26 -0400
Cc: Randy Bush <randy@psg.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <24319C47-1513-46BC-A20E-232F80C8695B@vigilsec.com>
References: <m2k0o6uqot.wl-randy@psg.com> <CAKr6gn3oCZBOP3L8AQWvH9Nk4fum-ycZCnHO_DUtgdx5M=z_+A@mail.gmail.com> <m2fsyuuofa.wl-randy@psg.com> <CAKr6gn18yGTrAiqPA2P+kc+JBt2Tf8D-G4Gf5WCnASm8vk1Fvg@mail.gmail.com> <m21raduy3s.wl-randy@psg.com> <CAKr6gn2tRD1M=MmZLxHraJHW2iYbn=_hAmyPke3fdpKJSnVRBw@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
X-Mailer: Apple Mail (2.3445.104.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/JdObMLUlxOQczLQWuAP4C3mwXVQ>
Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00
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: Wed, 12 May 2021 15:07:39 -0000

George:

I do not understand the value of the "nonce check".  CMS allows multiple parallel signatures.  See RFC 4853 for some clarifications, and see RFC 5752 when there are concerns about stripping one of the signatures.

Russ


> On May 11, 2021, at 7:45 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> You can't provide identity inside RPKI. It's forbidden in the profile.
> 
> You can use RTA and RSC to sign over things, which could be assertions
> about identity. RPKI can't "prove" the assertion. But it can associate
> INR with the assertion.
> 
> If you do an identity check out of band, with a public-private keypair
> (for example doing a nonce check) you can use RTA or RSC to sign over
> things which include the public key you just "checked" in some
> unstated, undefined, OOB manner. This binds the INR to the validation
> of that keypair.
> 
> If you want to define the context of use of the INR and the identity
> in the RTA and RSC, how you do that is out of scope for RPKI.
> 
> All your questions about risk and consequence are valid. They're out
> of scope for RPKI.
> 
> I think repeatedly saying "you can't provide identity in RPKI" is a
> bit pointless. Sure: we all know that. You can "bridge" from RPKI to
> identity, if you use some mechanism to say that, and RSC or RTA can
> help you do that, without breaching the RPKI profile which forbids
> directly certifying identity.
> 
> You asked "how" and I tried to say how. I did it badly. well, that
> doesn't help me sell the idea, I get that, but I still think this
> document is a bit pointless. Nobody is trying to say you can certify
> identity directly, inside RPKI. What I wanted the document to say,
> which would make it more useful (I think) is that you CAN associate
> identity and RPKI, if you do it through a mechanism like RTA or RSC.
> 
> What I say about identity, can be said about Geolocation, or any other
> quality you want to associate with INR.  If it is not permitted inside
> RPKI, then assert a declaration outside of RPKI, but sign over it
> using RTA or RSC.
> 
> Yes, bPKI was a stupid thing to use, to say "some PKI which isn't RPKI"
> 
> -G
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops