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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 01 Jan 2017 08:26:34 -0800

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.

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

* 3.3: ID.sidr-rfc6485bis -> RFC 7935

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

---

From: Rob Austein <[email-masked]>
Date: Sun, 01 Jan 2017 14:16:11 -0500

> because duplicate IDs are rare and never within a RIR), please say

Er, I suspect you're confusing serial numbers with serial numbers.

3.1.1 of this draft is talking about the id-at-serialNumber attribute
in the Subject field (RFC 5280 4.1.2.6, naming attribute type
X520SerialNumber), a different thing entirely from the certificate
Serial Number (RFC 5280 4.1.2.2, type CertificateSerialNumber).  Just
to make things more interesting, both are called serialNumber in
different contexts.  Clear as mud, I know.

So, agreed that this probably does need clarification, but perhaps not
quite the clarification you thought it needed.

---

From: Randy Bush <[email-masked]>
Date: Mon, 02 Jan 2017 20:10:15 +0900

> potentially repeating BGP IDs

not weighing in on the rest.  but i am not sure what you mean by bgp
id.  if it is routerID, those are unique within an AS.

randy

---

From: Sean Turner <[email-masked]>
Date: Tue, 3 Jan 2017 11:12:48 -0500

Yaron,

Thanks for the review.

> On Jan 1, 2017, at 11:26, Yaron Sheffer <[email-masked]> wrote:
> 
> Reviewer: Yaron Sheffer
> Review result: Has Nits
> 

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.

> Basic Constraints is included in the Cert Request but with other

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.

> 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

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 3 Jan 2017 23:47:01 +0200

Hi Sean,

Please see below.

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

> 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 reject…
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.
> r/two key identifier extensions./two key identifier extensions (i.e., Subject Key Identifier and Issuer Key Identifier)
Yes.

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Jan 2017 19:52:00 -0500

> On Jan 3, 2017, at 16:47, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Sean,
> 
> Please see below.
> 
> 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.

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