OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss-x] Rewriting of imported schemes


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


--
Frank Cornelis
e-Contract.be BVBA
https://www.e-contract.be



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]