Re: WG: [dss-x] SignaturePtr problems ...

[Andreas Kuehne <kuehne@trustable.de>]

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