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

Hi Scott,

The Java issue does pertain to the built-in support for XMLDSIG. Here is 
a reference for you:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8017171

In our case, we bundle copies of all the the schemas, and re-write the 
schemaLocation attribute during unmarshalling to point to our copies.  
So in a very real sense, for us, schema-validation implements 
application-specific awareness of the ID fields during signature 
verification (with awareness in the data model encoded when the JAXB 
model classes are generated).

As for validation being indicated by c14n11, just so you know how this 
crazy idea popped into my head, it came from reading the bullets:

  * Attribute values are normalized, as if by a validating processor
  * Default attributes are added to each element

.... which are found in the definition of the term /canonical form/ in 
section 1.1 of the W3C recommendation 
(http://www.w3.org/TR/xml-c14n11/).  I am not an attorney, but while it 
certainly doesn't say you have to validate... really, it certainly does 
appear to say you have to validate.

Anyway, you do see in the published version 
(http://www.w3.org/TR/xmldsig-bestpractices/) of the draft you 
referenced, that best practice recommendation did make it into the final:

/"Best Practice 24: Signers: Do not rely on a validating processor on 
the consumer's end.//
//
//"Do not rely on a validating processor on the consumer's end to 
normalize XML documents. Instead, explicitly include default attribute 
values, and use normalized attributes when possible."/

At least that is something!

Best regards,
--David Solin

On 10/22/2014 10:29 PM, Cantor, Scott wrote:
> On 10/22/14, 11:10 PM, "David Solin" <david@joval.org> wrote:
>> 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.
> Not validating per se (producers of documents rarely validate them), just
> populating any/all attributes that need to have values, and not leaving
> them implicit to recipients. If you do that, you will have interop
> problems. That's just a clear lesson that's been learned over a long
> period of time.
>
>>   (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?
> It is not in any way part of Inclusive or Exclusive 1.x canonicalization.
> They are schema-unaware algorithms, and so they cannot possibly address
> adding default or fixed attributes.
>
>>   However, you also said (of adding fixed attributes before signing):
>> "it's a widely accepted rule".
> Rule in the informal sense. Ignore it and somebody's code will probably
> break.
>
>> But can you tell me, if this isn't considered part of canonicalization,
>> where is this rule documented?
> We included it in the best practice material that wa drafted when the 1.1
> specs were published (see [1] 4.2). It is not a specification rule. I
> don't know that that material was ever anything but a draft, it seems to
> have stalled there.
>
> There are other considerations that come into play when validating
> documents before a signature is checked, such as data type normalization.
>
> Something in the thread mentioned Oracle making a change to Java, but I
> don't know what that refers to. Validation is certainly not on by default,
> it's something parsers have to be told to do. Maybe they did something in
> the standardized signature APIs, none of my project's code uses those.
>
> -- Scott
>
> [1] http://www.w3.org/2008/xmlsec/Drafts/best-practices/Overview.html
>


-- 

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