Re: [sidr] comments on draft-ymbk-sidr-transfer-01???

Geoff Huston <gih902@gmail.com> Thu, 08 October 2015 21:45 UTC

Return-Path: <gih902@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C3E1ACF55 for <sidr@ietfa.amsl.com>; Thu, 8 Oct 2015 14:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 wid1B3XGUuV7 for <sidr@ietfa.amsl.com>; Thu, 8 Oct 2015 14:45:02 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4C81ACF1D for <sidr@ietf.org>; Thu, 8 Oct 2015 14:45:02 -0700 (PDT)
Received: by qgez77 with SMTP id z77so54373381qge.1 for <sidr@ietf.org>; Thu, 08 Oct 2015 14:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9zt6p4uLaszGQdAG5TXVzT2mhqE2w6BZ914+98Zq5A4=; b=tAXMehO5vSEO5pDM9o+h101T1S5Ly3r+GZV5uPNPdqkzYETJ88jKohjkYaj9+/QCd1 L2fGbDt2G+Gv35Zu7h3JKmme3BywQfJO1B8yhjCUDf+VRU6wZxDvmKCThoQBu5h1gc+2 +a+RQpbd8q2Wbfzd+9c2nfqijMLZf5oArkdWwcnPyIMeFRKJSrjtiUQptsuagA3hcCuy aJXjx+bY+9tcYwWInyg2dfyGrxixD6FZp+9uBAGSSx5d5CIAH8kqLbJbpDzOeyfFj0Rh 1uGsV41zRZuNgyfsOqjctJ++eVuByXORVpRI0JRt/b1VfRN2j5GGa75PGkhDPbVZ1y1i jq4g==
X-Received: by 10.140.93.68 with SMTP id c62mr11400186qge.54.1444340701654; Thu, 08 Oct 2015 14:45:01 -0700 (PDT)
Received: from [172.16.137.34] ([216.46.0.94]) by smtp.gmail.com with ESMTPSA id y12sm19567032qgd.20.2015.10.08.14.45.00 for <sidr@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Oct 2015 14:45:01 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Geoff Huston <gih902@gmail.com>
In-Reply-To: <C881A1D8-ADD9-4FE9-90D3-3C6DAA57C5EB@tislabs.com>
Date: Thu, 08 Oct 2015 17:45:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7C8F00F-3B91-43E7-AD0A-8C83FEB30A05@gmail.com>
References: <C881A1D8-ADD9-4FE9-90D3-3C6DAA57C5EB@tislabs.com>
To: sidr wg list <sidr@ietf.org>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/eqQymmXbcgWri9dqoKM4waSmxMo>
Subject: Re: [sidr] comments on draft-ymbk-sidr-transfer-01???
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 08 Oct 2015 21:45:03 -0000

> On 8 Oct 2015, at 2:56 PM, Sandra Murphy <sandy@tislabs.com> wrote:
> 
> The draft draft-ietf-sidr-rpki-validation-reconsidered speaks forcefully of the potential for damage if a certificate over claims, i.e., claims more resources than its parent.  The draft discusses how that could result from a failure of timing in a transfer of resources.

** or form any other form of a drop in precise synchronisation between the CA’s number resource database and the state of a CA’s issued certificates.

While I’m sure perfection is an admirable objective, snafus do occur, and another part of the motivation of the reconsidered document was to reduce degree of catastrophic result from certain forms of certificate issuance failure from one where all subordinate certificates cannot be validated to one that impacts only of the validation status relative to the resource that was placed in this inconsistent state.

i.e. validation reconsidered is not 1:1 isomorphic to just transfers, as you may have been led to believe from the next sentence...


> 
> In a presentation in the November 2014 IETF session on this topic, it was suggested that discussion of "a standard procedure for certificate management during resource transfer” and "current CA operational procedures for managing transfers” would help in the reconsideration of the validation algorithm.
> 


regards,

   Geoff