RE: Default values in XML Schema - why should we bother?

> Why should we bother?

Historically it just wasn't addressed, and so the problem is that if the
signer schema-validates when parsing and the verifier doesn't, or vice
versa, you get different results from c14n of that DOM. Defaults are one
reason, schema normalization of data types is the other.

The question we have to address is whether to do anything about it or
nothing. There are reasonable arguments for nothing, but ultimately it's up
to c14n to address it, or not, based on whether the XSD validation model is
"in scope" or not. Historically only core XML validity has been in scope.

> If signature application, verification, and processing all stick to the
> same approach (i.e. either all or none of them validates XML Schema) we
> are fine.

But that's not reality, particularly since often the signer is constructing
the DOM directly. It's rare for the signer in a non-document scenario to be
validating what it built. So the effect of your suggestion is to tell
verifiers not to validate (or to separate the two steps). That's an option,
but with some tools it's quite inefficient to the point that it also ends up
being a prohibition on validation.

> However, all of these attack vectors rely on that the attacker is
> capable of modifying the XML Schema used for validation at the
> recipient's side. I'm not sure it is possible to embed a full XML Schema
> e.g. in a SOAP message and convince the recipient to use that one for
> validation. Maybe we should put a short text regarding this in the best
> practices document?

If you mean secure schema association, that's really an XML Schema issue,
not a Signature one.

But to answer your question, yes, bad code can be fooled into loading
arbitrary schemas. I wish parsers by default would provide automatic
prohibitions on remote DTD and schema access.

-- Scott

Received on Wednesday, 5 May 2010 14:31:12 UTC