At Fri, 28 Sep 2012 09:54:01 -0400, Stephen Kent wrote: > > >> 4.1. Originating a New BGPSEC Update > > ... > >> In particular, this AS number MUST match the AS number in > >> the AS number resource extension field of the Resource PKI end-entity > >> certificate(s) that will be used to verify the digital signature(s) > >> constructed by this BGPSEC speaker. > > "The" or "an"? Is it legal for the EE certificate to cover more RFC > > 3779 resources than just a single ASN? > yes, an EE cert can contain multiple ASNs, if they were allocated to the > cert holder by the same parent.
I know that RFC 3779 allows multiple ASNs, having implemented it. :) What I'm asking is whether it was Matt's intent to restrict BGPSEC to requiring that only a single ASN be certified in the relevant EE certificate. I do not recall any such restriction during earlier discussions of this protocol, which is why I flagged it. > >> 6.1. Algorithm Suite Considerations > > ... > >> To this end, a mandatory algorithm suites document will be created > >> which specifies a mandatory-to-use 'current' algorithm suite for use > >> by all BGPSEC speakers [12]. Additionally, the document specifies an > >> additional 'new' algorithm suite that is recommended to implement. > > Badly phrased, unless the real intent here is to say that we're going > > to pick both the current and next algorithms right off the bat, which > > seems unlikely to me. I think it would be more correct to say that > > we will specify an initial mandatory algorithm suite, and, once we > > have some idea of what the next algorithm should be, we will publish > > a series of updated documents phasing in the new one and (eventually, > > years later) phasing out the old one. > that would be consistent with the alg migration strategy described in > draft-ietf-sidr-algorithm-agility-07 I assume (please correct if wrong) that your comment refers to my suggested rephrasing being consistent with the algorithm migration strategy. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
