Hi, I have just submitted a -05 version of the document.
This version includes: = minor clarifications and improvements to the English (thanks Steve) = the text to replace all of RFC6487 section 7.2 suggested by Steve including Geoff's comment = amended to reject over-claiming EE certificates so we only need to update 6487 I would like to ask the WG (BGPSec folk in particular) to have a look at the following text that I included on 'fate-sharing' ROAs and BGPSec certificates: Note that ROAs [RFC6482] and BGPSec router (EE) certificates [I-D.ietf-sidr-bgpsec-pki-profiles] can contain multiple prefixes or ASNs respectively, and an over-claim of any of these would result in the ROA or BGPSec EE certificates being considered invalid. However, operators MAY issue separate ROAs or BGPSec router certificates to avoid this type of fate sharing. For ROAs I think this is a feasible option. We can easily modify our code to issue a separate ROA for each prefix. I don't think this causes scaling issues. But can the same be said about router certificates? I guess the use case there is that the same key is used for different ASNs, right? Can one just issue separate certificates for each ASN? And one other question to the working group. Is this something we need to talk about in Berlin again? I ask because we seem to be converging, and I don't want to claim speaking time if it's not needed. Thanks, Tim > On 29 Jun 2016, at 04:07, Geoff Huston <[email protected]> wrote: > > Thanks! I am now very comfortable with your text on this. > > Geoff > >> On 29 Jun 2016, at 3:39 AM, Stephen Kent <[email protected]> wrote: >> >> Geoff, >> >> Thanks for reviewing the text. >> >> I modified the text to change "current VRS-IP" to be "... the value of the >> VRS-IP computed for certificate x-1" as per your suggestion. I also made >> this change for the corresponding VRS-AS text. >> >> I don't think we need to add a note about validation being performed "top >> down" since bullet B already says: "certificate '1' is a trust anchor" >> >> Steve >>> FWIW, I like this formulation Steve. >>> >>> Possibly when you refer to "the current value of the VRS-IP” you may want >>> to explicitly refer to the VRS-IP of certificate x-1 rather than “current”. >>> >>> I also wonder if it is worth noting that the enumerated steps outlined here >>> are intended to be performed “top down” - i.e. from a trust anchor to the >>> certificate to be validated. >>> >>> regards, >>> >>> Geoff >>> > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
