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: <> Im Auftrag von Andreas Kuehne
Gesendet: Dienstag, 22. Januar 2019 15:33
An: ;
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: <> Im
> Auftrag von Andreas Kuehne
> Gesendet: Dienstag, 22. Januar 2019 11:42
> An:
> 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: <mailto:>
>> < <mailto:> > Im
>> Auftrag von Andreas Kuehne
>> Gesendet: Montag, 21. Januar 2019 22:40
>> An: dss-x <
>> <mailto:> >
>> 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:
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
