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
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
