>> 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.
I support this way forward. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
