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

Re: DSig2.0 examples V2.0

From: Meiko Jensen <Meiko.Jensen@ruhr-uni-bochum.de>
Date: 29 Mar 2011 10:14:39 +0200
Message-ID: <4D9194EF.6000906@ruhr-uni-bochum.de>
To: Frederick.Hirsch@nokia.com
Cc: public-xmlsec@w3.org
Frederick, see below.

Am 28.03.2011 22:51, schrieb Frederick.Hirsch@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.
As I said, I'm fine with this, it is definitely more intuitive.
> 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).
Agreed, a note would be reasonable. I just saw the OASIS WS-Security TC
is closed, does anyone know whether and how they will adopt XML
Signature 2.0? I mean, if they never will, it wouldn't make sense to use
SOAP+WS-Security as an example, right?
> 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.
It is not necessarily to be declared in the soap Envelope, but it must
be bound at both the ex:operation element and the dsig2:ExcludedXPath,
with both declaring it for the same uri. The most convenient way for
this is having it once in the Envelope. However, technically, it would
be correct to declare it twice, once in the operation element (or in the
SOAP Body), and once in the ExcludedXPath element (or at any of its
ancestors)---as long as both declarations point to the same uri.

best regards

Meiko
> 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>
>

-- 
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
Received on Tuesday, 29 March 2011 08:15:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 March 2011 08:15:12 GMT