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

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

Received on Thursday, 23 October 2014 03:30:27 UTC