Re: Detached signature of non-sibling elements (?)

Hi Frederick.


According to your comment, this IS a valid detached signature, isnt it?

<root>
    <my-data>
        <node Id="n"></node>
    <my-data>
    <my-sign>
        <Signature …>
            …
            <Reference URI=“#n”>
            ...
        </Signature>
    </my-sign>
</root>

Just to be sure (not miss-translating): sibling are only sister/brother,
right?

As stated in [4], " Detached signatures are over external network resources
or local data objects that reside within the same XML document *as sibling
elements*; in this case, the signature is neither enveloping (signature is
parent) nor enveloped (signature is child). "

Also in [2], "The signature is over content external to the Signature
element, and can be identified via a URI or transform. Consequently, the
signature is "detached" from the content it signs. This definition
typically applies to separate data objects, but it also includes the
instance where the Signature and data object reside within the same XML
document *but are sibling elements*."


I think both paragraphs induce an error/missunderstanding.
Hence, I request a correction/errata:
 -If the sibling part was added on purpose, many signatures "out there" are
invalid, but on detached signatures content-data MUST BE siblings. Spec
should be much more clear on this.
 -If the sibling part was accidental, remove the bold/underlined parts and
add an errata reference.

Should I proceed in someway to request this errata be considered officially?

Thanks a lot for your time and help
Regards.
PS: Someone should request Microsoft do the same with [3]...and even not to
distinguish between internal/external ;)

[4] http://www.w3.org/TR/xmldsig-core/#sec-Overview




On Tue, Aug 26, 2014 at 5:26 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:

> Sorry, must have missed your earlier email.
>
> basically you can sign content within the Signature Object element
> (enveloping signature), sign the content that contains the Signature
> (enveloped signature) or other content
> (either in the same document but not the previous two cases, or external)
> as detached signature.
>
> regarding your example, need to ref via #n, and with appropriate syntax
>
> <Signature …>
> …
> <Reference URI=“#n”>
> ...
> </Signature>
>
> Does this help?
>
> regards, Frederick
>
> Frederick Hirsch, Nokia
> @fjhirsch
>
>
>
> On Aug 26, 2014, at 2:27 AM, helpcrypto helpcrypto <helpcrypto@gmail.com>
> wrote:
>
> Ping?
>
>
> On Tue, Jul 29, 2014 at 9:30 AM, helpcrypto helpcrypto <
> helpcrypto@gmail.com> wrote:
>
>> Hi.
>>
>>
>> Altough XMLDSig [1] is quite old, stable and well-known, I havent been
>> able to understand (maybe a translation/missunderstanding issue) the
>> detached signatures properly.
>>
>> According to [2]:
>> "*The signature is over content external to the Signature element, and
>> can be identified via a URI or transform. Consequently, the signature is
>> "detached" from the content it signs.*"
>>
>> Ok. Detached elements...
>>
>>
>> "*This definition typically applies to separate data objects, but it
>> also includes the instance where the Signature and data object reside
>> within the same XML document but are sibling elements.*"
>>
>> Ok. Signature and object in the same XML doc and siblings.
>>
>>
>> As stated in [3] (I't seems the standard doesnt distinguish between
>> internal/external)
>> "the signature and data can be in separate files or in the same XML file
>> as sibling elements"
>>
>>
>> Shall I understand the "internally detached" *unique valid signature* is
>> where signature and data are brothers (or sisters) [have the same parent]?
>>
>>
>> *Is the following example a valid detached signature? *
>>
>> *<root>*
>>
>> *    <my-data>*
>>
>> *        <node Id="n"></node>*
>>
>> *    <my-data>*
>>
>> *    <my-sign> *
>>
>>
>> *        <signature ref="n"></signature>    </my-sign>*
>> *</root>*
>>
>> Thanks a lot for your help
>> Regards
>>
>>
>> [1] http://www.w3.org/TR/xmldsig-core/
>> [2] http://www.w3.org/TR/xmldsig-core/#def-SignatureDetached
>> [3] http://msdn.microsoft.com/en-us/library/ms759193%28v=vs.85%29.aspx
>>
>
>
>