W3C home > Mailing lists > Public > public-xmlsec@w3.org > March 2011

Re: DSig2.0 examples V2.0

From: <Frederick.Hirsch@nokia.com>
Date: Mon, 28 Mar 2011 20:51:34 +0000
To: <Meiko.Jensen@ruhr-uni-bochum.de>
CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
Message-ID: <FC7B7DE7-5B8B-4D10-A0A2-4AABA52A10F6@nokia.com>
Meiko

In my opinion it would  be better to use the standard WS-Security syntax to be clear how 2.0 Signature fits in, also to avoid the possible misinterpretation that the SOAP aspect of the example is incorrect.

We can put a warning note in the document that this is a 2.0 Signature illustration that thus has not been standardized as part of WSS (but should plug in seamlessly if the Signature 2.0 processing is supported in the XML Security layer).

To be clear you are saying the ex declaration needs to be on the soap:Envelope, we might want to add text noting this along with the example.

Thanks for the clarifications.

regards, Frederick

Frederick Hirsch
Nokia



On Mar 25, 2011, at 3:39 AM, ext Meiko Jensen wrote:

> Frederick, all,
> 
> see below
> 
> Am 24.03.2011 23:06, schrieb Frederick.Hirsch@nokia.com:
>> Meiko, 
>> 
>> Thanks for creating an example.
>> 
>> I reviewed it and made the following changes, attached:
>> 
>> 1. WS-Security uses wsse:Security as the security element within the SOAP header, so changed to that from nrns:SecurityHeader
> I intentionally used a different syntax here, since we don't know yet
> whether WS-Security will adapt XML Signature 2.0 or not. Stating an
> example that already shows what WS-Security has to be like when using
> XML Signature 2.0 may lead to confusions, especially if they decide to
> use a different approach (say, a different way to use XPath for
> selection), and our recommendation document then contains an invalid
> example. I'd imagine this to be rather misleading.
> 
> However, if the working group decides not to consider this a problem,
> I'm fine with having a WS-Security example.
>> 2. Switched to using Security Token Reference from KeyValue to  binary security token (with DSA X509 cert).
> Bruce already pointed me to the RSA algorthm but DSA KeyValues. Thanks
> for correcting this.
>> 3. Added explicit ds: prefix to all xml security elements as is common in SOAP examples
> ok
>> 4. Added c14n2: prefix for C14N2 elements in two places.
> ok
>> 5. changed dsig2:Verification DigestDataLength to "32" to reflect SHA-256 output length. Not sure where 175 came from, but am probably missing something obvious right now.
> As far as I remember, the DigestDataLength was to state the length of
> the digested data, not the length of the digest value. 175 reflected the
> length of the canonicalized version of the selected parts of the
> document (<ns0:operation>...</ns0:operation>). I'll do a recalculation
> on your examples in the next days.
>> 6. Changed soap body operation to be in the ex: namespace using example.com
> ok
>> Probably introduced an error but did not declare ex: namespace before soap:Body even though used in XPath. Will this be an error?
> Yep, the prefix "ex" is not bound at the text node of the XPath; this
> should result in a processing error. Just add its binding to the
> Envelope ;)
> 
> Thanks for the review.
> 
> best regards
> 
> Meiko
>> comment?
>> 
>> regards, Frederick
>> 
>> Frederick Hirsch
>> Nokia
>> 
>> 
>> 
>> On Mar 16, 2011, at 9:11 AM, ext Meiko Jensen wrote:
>> 
>>> Dear all,
>>> 
>>> I found some time to reiterate my initial example for the DSig2.0
>>> syntax. Again, I'm not claiming it to be complete nor correct, but
>>> according to my understanding of what we specified so far, this is what
>>> it should look like. Please note that for the sake of an example I
>>> listed some c14n parameters even though they keep their default values
>>> (and hence may also be omitted). I recommend developing a second example
>>> for ID-based referencing, which should look somewhat similar, but for
>>> now we at least should have something to start from.
>>> 
>>> cheers
>>> 
>>> Meiko
>>> 
>>> -- 
>>> Dipl.-Inf. Meiko Jensen
>>> Chair for Network and Data Security 
>>> Horst Görtz Institute for IT-Security 
>>> Ruhr University Bochum, Germany
>>> _____________________________
>>> Universitätsstr. 150, Geb. ID 2/411
>>> D-44801 Bochum, Germany
>>> Phone: +49 (0) 234 / 32-26796
>>> Telefax: +49 (0) 234 / 32-14347
>>> http:// www.nds.rub.de
>>> 
>>> <sig2example.txt>
> 
Received on Monday, 28 March 2011 20:52:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 March 2011 20:52:50 GMT