> On Jan 3, 2017, at 16:47, Yaron Sheffer <yar...@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 <yar...@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 >> > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
