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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: RE: [dss] OASIS DSS "Request for Feedback" - Signing Templates


> This can happen on KeySelector just as easily as it can on KeyInfo, it is
> just a matter of how one instructs the server to create signatures.

I'm not so sure.  The server can always "protect" itself by putting in the
X509Certificate element that it has "on file."

> I believe the benefit, especially in the area of complex
> Reference/Transform combinations outways the very few "slip by the server"
> concerns, which should be carefully validated anyway.

I'm not so sure.  For example, if I ask for an embedded signature with an
xslt transform -- i.e., the server will return the "modified" document
with signature to me -- then I could probably coerce the server into
giving me files on its local disk that it doesn't want to:

  <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116";>
    <xsl:template>
      <xsl:variable name="x">
        <noise>file<noise>:///etc</noise>/<noise/>
          <noise/>passwd
        </noise>
      </xsl:variable>
      <tns:foo>
        <!-- The document call does an implicit "xsl:string" call
          on its argument, which means it ends up with
                 file:///etc/passwd
          the URL for the password file on many unix-like systems. -->
        <xsl:copy><xsl:value-of select="document($x)"/></xsl:copy>
      </tns:foo>
    </xsl:template>
  </dsig:Transform>

Is it reasonable to expect a DSS server to understand the semantics of
xslt so that it can protect itself from this?  Probably not.  Is it
reasonasble to require a DSS server to appropriate hook itself into the
xslt engine that it uses, so that it can verify all document() calls?
Maybe.  But there's also xsl:include, xsl:import, external entities
therein, etc.

> This I believe is up
> to the implementation, afterall it is the server that has the last word. But
> I see your point about having the core "Warn" implementations to be careful.

Warn, in the sense that Ivan is a spring zephyr. :)

> Please remember, feedback is being solicited on the core versus profile
> decision, not on the virtues/pitfalls of templates.

Yup, I understand.  That is why I want them to be a separate profile, so
that my server be compliant, not implement them, and therefore be more
secure.

	/r$

--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html



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