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

[<detlef.huehnlein@ecsec.de>]

Hi,

"WhichData" would be fine with me. Should it be an xs:anyURI (which makes it more powerful)
or should we stick for some reason with xs:IDREF?

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