Re: [secdir] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

Yaron Sheffer <> Tue, 03 January 2017 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E13371297BC; Tue, 3 Jan 2017 13:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f9yw6BKFUoCY; Tue, 3 Jan 2017 13:47:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 909231297A7; Tue, 3 Jan 2017 13:47:06 -0800 (PST)
Received: from [] ([]) by (mrgmx003 []) with ESMTPSA (Nemesis) id 0LztHH-1ccm1M35Od-01546h; Tue, 03 Jan 2017 22:47:04 +0100
To: Sean Turner <>
References: <> <>
From: Yaron Sheffer <>
Message-ID: <>
Date: Tue, 03 Jan 2017 23:47:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------161B0AC6809EC36B16E83D53"
X-Provags-ID: V03:K0:4lgKQNzYkldrkBW6qQ+aO304NoHE21lhQpz/bjrQxrPhX7Ny2f8 KiF5svvaAnF9+3v8KClzqUnhdF16fccd2HdXj9pHWmYToBtk19wfI2+sEqVivYK0cxTFVsG XslK9vyTFSsjFegfaz4lk+4O9zDjE3ed7+4pKc/+VYSmUysF3/MLdcM2bEVgk7CZGsjz9ek WAGqPTWztC+B7d/8veWig==
X-UI-Out-Filterresults: notjunk:1;V01:K0:AnUGOv4GaKg=:v6oXwLLAH3iVbvwj9BdU+f TANXek75RjrZ8hLxIqV0rjcrNAzTU4wEzTDDGuavjiw78ay3rTMWPYhWb/tZ9Hnt+p0jioAai Mtk8dfBx94OtpJ7bhzyNBqMmin0DmvY/cD7rNoA+WC3flgFxwZo+9EXrTk3jjaHTVK9yQJx6b TcA2+jcogSHLj7Q4UnSGEms0GM7m6rAVOqHCC71A0jUCxaqiPSTLOUc5J/F8C0smKTX0TvXP4 jDfwQeiHLaKuq7ES8hn9EOSmnBPBYcMGY6/P0SwC5VJBHlFruTpU3hUuybmY8lTzykraRWPWe 2jSCyvw71jJYMUIP7fw+YSzcDo7Y/WpIfDTjek0jA43UCEgNFmmOtpY7+EtzdWzLw5tmVbrXE 9lUkZxETbDy0pQ+x1gubZdKhOGOoX69vR5dhClgpDgwArPFLtcTLQRl0APv+URq1WMSYJc2Y1 7+AJQ1HaCoBG7TiNA38IxSO1K+QvsCTO5FYGt/xEWUrLRNxDm9QY9zXh/VCeex7SweAxzUp2q ELo/bYHLdIYtpXk1nsINtuJsbOts5mhQEVC2Zgoll4/RcKcsYR1FbcwB911+nLaxv02yIdMoi TVPkcZtKXyKT7pXI7VjttR43ZyhrxfJ9RV/dtxwzDHovgnovzWEM9hp4M85y5eowbJXukHFc8 djAv8WJ1y6fWj3S6hkjgC/8mGNHk0yd7QHyIGJPSJoGNvV6vNJHqDzzJRRo6THS9Lded0rqjm IwsCsyEnbKd/9Fim8B5EZgkWoTG7IcTOWAXyrn5lYaMdwc1U4uVf/38bM0uEg2z9qWCRggp4H oh63YDa
Archived-At: <>
Subject: Re: [secdir] Review of draft-ietf-sidr-bgpsec-pki-profiles-19
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jan 2017 21:47:44 -0000

Hi Sean,

Please see below.

On 03/01/17 18:12, Sean Turner wrote:
> Yaron,
> Thanks for the review.
>> On Jan 1, 2017, at 11:26, Yaron Sheffer <> wrote:
>> Reviewer: Yaron Sheffer
>> Review result: Has Nits
>> * 3.1.1: The serial number in RFC 6487 is still a real, unique serial
>> number that uniquely identifies the certificate. Here it is used as
>> something other than a serial number, which is explicitly NOT unique,
>> and the CA is left to decide how to make it unique in the face of
>> potentially repeating BGP IDs. If this is not a real issue (e.g.
>> because duplicate IDs are rare and never within a RIR), please say
>> so.
> As Rob pointed out this paragraph is talking about the serial number naming attribute.  Maybe something like:
> r/only two attributes/only two naming attributes
> and
> r/common name and serial number/common name (i.e., X520CommonName) and serial number (i.e., X520SerialNumber)
> People ought to them be able to track down the definitions.
I'm good with these changes. However, according to Randy's response to 
my review, the text later on is subtly incorrect (or at least 
misleading). Router IDs are not globally unique, but the combination of 
AS Number and Router ID is in fact globally unique.

>> * 3.2: earlier we said that Basic Constraints must not be included in
>> the EE cert. Now we are saying that only a particular boolean flag
>> must not be honored when processing the Cert Request. What happens if
>> Basic Constraints is included in the Cert Request but with other
>> flags?
> The CA is ultimately the one who decides what gets issued.  A good CA would know to only issue properly formatted BGPsec certificates either by ignoring the improperly requested “feature" or rejecting it outright.  Since these CAs really aren’t open CAs then the CA ought not get caught off-guard with requests.
I'm not sure I understand. Why not give a consistent advice to EEs and 
CAs, e.g., reject any request that includes any Basic Constraints.
>> * 3.3: ID.sidr-rfc6485bis -> RFC 7935
> drat I missed one.
>> * 6: in the paragraph that discusses hash functions, please spell out
>> the names of the two key identifiers, because I cannot determine what
>> they are from the document.
> Ack they’re the key identifiers in the cert: Subject Key Identifier and Issuer Key Identifier
> r/two key identifier extensions./two key identifier extensions (i.e., Subject Key Identifier and Issuer Key Identifier)
> spt