IESG Comment 130

[deanwillis]

From: Stephen Farrell

Description: Section 4.1: Signatures imply some c14n rule, esp if supporting array/dictionary. Is this covered?

Notes: 5.1 Forward ref to 11.1

[petithug]

Ok, I disagree with this one. everything is defined as binary when signed. If there is c14n rules, they must be indicated when defining an usage (probably missing), i.e. when definign teh resource record, but not at this level...

[deanwillis]

Frack if I know. The main thing as I understand it is that namespace declarations are implicitly part of the signed subdocument, so if you want to validate the signature on a subdocument you have to know what those are. The easiest way to do this is to embed them in the subdocument in a standard way. If all that cruft is invariant and exterior, I don't see why a binary treatment wouldn't work. But I don't have the XML religion. We could explicitly state binary signature processing. 6.1.1.1 bullet 1 still needs a forward reference to 7.1. The bit about binary treatment could go in 7.1

[deanwillis]

I'll undertake the references.

[petithug]

No this is signature for the data stored, not for the xml file, right?

[deanwillis]

But what if the data stored IS an XML document?

[petithug]

Then the usage has to explain how it is conveted to opaque<>, which is binary.

[deanwillis]

Or are we talking about the message signature in the security block?

[petithug]

The confusion is that the AD understood array/dictionary as a software language feature, which it is not. It is an array/dictionnary of binary strings.

[deanwillis]

okay, I'll buy that.

[petithug]

This said reminding the designer s of usage that they have to define the rules for convertion between charters strign and binary, is useful

[petithug]

So I'll add this to 4.2

[deanwillis]

Fixed