On Aug 11, 2015, at 12:12, Richard Hansen <[email protected]> wrote: > Unfortunately no, with the disclaimer that I haven't really thought > about it in depth. Because of the challenge of accomplishing topic #3, > I would like start with the much simpler topic #1. Note that I'm not > opposed to tackling #3, but the amount of work involved means that I'd > like to get topic #1, and possibly topic #2, out of the way first. >
Okay so I think we’re in agreement here that we don’t work on #3 now, but I’m also thinking that we should leave #1 and #2 alone for now. If we think a SHA-1 hash for the RPKI’s KIs are good enough now, then it sounds like it's also good enough for BGPsec. It seems really odd that we do something different in BGPsec than what is done in the rest of the RPKI. So, I’m proposing that: 1. We make no change to the SKI generation mechanism. 2. To make sure folks don’t continue to go down this rathole I think we should add the following to the security considerations, which is copied from RFC 7093: While hash algorithms provide preimage resistance, second-preimage resistance, and collision resistance, none of these properties are needed for key identifiers. 3. We tackle the KI algorithm change we/if we re-open the RPKI PKI profile. spt _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
