[xmlsec] Signature verification vs namespaces

[Aleksey Sanin]

Hi Matej,

The --id-attr is not a hack. It's just that one needs to somehow
tell XML parser what is the ID attribute in the XML doc (including
namespace). If you are using xmlsec1 command line utility, then
--id-attr is a perfectly valid way of doing it. If you integrate
with the xmlsec library itself, then you have other options through
using LibXML2 library directly.

Hope this helps,

Aleksey

On 1/21/21 7:58 AM, Matej Tyc wrote:
> Hello,
> 
> one of the use cases of XML signing is signing of security content of 
> SCAP datastreams, which is a XML format standardized by NIST, i.e. one 
> would consider that as mainstream rather than obscure. Contents of 
> datastreams can be signed, and if this is the case, the namespace of the 
> signature element and the element that is signed differs. The example 
> r900-rhel-datastream.xml from the test suite can be obtained at [1] 
> (extracted file for your convenience is available at [2]).
> 
> This namespace discrepancy causes the xmlsec1 utility not to work out of 
> the box. [3] points to a solution - one has to "declare" the missing 
> namespaces using the --id-attr flag, e.g. xmlsec1 --verify --id-attr 
> http://scap.nist.gov/schema/scap/source/1.2:component --id-attr 
> http://scap.nist.gov/schema/scap/source/1.2:data-stream 
> r900-rhel-datastream.xml . However, the project FAQ [4] refers to this 
> as if it was some kind of a dirty hack.
> 
> The recommended solution would be to use a DTD. SCAP XMLs are complex, 
> there are XSDs available, but not DTDs. And those would be really 
> murderous. And aside from that, we just need to point out to namespaces 
> that should be considered when searching for the signed element, so one 
> doesn't have a big incentive to deal with complex files.
> 
> Do you have any ideas how to approach this problem in a non-hackish way 
> that we may be missing?
> 
> Thanks,
> Matej
> 
> Refs:
> 
> [1]: 
> https://csrc.nist.gov/projects/scap-validation-program/validation-test-content 
> 
> [2]: https://fedorapeople.org/~jcerny/r900-rhel-datastream.xml
> [3]: https://www.aleksey.com/xmlsec/faq.html#section_3_4
> [4]: https://www.aleksey.com/pipermail/xmlsec/2011/009201.html
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec