Re: [scap-dev] Broken XML signatures in USGCB datastreams

On 10/22/14, 5:38 PM, "Wendy Seltzer" <wseltzer@w3.org> wrote:
>
>I'd like to bring to the group's attention an issue with XML digital
>signature validation -- whether (and how) c14n11 applies when only an
>XSD is available, and if not, whether c14n11 is suitable for use with
>XML digital signatures in such a case.

All the standard c14n algorithms interact with XSD validation (or lack)
identically, there's nothing specific to 1.1 in this.

>The issue arises because of a set of signed XML documents created by
>NIST, whose XSD specifies fixed attributes which were not added during
>canonicalization -- breaking the signature when it's verified using an
>XSD-validating parser (which is the best practice in the Java
>programming language).

I wouldn't say that's the best practice in any environment, it's
application specific and context specific whether validation is done. It
is in no way a requirement to do signature verification, and it adds
nothing in terms of safety to the process. It provides at most a false
perception of safety.

The use of default or fixed attributes in a schema does not interact well
with signatures, and it's a best (more to the point, essentially
mandatory) practice to avoid omitting either in a document when you sign,
because leaving them out will lead to false negatives depending on whether
the recipient validates.

So, simply put, don't do it.

>> If there is no schema-validation going on, then there is no way for
>> the parser to know which nodes are actually IDs for the purpose of
>> signature validation (type=xsd:ID) -- hence making the parser
>> susceptible to a wrapping attack.

This is a misnomer. You cannot take the strict view that IDness is a
schema-only property if you intend to use them in signed documents. IDs
must be known to the application without relying on schemas or you're
rarely going to get correct behavior. That's just how it is. It's a
possible workaround to make sure that apps only process the explicit
output of a signature reference and transform chain, but that tends to be
difficult with a lot of APIs and often awkward in code.

Note, schema validation does *not* prevent wrapping attacks. Parsers do
not safely enforce ID uniqueness in documents in many cases, even if that
were enough. You can't just get around wrapping attacks by validating.

>>(I think it is obvious that adding fixed attributed during
>> canonicalization is the correct thing to do, provided there is
>> schema-awareness.)

Canonicalization algorithms in wide use are not schema aware, and do not
add fixed or default attributes. That needs to be done before hand to
prevent interop failures. And in turn, schemas should simply not contain
them to avoid creating the problem in the first place. It's a bad practice.

>>Furthermore, by asserting that one cannot use a schema-validating
>> parser for the purposes of c14n11 in the context of XML signature
>> validation, you are in turn saying that the specifications dictate
>> that the only way to perform XML digital signature validation without
>> being susceptible to a wrapping attack, where only an XSD is
>> available, is to hand-craft validation logic that understands exactly
>> which element attributes are type xsd:ID.

That is in fact true. It's not widely understood, but it's true. Those of
us with a SAML background have had to learn this the hard way. IDness is
an application layer issue and *cannot* be delegated to a parser or a
schema. It just won't work.

>>I would point out that, if NIST's XML signing process added the fixed
>> attributes to the canonicalized XML during signing (which would be a
>> perfectly valid thing to do), then both Java and whatever tools you're
>> already using would be able to successfully verify the signature.

Which is why that's the widely accepted rule. But it doesn't prevent
wrapping attacks, and doesn't allow applications to ignore knowledge of
IDness, because that's the most general way to enforce the "see what is
signed" rule, which is what actually prevents the attacks.

-- Scott

Received on Thursday, 23 October 2014 02:01:11 UTC