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

Sean Turner <sean@sn3rd.com> Thu, 05 January 2017 00:52 UTC

Return-Path: <sean@sn3rd.com>
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 87DEF1294B0 for <secdir@ietfa.amsl.com>; Wed, 4 Jan 2017 16:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCLHiqnVsi1q for <secdir@ietfa.amsl.com>; Wed, 4 Jan 2017 16:52:06 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADC71294A5 for <secdir@ietf.org>; Wed, 4 Jan 2017 16:52:05 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id s140so5545979qke.0 for <secdir@ietf.org>; Wed, 04 Jan 2017 16:52:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3KWTKhi6ZWFqcVA+qbp12Y/8xx04rTjfHgWaXDKcnIo=; b=OJ0JSQ9GLFiPD+Xtf0MMxhk6qxw4h2TMOn87Pg1HpAj4mjlDVoRWX+NyH6KxJvETBa I+BtyVF7R/8LkUAQ3P4HgHoiOcJCoR4AyeVXzgQl7WYg1puTgFq6q6ZNMAdyKS6p8gqi 69owZBbDy7YWaauQJOVLdFHVbDO2WrBliXAX4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3KWTKhi6ZWFqcVA+qbp12Y/8xx04rTjfHgWaXDKcnIo=; b=OwyEYB/2CC0kR6oBmgsuFqHQTXftTjGeO6FlDJ+bzg5E+gy7OZoQeP1AQcpwbCa0r4 iMJWw6AePGudE8oHkIhBnb1qIL8IodsTPLAS0Nfao6rh4c2A5HpshRAZgx93NR0Yn5jT 7TjMZbe93TTBW58klQ8BUzvQxhcPch3wngb0vfQiQH3Jt8hComJs1WmBvuZ9S9pzRcn9 0ihT8IkKnMStavaRUhSjdefn6+gZp2CQLljG353ThdD00F/lmVKlDOLGeQ0dKYezFzWz +5AD5A2Qr3rwbiTJB9nCxVxlqQaksvGnYgdisZO7mptli4ih36QDyzyMLOJkGGu3qvNA ST7A==
X-Gm-Message-State: AIkVDXJ3tOS0jIGod45PtJ5LXXGZh4hAnLm6gazXmbmvGquzKNPKIoOchggd7fth3Q0sgQ==
X-Received: by 10.55.125.194 with SMTP id y185mr67229649qkc.38.1483577524324; Wed, 04 Jan 2017 16:52:04 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 53sm47101653qtm.5.2017.01.04.16.52.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 16:52:03 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <be05d9e5-6099-ed76-455a-0619fa28ef32@gmx.com>
Date: Wed, 4 Jan 2017 19:52:00 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <A863C898-CEC6-481E-9140-AE010B9B918F@sn3rd.com>
References: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> <A876AE38-EFC6-48DC-955F-510CEEA4DB43@sn3rd.com> <be05d9e5-6099-ed76-455a-0619fa28ef32@gmx.com>
To: Yaron Sheffer <yaronf@gmx.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/8vKj_puaWW9tmsuTFie17XBHKqs>
Cc: sidr@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-sidr-bgpsec-pki-profiles-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 05 Jan 2017 00:52:07 -0000

> On Jan 3, 2017, at 16:47, Yaron Sheffer <yaronf@gmx.com> wrote:
> 
> 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 <yaronf@gmx.com>
>>>  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.

This bit is now OBE based on Stephen’s discuss.

>>> * 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.

So there’s really no good way to put this but it’s primarily because the common PKCS#10/PKCS#7 dance doesn’t support errors; it’s either success or silence.  It’s better to assume they’ve dorked their request and to give ‘em a proper certificate.  Remember these CAs are pretty clued into what’s going on here this isn’t the webPKI.

>>> * 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)
>> 
> Yes.
>> 
>> spt
>> 
>