IETF Logo Mail Archive

Re: [sidr] RPKI validator testing summary

Danny McPherson <danny@tcb.net> Fri, 02 December 2011 01:52 UTC

Return-Path: <danny@tcb.net>
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 DE36C1F0C5F for <sidr@ietfa.amsl.com>; Thu, 1 Dec 2011 17:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Y-FXAxgkprPM for <sidr@ietfa.amsl.com>; Thu, 1 Dec 2011 17:52:34 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD191F0C5E for <sidr@ietf.org>; Thu, 1 Dec 2011 17:52:33 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id BF4003681BC; Thu, 1 Dec 2011 18:52:32 -0700 (MST)
Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 01 Dec 2011 18:52:32 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=61054; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <4ED64E04.7030408@bbn.com>
Date: Thu, 01 Dec 2011 20:51:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <968DA738-0BB5-4D66-AA99-173664F60A2F@tcb.net>
References: <4ED64E04.7030408@bbn.com>
To: Andrew Chi <achi@bbn.com>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg <sidr@ietf.org>
Subject: Re: [sidr] RPKI validator testing summary
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, 02 Dec 2011 01:52:35 -0000

On Nov 30, 2011, at 10:38 AM, Andrew Chi wrote:

> The specs leave room for the relying party to decide what to do with imperfect but not completely invalid objects. 

Thanks for sharing Andrew.  One question and one comment...

Is an expired object "completely invalid" or just "imperfect"?  Can you 
explain the difference?

In general, I agree with you that this needs to be codified before we proceed
and I agree with Randy that "I see no reason to tolerate useless incorrectness" 
in a brand new security system expressly aimed at bringing integrity to the mix, 
integrity that is especially important in times of instability and uncertainty.

-danny

v2.23.0 | Report a Bug | By Email