Sandy, Thanks a lot for the comments.
Let me first introduce the (informal) terminology that a signature on a ROA is "GOOD" if it can be verified using an EE certificate that is valid (according to the draft-ietf-sidr-res-certs), and the signature is "BAD" otherwise. Then when validating a ROA there seem to be the following cases: A) All signatures on a ROA are "BAD" B) All signatures on the ROA are "GOOD", but the ROA contains an IP address prefix that is not covered by a "GOOD" signature C) The ROA contains both "GOOD" and "BAD" signatures, but the ROA contains an IP address prefix that is not covered by a "GOOD" signature D) The ROA contains both "GOOD" and "BAD" signatrues, and all IP address prefixes in the ROA are covered by a "GOOD" signature E) All signatures on the ROA are "GOOD", and all IP address prefixes in the ROA are covered by a "GOOD" signature In cases A, B and C, the ROA is declared invalid. (Invalid ROAs should be handled in the same way regardless of which case they fall under) In case E, the ROA is declared valid. As you indicate in your comments, the proposal was unclear as to the handling of ROAs in case D. Personally, I believe that the proposal is reasonable whether Case-D ROAs are deemed valid or invalid. If Case-D ROAs are deemed valid, then there is a possibility for a backwards-compatible mechanism for hash-function migration (if needed in the future). However, it is possible that Case-D ROAs should be deemed invalid to improve safety or to reduce complexity. Please let me know if there are other cases that I have missed which need to be clarified. <additional comments inline below> >> The proposed solution is to alter the ROA format to allow for a ROA that >> includes signatures from multiple signers. In essence, this provides a >> way for a subject of the certificate containing 10.0/16 to state "I, as >> the owner of 10.0/16, authorize AS 123 to advertise the aggregate prefix >> 10.0/15". > > > I think I'd quibble about the wording here. The owner of just 10.0/16 > can not in this format authorize the origination of the aggregate. > (And be careful of the word "owner" :-)) It is the "owner" of both > parts of the aggregate who is authorizing the origination of the > aggregate. So maybe "I, as the holder (:-)) of 10.0/16 and 10.1/16, > authorize AS 123 ...." would work better. > I completely agree that "owner" was a poor choice of words. Also, upon re-reading I realize that the quoted informal text doesn't really say what I want it to say. The important thing is that everyone understands the proposal at a high level. In essence, we are giving the holder of 10.0/16 a mechanism to give concent for AS 123 to originate the aggregate prefix. If both the holder of 10.0/16 and the holder of 10.1/16 give concent (by each signing the ROA) then the ROA is valid and authorizes AS 123 to orginate the aggregate prefix. >> By now mandating support for multiple SignerInfo >> objects, we ensure that such a future hash function migration can be >> performed in a backwards compatible fashion. > > > Good point. I hadn't realized that about the SignerInfo. (But see > below.) > >> In the degenerate case where >> there are multiple signatures that correspond to the same address range, >> then the authorization is only considered valid if all signatures are >> valid. > > > I would think that this would be the case for any ROA, not just the > degenerate case. (I think you are just trying to point out that using > multiple signatures with overlapping ranges does not make it more likely > that the ROA validation will succeed.) > > But if so, what happens if in the case of multiple hash algorithm > signatures - would not one of them be likely to fail, invalidating the > ROA? (unless the recipient supported both hash algorithms) > Clearly I suggested that this mechanism might be used for hash function migration without fully thinking through the ramifications. On the question of how to handle the case where a particular IP address prefix is covered by two signatures (one valid and one invalid), I think the working group could reasonably go either way. Allowing validation to succeed when a particular prefix is covered by two signatures (one valid and one invalid) provides a possible backwards-compatible mechanism for future hash function migration. However, perhaps it is safer (or less complex to implement?) to mandate that validation fail in the case where any signature on the ROA cannot be verified. Alternatively, we could differentiate between the following two cases of signature verification failure: (1) Verification fails because of an unsupported algorithm; vs (2) The algorithm is supported but the signature value is incorrect. >> The instructions for ROA validation in Section 3 of draft-ietf-sidr-roa- >> format would then be changed to the following: > > > I think that the comments at the last meeting specifically asked for > discussion of the error cases, which aren't addressed in what follows. Please let me know if there are any cases (other than those discussed above) that need clarification. >> 2.B Use the public key in the EE certificate to verify the >> signature on the ROA. > > > If a signature does not validate, then the loop is terminated at that > point, because that constitutes failure of the ROA verification, right? > > Even if the all remaining signatures validate and cover the aggregate? This is the issue of a particular IP address prefix being covered by both a valid and an invalid signature. Personally, as indicated above, I think that either answer results in a reasonable path forward. >> 2.C Verify that the EE certificate is a valid end-entity >> certificate in the resource PKI by constructing a valid >> certificate path to a trust anchor. (See >> draft-ietf-sidr-res-certs for more details.) > > > Do all the signatures have to be validated with EE certificates that can > be traced to the *same* trust anchor? > > (I would think not, but that question came to mind. Someone pointed out > on the list (George Michaelson, I think) that due to the ERX transfer of > addresses between RIRs, there are some sequences of aggregatable > addresses that are not in the same RIR. A ROA with such an aggregate > address might potentially have certificate paths that ended in separate > trust anchors. Depending on how the root of the RPKI ends up being > handled.) No, my intent certainly was *not* to require each EE certificate is validated using the same trust anchor. My intent was to say that each EE certificate should be (independently) validated as per draft-ietf-sidr-res-certs. >> 3. Compute the union of addresses in the list of prefixes >> corresponding to verified signatures by aggregating adjacent >> prefixes to the greatest possible extent. If this union exactly >> matches the IP address prefix(es) in the ROA, then the ROA is >> valid. > > > Exactly matches? A covering match will not suffice? We've had this discussion before with regards to a single signature on a ROA. If an entity has a CA certificate for the prefix 10.128/16 and wants to issue a ROA for 10.128.0/20, then the CA would issue an EE certificate for 10.128.0/20 and use this EE certificate to sign the ROA. Therefore, the current text of sidr-roa-format indicates that (in the case of a single signature) the IP address prefix in the ROA should indicate exactly the same set of IP addresses as the RFC 3779 extension in the corresponding EE certificate. Similarly, with regards to multiple signatures, two CAs holding a covering range of IP addresses can each issue EE certificates so that the IP addresses in the union of addresses ranges of the EE certificates exactly match the IP addresses in the ROA. Certainly, we could allow the addresses in an EE certificate to be a super-set of the addresses in the corresponding ROA, but I think its important that we use the same approach regardless of the number of signatures on the ROA. > > _______________________________________________ Sidr mailing list [email protected] http://www.ietf.org/mailman/listinfo/sidr
