[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: WG: [dss-x] SignaturePtr problems ...
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]