[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: WG: [dss-x] SignaturePtr problems ...
Hi Detlef,
maybe I didn't get your point regarding the IDRefs:
The IDRef identifies a blob within the Request (or Response) containing
a signature (of any format). I don't see a relationship with the XMLDSig
references _within_ a given signature.
Other topic:
How did we end up regarding 'identiification by digest' within SignaturePtr?
Greetings,
Andreas
> Hi,
>
> the motivation to think about shifting to anyURI (instead of IDREF) is to be more
> flexible (as the IDREF-case would only correspond to the special case of
> a 'same-document' reference (see https://www.w3.org/TR/xmldsig-core1/#sec-ReferenceProcessingModel )).
>
> However the security ramifications you raised below might indeed not be
> easy to overlook completely and hence we would stay on the
> safe(r) side, if we keep xs:IDREF.
>
> OK?
>
> BR,
> dh
>
> -----UrsprÃngliche Nachricht-----
> Von: dss-x@lists.oasis-open.org <dss-x@lists.oasis-open.org> Im Auftrag von Andreas Kuehne
> Gesendet: Dienstag, 22. Januar 2019 15:33
> An: detlef.huehnlein@ecsec.de; dss-x@lists.oasis-open.org
> Betreff: Re: WG: [dss-x] SignaturePtr problems ...
>
> Hi Detlef,
>
>> "WhichData" would be fine with me.
> Great!
>> Should it be an xs:anyURI (which makes it more powerful) or should we
>> stick for some reason with xs:IDREF?
> The current approach is to reference a Base64Data component. That's what the user expects to find at the other end of the relationship (and supported by e.g. JAXB framework).
>
> Pointing to anywhere in the internet is a completely different use case, due to my opinion. And presumably cannot expect to find a Base64Data component but the root of the signature document. Therefore I would like to propose to add an anyURI to the Base64Data component. But it is always a dangerous pattern to access an endpoint someone else provided.
> That's a good place to launch an amplification attack using the DSS-X server. So I'm not that eager to include a remote pointer ...
>
> Or do I misunderstand the intended use of anyURI?
>
>
> Greetings,
>
>
> Andreas
>
>> BR,
>> dh
>>
>> -----UrsprÃngliche Nachricht-----
>> Von: dss-x@lists.oasis-open.org <dss-x@lists.oasis-open.org> Im
>> Auftrag von Andreas Kuehne
>> Gesendet: Dienstag, 22. Januar 2019 11:42
>> An: dss-x@lists.oasis-open.org
>> Betreff: Re: WG: [dss-x] SignaturePtr problems ...
>>
>> Hi Detlef,
>>
>>> isn't the technical prerequisite that the object (document or
>>> signature)
>>>
>>> to which the WhichDocument attribute points to has an xs:ID?
>>>
>>>
>>>
>>> As far as I see it, both structures (InputDocuments/Document and
>>> SignatureObject/Base64Signature)
>>>
>>> are in the end derived from dsb:Base64DataType, which may have this
>>> xs:ID such that
>>>
>>> some WhichDocument-attribute (either being xs:IDREF or xs:anyURI) can point to it.
>>>
>>>
>> currently WhichDocument refers to a DocumentBaseType, what in this
>> case could be a Document or TransformedDocument (or DocumentHash, not
>> relevant here). As the attributes name suggests a 'Base64Data'
>> structure would not be expected here. So I would propose to change the
>> name to 'WhichData'.
>>
>> Despite the nuisance of name change the relationship to Base64Data
>> makes more sense (one mismatch is addressed by ticket DSSX-50). E.g.
>> the WhichDocument attribute is used in SignaturePlacement, but a
>> placement within a DocumentHash doesn't make any sense.
>>
>>
>> So let's go with changing 'WhichDocument' to 'WhichData' and the
>> alignement of SignatureObject (see below) and our spec is a little bit
>> better, again!
>>
>>
>> Greetings,
>>
>>
>> Andreas
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----UrsprÃngliche Nachricht-----
>>> Von: dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org>
>>> <dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org> > Im
>>> Auftrag von Andreas Kuehne
>>> Gesendet: Montag, 21. Januar 2019 22:40
>>> An: dss-x <dss-x@lists.oasis-open.org
>>> <mailto:dss-x@lists.oasis-open.org> >
>>> Betreff: [dss-x] SignaturePtr problems ...
>>>
>>>
>>>
>>> Dear colleagues,
>>>
>>>
>>>
>>> sorry come up late with a statement contradicting my view from the call.
>>>
>>> But looking at the code produced for WhichDocument attribute I
>>> realized
>>>
>>> our view of the intention of tghis attribute is wrong:
>>>
>>>
>>>
>>> public DocumentBaseType getWhichDocument() {
>>>
>>>
>>>
>>> The attribute does not point directly to an arbitrary (XML) document
>>>
>>> holding a signature but it refers to an instance of InputDocumentType.
>>>
>>> So my assumption is wrong, _it is_ an in-document reference!
>>>
>>>
>>>
>>> So the SignaturePtr is _not_ capable of identifying a signature
>>> within
>>>
>>> a SignatureObject/Base64Signature! This sounds reasonable if you
>>> think
>>>
>>> of just one signature directly contained within the Base64Signature.
>>> But
>>>
>>> e.g. XAdES this may not be true. This shortcoming also makes it
>>> unusable
>>>
>>> for the intended replacement of a Peter's SignatureIdentifier.
>>>
>>>
>>>
>>> An obvious solution would be to replace the Base64Signature (in
>>>
>>> SignatureObject) by a 'SignatureAsDocument' of the type DocumentType.
>>>
>>> This allows easy referencing, it would fix the relationship in cases
>>>
>>> where the signature should be included directly in SignatureObject.
>>> It
>>>
>>> also would allow to transport big (encapsulating) signatures as
>>>
>>> attachments.
>>>
>>>
>>>
>>> The original
>>>
>>>
>>>
>>> <xs:complexType name="SignatureObjectType">
>>>
>>> <xs:choice>
>>>
>>> <xs:element name="Base64Signature"
>>> type="dsb:Base64DataType"/>
>>>
>>> <xs:element name="SignaturePtr"
>>> type="dss2:SignaturePtrType"/>
>>>
>>> </xs:choice>
>>>
>>> <xs:attribute name="SchemaRefs" type="xs:IDREFS"
>>> use="optional"/>
>>>
>>> </xs:complexType>
>>>
>>>
>>>
>>> would morph to
>>>
>>>
>>>
>>> <xs:complexType name="SignatureObjectType">
>>>
>>> <xs:sequence>
>>>
>>> <xs:element name="SignatureDocument" type="DocumentType"
>>>
>>> minOccurs="0"/>
>>>
>>> <xs:element name="SignaturePtr" type="SignaturePtrType"
>>>
>>> minOccurs="0"/>
>>>
>>> </xs:sequence>
>>>
>>> <xs:attribute name="SchemaRefs" type="xs:IDREFS"
>>> use="optional"/>
>>>
>>> </xs:complexType>
>>>
>>>
>>>
>>> But, big drawback, would add another element even in the case of
>>> plain
>>>
>>> vanilla 'one signature, one detached document' calls. Easy structures
>>>
>>> for simple calls _and_ also supporting the complexity of XMLDSig isn't easy!
>>>
>>>
>>>
>>>
>>>
>>> What's your view?
>>>
>>>
>>>
> --
> Andreas KÃhne
> phone: +49 177 293 24 97
> mailto: kuehne@trustable.de
>
> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
>
> Director Andreas KÃhne
>
> Company UK Company No: 5218868 Registered in England and Wales
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
--
Andreas KÃhne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de
Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
Director Andreas KÃhne
Company UK Company No: 5218868 Registered in England and Wales
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]