BTW, I just looked at the -10 revision of https://tools.ietf.org/html/draft-ietf-babel-information-model-10
Since that revision has Boolean (true/false) parameters of babel-key-use-sign and babel-key-use-verify (but not key-use with values of sign/verify/both), I did want to be sure we were talking about the right model revision. Barbara > From: STARK, BARBARA H > > > From: Toke Høiland-Jørgensen <[email protected]> > > > > Juliusz Chroboczek <[email protected]> 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 > > > > > > <URL mauled by AT&T mail system> > > > > > > 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? > > <URL mauled by AT&T mail system> > > 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 > > I don't remember precisely and would need to go looking for the emails. I > think it did come from Toke's comments. But if an implementation doesn't > support asymmetric signing, it can just hard-code the parameter to "both", > not allow configuration of the parameter, and be done with it. > Barbara _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
