Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

Sam Hartman <hartmans-ietf@mit.edu> Wed, 04 May 2011 18:31 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 29DD1E078F; Wed, 4 May 2011 11:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.607
X-Spam-Level:
X-Spam-Status: No, score=-103.607 tagged_above=-999 required=5 tests=[AWL=-1.342, 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 LsxK8ubcoUZs; Wed, 4 May 2011 11:31:45 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A55B1E0700; Wed, 4 May 2011 11:31:45 -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 A654D20222; Wed, 4 May 2011 14:27:57 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A52F141F4; Wed, 4 May 2011 14:31:39 -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]> <tslboziadpf.fsf@mit.edu> <p06240803c9e6f3747d1c@[193.0.26.186]> <tsl1v0ebkor.fsf@mit.edu> <p06240802c9e73842b579@[193.0.26.186]>
Date: Wed, 04 May 2011 14:31:39 -0400
In-Reply-To: <p06240802c9e73842b579@[193.0.26.186]> (Stephen Kent's message of "Wed\, 4 May 2011 13\:20\:38 -0400")
Message-ID: <tsly62m8ghg.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 18:31:46 -0000

Steve, I'd like to thank you for working through these issues with me.
I think the new texxt you added before approval is very helpful.  You
indicated you could add an additional sentence pointing out that
multiple signed objects would need to be used in order to deal with
phase 2 for end-entity certificates.  While I think that would be
reasonable to add, I also don't think it is necessary.
I'm sorry the upgrade approach was not more obvious from the beginning.
>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:

    Stephen> I find your last sentence above confusing.  I would say
    Stephen> that the BGPSEC protocol will have to define how it deals
    Stephen> with alg changes for the signed objects it defines, with
    Stephen> key changes for RPKI certs, with alg changes for all RPKI
    Stephen> objects, and with format changes for RPKI objects and for
    Stephen> its own objects.

Excellent.  Please consider it early input to the WG process that how
the protocol deals with all of these issues should be documented. The
sort of structure you adopted for the text added to cert profile seems
like a fine style to use, although of course there are others that would
also work.  What I think is important is that the IESG and community at
large be able to evaluate these transition issues when the protocol
comes up for IETf review.

In conclusion, thanks again for your help. I see you're giving a talk
next Thursday on these issues at an ISOC chapter meeting; I hope to attend and better come up to
speed.