Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Sam Hartman <hartmans-ietf@mit.edu> Wed, 04 May 2011 11:48 UTC
Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4671FE0748; Wed, 4 May 2011 04:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.409
X-Spam-Level:
X-Spam-Status: No, score=-103.409 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jUNqyDuAkyA; Wed, 4 May 2011 04:48:54 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C7800E0708; Wed, 4 May 2011 04:48:53 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2AE862034A; Wed, 4 May 2011 07:45:03 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F43441F4; Wed, 4 May 2011 07:48:44 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Stephen Kent <kent@bbn.com>
References: <tslhbbag9m1.fsf@mit.edu> <4D791B26.8020001@vpnc.org> <tsl4o7ag5fw.fsf@mit.edu> <4D79271E.6080707@vpnc.org> <tslzkp2elyf.fsf@mit.edu> <p06240801c9ce424e70b1@[128.89.89.62]> <tsl62q2tj33.fsf@mit.edu> <p06240808c9e45144c8f9@[10.242.22.94]> <tslr58fbz9t.fsf@mit.edu> <p06240800c9e604898d1c@[193.0.26.186]> <tslk4e7a14w.fsf@mit.edu> <p06240803c9e6ae6a7fe9@[193.0.26.186]>
Date: Wed, 04 May 2011 07:48:44 -0400
In-Reply-To: <p06240803c9e6ae6a7fe9@[193.0.26.186]> (Stephen Kent's message of "Wed\, 4 May 2011 04\:00\:18 -0400")
Message-ID: <tslboziadpf.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2011 11:48:55 -0000
>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes: Stephen> The BGPSEC protocol being defined does not pass around ROAs Stephen> or other RPKI repository objects. It defines two new, Stephen> signed objects that are passed in UPDATE messages, and are Stephen> not stored in the repository. These objects are verified Stephen> using RPKI certs and CRLs, so there is a linkage. OK, so how will the upgrade work for these signed objects? In particular during phase 2, when both old and new certs (under the old and new profile) are in use, what happens with these signed objects? Can a party generate both old and new signed objects? If so, will the protocol scale appropriately? If not, how does a party know which signed object to generate?
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Jeffrey Hutzelman
- [secdir] Secdir review of draft-ietf-sidr-res-cer… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Paul Hoffman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Paul Hoffman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Rob Austein
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Martin Rex
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… John C Klensin
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman