[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] Rewriting of imported schemes
Hi Frank,
I see your point. My first approach for this setup would be to protect
the whole message by wrapping it into a signed container. I guess you
control the whole flow so why do you try to protect the message 'from
within'? Wrapping seems more obvious to me.
Next point is the need for the xs:ID at SignRequest. My expectation is
the use of an 'Enveloped Signature' transform without the need for
additional ids (and without breaking the signature while inserting it).
If you are using ds:Signature on XML content you are loosing syntax
independency. It could be a valid decision for a profile to define
different mechanism for different syntaxes. But that's what I try to
avoid for the core. And I haven't really understood why we have to mix
the requests and its integrity protection.
A flaw of the current schemes: If we take the path of rewritten schemes
they _of course_ need distinct namespaces! I'll move the rewritten
XMLDSig to another namspace and come back to you.
Greetings,
Andreas
> Hi Andreas,
>
>
> Because we are using DSS Core over Browser POST in our DSS
> implementation, we really need message-level security by means of an
> XML signature.
>
> Hence our SignRequest looks as follows:
>
> <dss:SignRequest xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema"
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
> xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema"
> xmlns:my="urn:dss:myextension" xmlns:sec="urn:dss:security"
> xmlns:wsa="http://www.w3.org/2005/08/addressing";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> RequestID="request-id-is-just-a-string"
> wsu:Id="uuid-5ce88924-a565-452a-aadd-f8068f49348f">
> <dss:OptionalInputs>
> <dsb:Other>
> <dsb:Value>d2hlcmUgZG8gSSBwdXQgbXkgWE1MIHNpZ25hdHVyZT8=</dsb:Value>
> </dsb:Other>
> <my:Test>
> <my:Value>hello world</my:Value>
> </my:Test>
> <sec:Security>
> <wsa:MessageID>message-identifier</wsa:MessageID>
> <wsu:Timestamp>
> <wsu:Created>created-value</wsu:Created>
> <wsu:Expires>expires-value</wsu:Expires>
> </wsu:Timestamp>
> <wsa:ReplyTo>
> <wsa:Address>https://relying.party/landing-page</wsa:Address>
> </wsa:ReplyTo>
> <ds:Signature>
> <ds:SignedInfo>
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> <ds:SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> <ds:Reference URI="#uuid-5ce88924-a565-452a-aadd-f8068f49348f">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transforms>
> <ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> <ds:DigestValue>5W8u9z3+OfORMX1eyBtXZwnl3lU=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue>...</ds:SignatureValue>
> <ds:KeyInfo>
> <ds:KeyName>key-name</ds:KeyName>
> </ds:KeyInfo>
> </ds:Signature>
> </sec:Security>
> </dss:OptionalInputs>
> </dss:SignRequest>
>
>
> Notice that we also had to redefine dss:SignRequest to have an Id of
> type xs:ID so we can ds:Reference it properly.
>
> So our redefine XML schema becomes:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
> xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema"
> targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema"
> xmlns:sec="urn:dss:security"
> elementFormDefault="qualified"
> attributeFormDefault="unqualified">
>
> <xs:include schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/>
>
> <xs:import namespace="urn:dss:security"
> schemaLocation="dss-security.xsd"/>
>
> <xs:redefine schemaLocation="oasis-dss-core-schema-v1.0-os.xsd">
> <xs:complexType name="SignRequestType">
> <xs:complexContent>
> <xs:extension base="dss:SignRequestType">
> <xs:attributeGroup ref="sec:SecurityAttributeGroup"/>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> <xs:complexType name="OptionalInputsSignType">
> <xs:complexContent>
> <xs:extension base="dss:OptionalInputsSignType">
> <xs:group ref="sec:SecurityGroup"/>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>
>
> </xs:schema>
>
>
> And the extension XML schema itself:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
> targetNamespace="urn:dss:security"
> xmlns:sec="urn:dss:security"
> xmlns:wsa="http://www.w3.org/2005/08/addressing";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
> elementFormDefault="qualified"
> attributeFormDefault="unqualified">
>
> <xs:import namespace="http://www.w3.org/2005/08/addressing";
> schemaLocation="ws-addr.xsd" />
>
> <xs:import
> namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> schemaLocation="oasis-200401-wss-wssecurity-utility-1.0.xsd"/>
>
> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#";
> schemaLocation="xmldsig-core-schema.xsd"/>
>
> <xs:group name="SecurityGroup">
> <xs:choice>
> <xs:element name="Security" type="sec:SecurityType">
> <xs:annotation>
> <xs:documentation>
> Defines message-level security.
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> </xs:choice>
> </xs:group>
>
> <xs:complexType name="SecurityType">
> <xs:sequence>
> <xs:element ref="wsa:MessageID">
> <xs:annotation>
> <xs:documentation>
> A unique identifier for this message.
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element ref="wsu:Timestamp">
> <xs:annotation>
> <xs:documentation>
> Message should only be used within this time
> frame.
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element ref="wsa:ReplyTo">
> <xs:annotation>
> <xs:documentation>
> The URL to which the DSS should send a
> response message.
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element ref="ds:Signature">
> <xs:annotation>
> <xs:documentation>
> The message signature.
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
>
> <xs:attributeGroup name="SecurityAttributeGroup">
> <xs:attribute ref="wsu:Id" use="required"/>
> </xs:attributeGroup>
>
> </xs:schema>
>
>
>
> Kind Regards,
> Frank.
>
>
> On 02/03/2018 08:08 PM, Andreas Kuehne wrote:
>> Hi Frank,
>>
>>> There seems to be an error in your rewritten xmldsig-core-schema. It
>>> can no longer validate XML signatures:
>>>
>>> cvc-complex-type.2.4.a: Invalid content was found starting with
>>> element 'ds:SignedInfo'. One of
>>> '{"http://www.w3.org/2000/09/xmldsig#":SignatureValue}' is expected.
>>>
>> the ds:SignedInfo MUST NOT show up. An XMLDSig signature is expected to
>> be contained within a dss:SignatureObject element. Where did you manage
>> to insert the signature?
>>
>> Greetings,
>>
>> Andreas
>>>
>>> Kind Regards,
>>> Frank.
>>>
>>> On 02/02/2018 01:33 PM, Andreas Kuehne wrote:
>>>> Hi all,
>>>>
>>>>
>>>> as agreed on the last call I did some research regarding the volume of
>>>> imported structures.
>>>>
>>>> XMLDSig & SAML:
>>>>
>>>> The blobification of signatures and timestamps in the core limits the
>>>> core's references to external types significantly. There are the SAML
>>>> schemes and XMLDSig. The latter provides especially
>>>> CanonicalizationMethodType and TransformType. Both contain all major
>>>> non-XML-syntax incompatibilities: xs:any, mixed content and a XPath
>>>> expression. The 're-creation' of these types in a compatible way
>>>> within
>>>> DSS-X core could be an option. The same is true for SAML.
>>>>
>>>>
>>>> XAdES:
>>>>
>>>> Considering the AdES or the Verification profile the XAdES schema is
>>>> included. It contains many structures and types that do not fit
>>>> into the
>>>> multi-syntax approach. It even defines the most evil AnyType (sequence
>>>> of xs:any and mixed content and an arbitrary set of attributes). It
>>>> also makes intensive use of the '<xs:choice maxOccurs="unbounded">'
>>>> pattern that does not fit very well with Java's schema-to-code
>>>> compiler.
>>>> This pattern produces non-typesafe code like an xs:any. So the version
>>>> 2.0 design goals cannot be achieved with an unmodified XAdES schema. A
>>>> quick check with the code coverage of my DSS-X tests shows that at
>>>> least
>>>> 50% (25 out of 50) of the structures defined in XAdES are used so
>>>> cherrypicking of the 'useful few' does not work out.
>>>>
>>>> Applying the blobification approach to the verification report sounds
>>>> promising for the verification report if it will restricted to be
>>>> 'XML-syntax only'. This could be acceptable and the JSON syntax
>>>> problem
>>>> do not apply. But the verification report itself is not a autonomous
>>>> artifact but uses the core schema. So we would introduce a mix of
>>>> multi-syntax-enabled types and XML-only parts. To me this sounds
>>>> like a
>>>> concept that wiil be hard to understand for any DSS-X user.
>>>>
>>>>
>>>> My recommendation would be to keep things easy to use and consistent:
>>>> Support the multi-syntax paradigm everywhere and don't introduce
>>>> XML-only profiles! But this comes with price of rewriting of external
>>>> schemes.
>>>>
>>>>
>>>> Let's see what's Peter's view on JSON support for the verification
>>>> report. I wouldn't be surprised that team working with Javascript
>>>> in the
>>>> browser and / or node.js in the server side would appreciate to see a
>>>> verification report in JSON.
>>>>
>>>>
>>>> Greetings,
>>>>
>>>>
>>>> Andreas
>>>>
>
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]