Hi Dave,
Let me respond to your questions. I'll extract them:
Question: "Why is the Id attribute unworkable? For example, if I use a
string GUID for the Id, would that work then? Each element in our system
actually has such a unique id already (for primary key), though it's
meaningless to people. But the same "file", even if included in lots of
different XML docs would all have the same string GUID. Our GUID looks
something like a URI but with no protocol prefix."
<Blake>
Id attributes are the preferred way to go. I made an assumption that it may
be too cumbersome on your end to make sure that the exact same Id's are used
for each distinct file as well as each distinct Signer block. If this
assumption can be met, you can use Id's with no problem.
The problem I was anticipating is the specific case where person A generates
the XML content model for "file1.bin" and generates along with it a random
Id. Then, lets say 4 weeks form now, person B generates the XML content
model for the *same* file1.bin. They also need an Id. You need to make sure
the Id is exactly the same.
The key point is this: The mechanism by which the file content blocks are
references is via the Id, not by the element name, so the Id has to be in
exact one-to-one correspondence with the specific file. This seems difficult
to enforce, but I don't know your architecture in full.
</Blake>
Question: Would it be any faster if it gave a more complete path, like
ancestor-or-self:/wrapped/doc/file? Or is the idea that we don't want it to
be too specific so that somebody could take a signed document like we have
here, and embed it in yet another XML doc, but located elsewhere in the tree
(i.e. /someotherdoc/anothertran/wrapped/doc/file)?
<Blake>
No. The way XPath is implemented in XML Signature is *not* the same way it
is used to commonly address elements in other cases.
Let me repeat that. XML Signature uses XPath as a node-test filter, not as a
path-based selection mechanism. This is perhaps the single most confusing
point of using XPath transformations and perhaps the single reason why
people get tripped up so often on this part.
For example, if I wanted to refer to the file element using normal XPath
using your content model I would make the expression:
/wrapped/doc/file
This expression, however, when used inside the XML Signature <XPath>
transform will not behave as expected, because the XML Signature standard
was written to evaluate each expression to a Boolean. This expression always
returns "true", and therefore, the entire document will be signed. No what
we want. This is why the "ancestor-or-self:foo" function must be used and
test each node in the node-set. This will sign foo and all of its children.
In essence it asks the question: "I am I myself a foo element or do I have
foo as an ancestor." This is confusing, error prone, and in practice very
cumbersome. This is why Id's should be used.
</Blake>
Question: Is the second Xpath supposed to be ancestor-or-self:SignerTran, or
was the 'Signer1' reference to an Id attribute?
<Blake>
This was a syntax error on my part. The correct expression is:
<Xpath> ancestor-or-self::SignerTran </XPath>
</Blake>
Question: How would a second signature applied look? Can I have I multiple
ds:Signature elements in this document? I presume the difference is that
the Xpath for the SignerTran would be have to vary depending on which user's
meta data was being included.
<Blake>
You can have as many signatures as you want. Each successive signature is
appended to the document and refers to the file and its respective
SignerTranX block via an Xpath expression, or if it is workable, an Id
attribute.
Example: This shows only the top level elements.
<wrapped>
<!-- top portion, file -->
<doc>
<file Id="fileId"> ... </file>
</doc>
<!-- bottom portion, metadata and signatures -->
<!-- signer #1 -->
<SignerTran ... </SignerTran>
<ds:Signature> ...
</ds:Signature>
<!-- signer #2 -->
<SignerTran ... </SignerTran>
<ds:Signature> ...
</ds:Signature>
<!-- signer #3 -->
<SignerTran ... </SignerTran>
<ds:Signature> ...
</ds:Signature>
</wrapped>
</Blake>
Question: Where is the 'same-document detached signature' type specified in
the Apache APIs? I don't see anything similiar in the ThreeSignerContract
examples. Or is it just figured out because the ds:Signature element doesn't
wrap the data when I copy the created ds:Signature element into that area of
the DOM before I write it back out
<Blake>
I don't know that there is one. You can always add new sample code! I
haven't looked at the Apache API's in extreme depth, but from what I
remember, you can definitely make same-document detached signatures.
</Blake>
Question: Well, we don't need a prototype. Is there another API that would
be much better at this, or is it just that XML DSigs are not real fast yet
because they are fairly new?
<Blake>
XML Signatures are slow because XML processing is slow. There are just no
two ways about it. 90 percent of the processing in an XML signature is XML
parsing, canonicalization, and transformation. The private key and hashing
operations are usually orders of magnitude faster, depending on the size of
the documents.
</Blake>
Good Luck,
Blake Dournaee
Senior Security Architect
Sarvega, Inc.
