I remain quite skeptical about the need for this, but will suspend disbelief on that point for the remainder of this message.
The proposal is too complicated for the stated purpose, mostly because it allows overlapping resource sets. That drags in all sorts of fun topics, such as partial overlaps, overlaps with multiple algorithms, downgrade attacks, deciding how many good signatures is enough, etcetera ad nauseum. Complicated decision trees means multiple code paths. Rarely used code paths will be buggy. Buggy code paths will be an attack vector. This is supposed to be security software. Keep it simple. If you must support multiple signatures, do it as simply as possible: - All signatures must be good, if any are bad, so is the ROA. Full stop. - Overlaps are not allowed, full stop. - If the ROA's exactMatch field is true, the prefixes listed in the ROA must be an exact match for the union of the set of prefixes covered by the certs; otherwise, the prefixes listed in the ROA must be a subset (possibly improper) of the union of the resources in the cert. _______________________________________________ Sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
