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

Sean Turner <> Tue, 03 January 2017 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D9C012966B for <>; Tue, 3 Jan 2017 08:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9c788TMGuL4C for <>; Tue, 3 Jan 2017 08:12:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8210A12965B for <>; Tue, 3 Jan 2017 08:12:52 -0800 (PST)
Received: by with SMTP id c47so466509505qtc.2 for <>; Tue, 03 Jan 2017 08:12:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EVCzkpFkXVxAAqe3J+2UkWE9YYvJcIzgY6rDbUyF8oM=; b=csmw5CWMZvJlzd2V8Zxts+Ee/zymSQAGTvrFHSjrWlaIND2Gj3mR4z3umFSE3kJtZ5 gvhUpKp9hCEJRSiBleB88Otmsbp1sbNS1K+6fUjTqgUu0MuJfF2WCwb6KlVrNXghbl6e xpnYViAOAjwJRq/Y/3evjygZ8+QAxspg+tauA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EVCzkpFkXVxAAqe3J+2UkWE9YYvJcIzgY6rDbUyF8oM=; b=YKuE6WwJkijOlX2pTBEUxZwCKyMTcc3mmpxHfpiFxsXZJ4kmuRhTrPvKoBQSM1l3OB N9BflxzgblgaLCEWL5f+vPDVmFESSd/3RpT3YjbBahC3O/kPMDUGVMPpmdPnTC7QvuQ8 yQlrN4lcMfx7mJqlGvchfiFRRDm/6VGCwIe/puycDKE2XX/bv/7f06R+uiIelbV6mBw8 iH21eWe18ifCTMHtpXpRaRWH4taZKKScvqcJalCtHlJAI+6wvC9CsWDRVFU7pKMerou6 BaPiUK1XQbuKWsP5gF7jofUgDf3rVOHfv2Uog/uJ01SQFfYM0w2K3k0xB8TDBoBLJF+4 ZR1Q==
X-Gm-Message-State: AIkVDXIcQOhE2GYDpZNCZEY2cvSrPu1JyQzXZg+I5b2MnYzW9udh5XHRha7PcNj98WhXgQ==
X-Received: by with SMTP id n25mr65305661qtf.50.1483459971490; Tue, 03 Jan 2017 08:12:51 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id i41sm44019203qtc.18.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 08:12:50 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <>
In-Reply-To: <>
Date: Tue, 3 Jan 2017 11:12:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Yaron Sheffer <>
X-Mailer: Apple Mail (2.3124)
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 16:12:54 -0000


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

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

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