use of exclusive canonicalization [action 05-09-19-03]

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Dear Tommy and all,

A section similar to the following text could be added to the core 
document in an appropriate location, potentially to the appendix.

**** section begin ****
Use of Exclusive Canonicalization:

Exclusive Canonicalization of dereferenced and transformed data can be 
achieved by appending exclusive canonicalization as the last transform 
in the <ds:Transforms> element of <TransformedData> or <DocumentHash>. 
In the case of <Document> being used this can be done by adding 
exclusive canonicalization as the last transform in the <ds:Transforms> 
of a <SignedReference> pointing to that <Document>.

By doing this the resulting data produced by the chain of transforms 
will always be octet stream data which will be hashed without further 
processing on a <ds:Reference> level by the server as indicated by basic 
processing section 3.3.1 step 1 b. and c.

However after the server formed a <ds:SignedInfo> (section 3.3.1 step 
3.) this information to be signed also needs to be canonicalized and 
digested, here [XMLSig] offers the necessary element 
<ds:CanonicalizationMethod> directly and not via a transform.
**** section end ****

A note for further Discussion on the need for exclusive canonicalization 
and SignatureObject:

If a signature's <ds:SignedInfo>/<ds:CanonicalizationMethod> is not 
exclusive canonicalization we have to be careful if such a signature is 
sent in a verify request 
<VerifyRequest>/<SignatureObject>/<ds:Signature> and not properly 
context free extracted as it will inherit outer namespaces (oasis-dss, 
soap, etc ...).

Hence we could either a) mandate to issue an Error if a Signature not 
using exclusive canonicalization for 
<ds:SignedInfo>/<ds:CanonicalizationMethod> is send inside 
<VerifyRequest>/<SignatureObject>/<ds:Signature> or b) take similar 
precautions as we did with <InlineXML> or c) remove <ds:Signature> from 
<SignatureObject> as <SignaturePtr> in combination with <Document> is 
sufficient.

For the first alternative a) speaks that we already have 
<VerifyRequest>/<SignatureObject>/<SignaturePtr> allowing to point to a 
Document if exclusive canonicalization is not used. This resolution 
hence includes <InlineXML>'s capabilities for context free extraction 
(and also opaque encodings) for cases where 
<ds:SignedInfo>/<ds:CanonicalizationMethod> is not exclusive 
canonicalization. However against it speaks that an error message will 
have to be returned in such a case instead of dealing with it.

For the second alternative b) speaks that the structure of the 
<ds:Signature> will be validated against the [XMLSig] schema in the 
first parsing pass. This however is not of much value as [XMLSig] 
implementations would report structural invalid Signatures any way as 
either not understandable or invalid.
Further would this solution be a redundant solution of the problems 
already solved by <Document> and <InlineXML>, <Base64XML> etc... .

The third solution c) to remove <ds:Signature> from <SignatureObject> 
seems to be the best reuse of functionality provided by <Document>. 
Further will optional schema inputs allow to mitigate the minor 
disadvantage of not validating the <ds:Signature> in the first xml parsing.
The most important argument that speaks for c) is that <SignaturePtr> in 
combination with <Document>/<InlineXML> and a schema is sufficient and 
perfectly models the removed <ds:Signature> element.
Solution c) would further allow to remove <Base64Signature> as 
<SignaturePtr> in combination with <Document>/<Base64Data> perfectly 
models the removed <Base64Signature>.

Similar thoughts will also have to be made for <Timestamp>/<ds:Signature>.


best regards
Konrad