IETF Logo Mail Archive

Re: [sidr] Origin Ops, TALs and Local TAs

Danny McPherson <danny@tcb.net> Tue, 15 November 2011 03:58 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 6DCE21F0CBB for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 19:58:09 -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 RyQoIJM-03q4 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 19:58:09 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id EC38E1F0CC0 for <sidr@ietf.org>; Mon, 14 Nov 2011 19:58:08 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id B0CA6268063; Mon, 14 Nov 2011 20:58:08 -0700 (MST)
Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 20:58:08 -0700 (MST) (envelope-from danny@tcb.net)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <CAL9jLaZvdPbzxUe096GCZnSkneMipFdWKtdWKeZt5_x4hFNdxA@mail.gmail.com>
Date: Mon, 14 Nov 2011 22:57:50 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <73084175-C365-4134-8C35-9892115504E8@tcb.net>
References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <20111114234754.33CA96550DD@minas-ithil.hactrn.net> <87819BD9-1829-438C-A479-A315819943D0@tcb.net> <CAL9jLaZvdPbzxUe096GCZnSkneMipFdWKtdWKeZt5_x4hFNdxA@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Origin Ops, TALs and Local TAs
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: Tue, 15 Nov 2011 03:58:09 -0000

On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote:

> On top of that if the resource is then re-certified (to the same or
> different end entity) how do the intermediate parties know which is
> the 'right' thing to do?

Agreed..  It's critical to highlight that LTA doesn't fix anything here
unless this is accommodated by all parties in the transaction path.

Furthermore, because CAs can be compromised (as we've seen with 
many CAs whose @day_job IS security), and today anyone in your TAL 
list can assert authority for any resources (as many are currently doing
currently), without the ability to filter this or scope it in some manner it
could be really problematic.

-danny

v2.23.0 | Report a Bug | By Email