Juliusz Chroboczek <j...@irif.fr> writes: > Dear all, > > Antonin and I have spent the afternoon looking at his work on MAC rekeying > in babeld. His code is available in branch hmac-rekeying of > > https://github.com/MisterDA/babeld > > Now... we've got an issue with the information model. > > Following the information model, Antonin adds the following attribute to > keys: > > key-use sign|verify|both > > I'm a little puzzled by the purpose of this attribute. What usage > scenarios is it useful in? In particular, it does not appear to subsume > the sign-only interface attribute, which is useful in incremental > deployment scenarios.
Hmm, I think this notion originally comes from Bird's password configuration support? https://bird.network.cz/?get_doc&v=20&f=bird-3.html - search for 'password'. I guess you could use it for a kind of asymmetrical verification procedure? I.e., a route server could have its own key that it signs with, that all peers with the route server will accept, but each peer has its own key it signs with, that the route server is set up to accept. That way the peers wouldn't peer with each other, but all go through the route server? This would not prevent malicious actors, of course (they could just start signing with the route server's key), but it could prevent accidental misconfiguration. Dunno exactly what the original intention with the Bird option is, though. I can ask on the Bird list? -Toke _______________________________________________ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
