Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

Andrei Robachevsky <andrei.robachevsky@gmail.com> Fri, 29 June 2012 15:05 UTC

Return-Path: <andrei.robachevsky@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAEF21F8697 for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 08:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he5hP29DeSqG for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 08:05:46 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A489121F86C1 for <sidr@ietf.org>; Fri, 29 Jun 2012 08:05:45 -0700 (PDT)
Received: by eaaq13 with SMTP id q13so1631614eaa.31 for <sidr@ietf.org>; Fri, 29 Jun 2012 08:05:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=FnCJe6B/e7rV2IPRCV7emX++sBaG/IMpX/ukZabkyrg=; b=o2mBMTpdhX8bnm/MmvrMWUPlkC8Ogqok8bveRQStIedZQwL9paZD+Z+IyF9FshkbYC 9H4Ul/Gj/5CqU0IJwGiqmFC9viEG3brtnl90ZC35LuWCBmFFFdV4tsTrIKRTJ6IwrCbD ehCaag2VmU0w7AZMHmppfzkKF6HibgVulCt5OMIrladtmPJCtWLrdE9fZiKBfOnCU622 3WyigCLhaBdGwlMDVV7s4ut4d/BEvB+7pI24vsW/seJySWyL13aIZiqDX+XTYXATJAZy AQ594pyDsMKdHUTYtjM/J3eT+u8MRRVzX9txXnMVFsweUVjV32MDg2jLFvHf9OJkcxTs zMGg==
Received: by 10.14.95.138 with SMTP id p10mr760623eef.110.1340982344723; Fri, 29 Jun 2012 08:05:44 -0700 (PDT)
Received: from Andrei-Robachevskys-MacBook-Air.local (d126092.upc-d.chello.nl. [213.46.126.92]) by mx.google.com with ESMTPS id m46sm8736094eeh.9.2012.06.29.08.05.42 (version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 08:05:43 -0700 (PDT)
Message-ID: <4FEDC445.2030402@gmail.com>
Date: Fri, 29 Jun 2012 17:05:41 +0200
From: Andrei Robachevsky <andrei.robachevsky@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Randy Bush <randy@psg.com>
References: <20120606135903.5473.73476.idtracker@ietfa.amsl.com> <m28vg0lev7.wl%randy@psg.com>
In-Reply-To: <m28vg0lev7.wl%randy@psg.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 15:05:47 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Randy,

Randy Bush wrote on 06/06/2012 16:00:
[...]
> 
> Abstract: There are circumstances in RPKI operations where a
> resource holder&#39;s parent may not be able to, or may not choose
> to, facilitate full and proper registration of the holder&#39;s
> data.  As in real life, the holder may form a relationship to their
> grandparent who is willing to aid the grandchild.  This document
> describes simple procedures for doing so.
> 

The procedures make sense, but I am still trying to figure out what
the draft is trying to recommend.

Surely, what is described is technically possible, but it gives RPs no
clue if the procedures were followed. In fact, what a RP may see would
not be "congruent with the number resource allocation framework" [CP].

IMO a clean implementation would necessarily entail punching a hole in
C's certificate. But this is not what the draft recommends.

Andrei
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/txEUACgkQljz5tZmtij8WPwCg2kRVgtBPaa/R2Ww60zYZEAvs
9koAoOKvcGU06yERG1op2ehL1IQoTvzk
=K7Ly
-----END PGP SIGNATURE-----