Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt

Stephen Kent <> Fri, 15 July 2016 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68E0512D0E9 for <>; Fri, 15 Jul 2016 10:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AALWMqzhBkyx for <>; Fri, 15 Jul 2016 10:28:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D57B12B04D for <>; Fri, 15 Jul 2016 10:28:36 -0700 (PDT)
Received: from ([]:54094 helo=COMSEC.fios-router.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1bO6ud-00065k-0U for; Fri, 15 Jul 2016 13:28:31 -0400
References: <> <>
From: Stephen Kent <>
Message-ID: <>
Date: Fri, 15 Jul 2016 13:28:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/mixed; boundary="------------77B09798B26354C6D8BF2334"
Archived-At: <>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jul 2016 17:28:38 -0000


I reviewed the -06 version and am attaching a pdf of the MS Word file 
with suggested edits. I can send you the word file itself if you wish.

I have provided text to my co-author, Sean, to include in the 
bgpsec-pki-profile doc to address your concern. I suggested the 
following text at the beginning of section 3 :

    The validation procedure used for BGPsec Router Certificates is
    identical to the validation procedure described in Section 7 of
    [RFC6487](and any RFC that updates this procedure), but using the
    constraints applied come from this specification.

Sean added an implementation considerations section which I suggest will 

    Operators MAY choose to issue separate BGPsec Router Certificates for
    different ASNs. Doing so may prevent a BGPsec Router Certificate from
    becoming invalid if one of the ASNs is removed from any superior CA certificate
    along the path to a trust anchor.

I hope these changes avoid the need to say anything about router certs 
in your doc.

I'm not sure there is a need to change the ROA spec. If we agree that 
all prefixes in the ROA MUST be contained in the EE cert for that ROA, 
then the current text in the ROA spec does not need to change.