Hi Eliot, I agree it would be useful to be able to sign configuration data in an encoding-independent way, but it is not an aim of this document to deal with this problem. Encoding-specific approaches are of course available, this probably needn't be mentioned.
Lada > On 24 Mar 2016, at 14:18, Eliot Lear <[email protected]> wrote: > > > Hi Lada, > > On 3/24/16 1:12 PM, Ladislav Lhotka wrote: >> I am fine with adding this sentence although, as a matter of fact, the >> document does not define an infinite number of other mechanisms. There >> is no general requirement to support signing and encrypting for >> YANG-modelled data, also because, as Andy pointed out, our protocols >> so far demand a secure transport. > > Just for context, encrypted transport addresses only in flight attack. > That's not always the only form that needs to be protected against. At > least in the use case I'm dealing with, where an intermediary system – > one that is storing files – is attacked, and due to the scope of the > risk, we want an additional layer. This also allows files to be passed > around without having to worry about the path. That's not in my > specific use case today, but it is something that has been done. > > Eliot > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
