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

Hi,

the point I tried to make with respect to xs:IDREF vs. xs:anyURI was that 
instead of using an IDREF-Component to point to an xs:ID "ID-Nr-5" 
one could use the 'same-document URI' "#ID-Nr-5" to identify this
element, if URIs are handled as specified in XML-DSig. 
 
See paragraph "In this specification, a 'same-document' reference is defined as a URI-Reference that 
consists of a hash sign ('#') followed by a fragment ...".

>How did we end up regarding 'identiification by digest' within SignaturePtr?

As far as I see it, the digest is not for identification of the location of a data object, but a 
"cryptographic specification" that one really means exactly the data object
with the given digest. The mere identification of the location would be possible without 
the digest.

BR,
 dh
-----UrsprÃngliche Nachricht-----
Von:  <> Im Auftrag von Andreas Kuehne
Gesendet: Dienstag, 22. Januar 2019 16:21
An: 
Betreff: 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:  <> 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
>
>
>
> ---------------------------------------------------------------------
> 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: 

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