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

Hi Scott,

(I'm not sure if I can email the public-xmlsec list, so you may need to 
forward this).

Thanks for this detailed response.  I've copied Harold Booth from NIST.

Leaving aside all other matters for now, you mentioned that validating 
before canonicalizing -- and specifically adding any default and fixed 
attributes -- is a necessity for interoperability.  (I agree!)  My 
reading of c14n 1.1 suggested this would be considered part of 
canonicalization, but you seem to be saying it's not relevant?  However, 
you also said (of adding fixed attributes before signing): "it's a 
widely accepted rule".

Your preferred approach of eliminating these attributes from the schema 
is not an option, as these are SCAP specifications that have been 
standardized, published, adopted by numerous extremely large government 
agencies, and there is even a NIST validation program behind it.  So we 
are stuck with them as they are, warts and all.  So abiding by this rule 
-- whether it's inherent to c14n11 or otherwise -- seems to be a 
workable alternative.

But can you tell me, if this isn't considered part of canonicalization, 
where is this rule documented?

Best regards,
--David Solin

On 10/22/2014 9:00 PM, Cantor, Scott wrote:
> 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
>


-- 

jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>