On Mon, Mar 21, 2016 at 04:30:03PM +0100, Eliot Lear wrote: > > > On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote: > > Lada, I think Stephen asks about JSON encoded YANG-defined data that > > is signed, that is, the JSON serialization itself is signed. What > > happens to the signature if you convert the JSON to corresponding XML > > serialization. I think the answer is that the signature is broken in > > this case and I think this is quite natural. > > > > Object signatures so far never came up in the NETCONF/YANG context > > (well not quite correct, I think there is some related discussion > > aroud the zero-config draft) but even if they do, I think we will have > > to accept that signatures are encoding specific. And I think this is > > not a big deal; if I sign my HTML encoded email, then the signature > > likely won't apply to a text-only rendering of the same email. > > > > However this goes, it should be well documented somewhere. This will > not be the first time this comes up (he says, knowingly). >
I am somewhat surprised. Do people really expect that signatures computed over a certain encoding of some data can be applied to a different encoding of the same data? If I sign a tar archive and then convert the content to a zip archive, do people really assume the signature is still valid? If this is a surprise, perhaps object signature RFCs should say something about this. Does it make sense to have a statement in every data encoding RFC saying that 'if you transform the encoding to a different encoding, a signature calculated over the original encoding will not be valid anymore'? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
