Obligatory statement: The following opinions are stated strictly as a member of the wg, not as a wg chair pronouncement. My opinion on this matter should matter no more or less than that of any other wg member.
Right now, prefix holders who have been allocated multiple aggregatable prefixes can originate an advertisement for the aggregate. I imagine that we (sidr) would want the architecture to premit the authorization of such an aggregate advertisement - no one wants to give up current features. The choices seem to be: (1) create multiple singly signed ROAs, say for two /20's, and let the recipient interpret whether you meant to authorize the origination of the /19 as well. (IMHO, I don't care for the recipient reading the mind of the prefix holder - the wg must choose a common interpretation to make this work, and if the common choice is wrong for some prefix holder, there's no way for that prefix holder to recover.) (2) mandate that all sources (all CAs) MUST produce an aggregate cert when there are aggregatable certs. (IMHO, mandating a CA activity like this is out of character for PKIs, but there's always a first time...) (3) tell prefix holders whose source is not willing to sign an aggregate cert that they are just out of luck in originating the aggregate, maybe just until the next prefix renewal period, maybe forever. (IMHO, this would not be a popular option.) (4) allow a prefix holder whose source is not willing to sign an aggregate to sign an aggregate ROA with multiple signatures. (IMHO, this does add a bit of complication to the ROA validation algorithm, but for the computers not the humans - and that's what computers are good for.) It could be that the chosen interpretation in (1) is so very seldom wrong, that we can decide that this is a good engineering choice and go with that. But I dislike the idea of going to some large effort to strongly assert an authorization that won't be exactly followed by the recipients. --Sandy _______________________________________________ Sidr mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sidr
