Comments on July 8 2.0 signature draft

I started to write some material about why we needed to basically move all
this new text into the old document and approach it that way instead of as a
new document, but I'm starting to think that the result of that will be to
confuse people and make it seem like you have to understand both to start
with the new model. So I'm coming around to the idea of using a new 2.0 spec
that formally references the original spec as "a valid but optional
processing model" and layers a new processing model on top of it as the
preferred mechanism, with the trigger being the new Transform to explicitly
signal that.

So, that being the case, I think we would want to say that kind of thing up
front.

But I would avoid quite so much language inline talking about the changes
from 1.x, and either highlight them as some kind of HTML insert/panel/note,
or move the text to a changes section (maybe with hyperlinks in various
spots to the specific discussion in that section).

Section 1:

The third paragraph is where we're stating the relationship between the old
and new work, and to get that right we have to decide on that relationship.
Are we actually *deprecating* the old transforms and c14n algorithms? That
implies intent to remove. Or are we discouraging their use, while not
signaling that intent? Or is it more about conformance, and we intend to
make only the new one MTI? We should decide all that soon, I think.

Section 3.1.2:

The Note seems insufficiently detailed. I assume we just want to use the
text from 1.1.

Section 3.2:

Would soften step 1 in that KeyInfo may be omitted, so there are other ways
to establish the signing key.

Are steps 2 and 3 actually in the right order? Seems like at least in some
cases, it will be cheaper to evaluate the Reference/Selection than do the
signature operation. I know in the old model, specs that have tight
Transform profiles always assume that the implementer will check out the
Reference/Transform set first.

Section 3.2.1:

Step 2 says C14N 2.0 is a must but not a normative MUST. Are we requiring
that? If so, we need to make it normative as a function of this processing
model and add text up front to clarify that the MUSTs apply if and only if
the new model is being used, or something like that. But I don't think we
want soft language inside the doc just to deal with the fact that older
signatures will still permit other c14n methods.

Step 3 again assumes KeyInfo is present/used.

Section 4.4.1:

Same issue as above wrt requiring new c14n 2.0. Suggest text about which
"named parameter sets" are MTI be in the c14n spec, not here.

You have a reference to requiring c14n 1.0, obviously this should be 2.0.

Suggest redoing the paragraph about the security issues, but that's
wordsmithing, not essential right now.

The last sentence of the last paragraph needs to come out, I think, or maybe
replace it with the point that by requiring this algorithm, the SignedInfo
element is represented only as an XML subtree and not as text.

Section 4.4.3:

This is confusing because the Selection/etc. elements aren't actually here,
but are inside a Transform. I wouldn't discuss them here, but would instead
just say that in accordance with the new processing model:

- URI MUST be present and refers to the source material over which the
single 2.0 Transform will operate
- Type MUST NOT appear
- The Transforms element MUST be present and contain exactly one child
element with the new Algorithm

This assumes the way you do detached/non-XML sigs is to point at the content
but then specify something in the Transform about it not being XML. If
that's not the intent, adjust above as needed.

Obviously some/much of the text about the URI attribute gets moved up here.

Section 4.4.3.1:

Again, I'd defer discussion of thew new Transform to its own section and
merely have text here constraining what MUST appear.

I would move all the subtext about the new Transform down into a Transform
section, and just have this section continue as before documenting the top
level elements.

Section 4.4.3.2:

As has been discussed, I believe URI needs to be removed here and left to
the Reference level. I think it's less confusing that way, rather than more.

Is the enveloped flag needed? Is it possible to assume that if you run
across yourself in the tree while applying c14n that you have to exclude
that? That seems to be self-evident, right? Is there a way to actually
generate a valid signature that includes yourself?

Section 4.4.3.4:

We also noted last call that it's critical to have much rigor about exactly
what XPath subset is allowed here, or if it's not even true XPath then
defining something in its place (ideally something drastically simpler that
happens to be a subset syntactially maybe).

Since the rules for include/exclude are different, the text needs factoring
on that line.

Section 4.4.3.5:

Seems like this section should be turned into "Transform Processing Model"
and have a step by step explanation of how to do that, rather than a focus
on changes.

-- Scott

Received on Wednesday, 26 August 2009 17:49:15 UTC