From timlegge at gmail.com  Mon Jan  4 09:07:14 2021
From: timlegge at gmail.com (Timothy Legge)
Date: Mon, 4 Jan 2021 13:07:14 -0400
Subject: [xmlsec] DSA Signatures
Message-ID: <CALTFL3U5J-voXeqJdwVhA0hk7yMZce8MWusXd7d8AhtTkoZRKA@mail.gmail.com>

Hi

This is somewhat off topic as it is related to my maintenance of the
Perl XML::Sig module.

DSA signatures are a base64 encoded concatenation of the r and s octet
streams.  I can sign and verify DSA signatures with XML::Sig or xmlsec
but occasionally the DSA signature validation fails (for both XML::Sig
and xmlsec at the same time).

I assume something is getting lost when I concatenate  r and s before
it is base64 encoded.  Any thoughts based on how xmlsec generates the
base64 encoded DSA signature?

regards

Tim

From aleksey at aleksey.com  Mon Jan  4 10:25:40 2021
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 4 Jan 2021 11:25:40 -0700
Subject: [xmlsec] DSA Signatures
In-Reply-To: <CALTFL3U5J-voXeqJdwVhA0hk7yMZce8MWusXd7d8AhtTkoZRKA@mail.gmail.com>
References: <CALTFL3U5J-voXeqJdwVhA0hk7yMZce8MWusXd7d8AhtTkoZRKA@mail.gmail.com>
Message-ID: <da8e2530-3e3f-fa2f-72dc-afcd16ab378f@aleksey.com>

https://www.w3.org/TR/xmldsig-core1/#sec-DSA

Aleksey

On 1/4/21 9:07 AM, Timothy Legge wrote:
> Hi
> 
> This is somewhat off topic as it is related to my maintenance of the
> Perl XML::Sig module.
> 
> DSA signatures are a base64 encoded concatenation of the r and s octet
> streams.  I can sign and verify DSA signatures with XML::Sig or xmlsec
> but occasionally the DSA signature validation fails (for both XML::Sig
> and xmlsec at the same time).
> 
> I assume something is getting lost when I concatenate  r and s before
> it is base64 encoded.  Any thoughts based on how xmlsec generates the
> base64 encoded DSA signature?
> 
> regards
> 
> Tim
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From timlegge at gmail.com  Mon Jan  4 11:06:43 2021
From: timlegge at gmail.com (Timothy Legge)
Date: Mon, 4 Jan 2021 15:06:43 -0400
Subject: [xmlsec] DSA Signatures
In-Reply-To: <da8e2530-3e3f-fa2f-72dc-afcd16ab378f@aleksey.com>
References: <CALTFL3U5J-voXeqJdwVhA0hk7yMZce8MWusXd7d8AhtTkoZRKA@mail.gmail.com>
 <da8e2530-3e3f-fa2f-72dc-afcd16ab378f@aleksey.com>
Message-ID: <CALTFL3UDz=p1o_9J_TN7KC185h1UK_TOU0JBT3+TBcZ=wZ1T2w@mail.gmail.com>

Thanks.  I suspect it is related to the possible leading zeros in the
I2OSP spec that I may be losing when I concatenate r and s but I have
not tracked it down yet.

Tim

On Mon, Jan 4, 2021 at 2:25 PM Aleksey Sanin <aleksey at aleksey.com> wrote:
>
> https://www.w3.org/TR/xmldsig-core1/#sec-DSA
>
> Aleksey
>
> On 1/4/21 9:07 AM, Timothy Legge wrote:
> > Hi
> >
> > This is somewhat off topic as it is related to my maintenance of the
> > Perl XML::Sig module.
> >
> > DSA signatures are a base64 encoded concatenation of the r and s octet
> > streams.  I can sign and verify DSA signatures with XML::Sig or xmlsec
> > but occasionally the DSA signature validation fails (for both XML::Sig
> > and xmlsec at the same time).
> >
> > I assume something is getting lost when I concatenate  r and s before
> > it is base64 encoded.  Any thoughts based on how xmlsec generates the
> > base64 encoded DSA signature?
> >
> > regards
> >
> > Tim
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
> >

From aleksey at aleksey.com  Mon Jan  4 11:09:53 2021
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 4 Jan 2021 12:09:53 -0700
Subject: [xmlsec] DSA Signatures
In-Reply-To: <CALTFL3UDz=p1o_9J_TN7KC185h1UK_TOU0JBT3+TBcZ=wZ1T2w@mail.gmail.com>
References: <CALTFL3U5J-voXeqJdwVhA0hk7yMZce8MWusXd7d8AhtTkoZRKA@mail.gmail.com>
 <da8e2530-3e3f-fa2f-72dc-afcd16ab378f@aleksey.com>
 <CALTFL3UDz=p1o_9J_TN7KC185h1UK_TOU0JBT3+TBcZ=wZ1T2w@mail.gmail.com>
Message-ID: <d9d7de29-eb6c-fd2a-104b-3a21b0c91dd6@aleksey.com>

Right, I know remember that I had problems with leading zero's
as well :) Take a look at the code for details:

https://github.com/lsh123/xmlsec/blob/f3a59c721e38a663405093e2bbb30e2bf45853a2/src/openssl/signatures.c#L597



Aleksey

On 1/4/21 11:06 AM, Timothy Legge wrote:
> Thanks.  I suspect it is related to the possible leading zeros in the
> I2OSP spec that I may be losing when I concatenate r and s but I have
> not tracked it down yet.
> 
> Tim
> 
> On Mon, Jan 4, 2021 at 2:25 PM Aleksey Sanin <aleksey at aleksey.com> wrote:
>>
>> https://www.w3.org/TR/xmldsig-core1/#sec-DSA
>>
>> Aleksey
>>
>> On 1/4/21 9:07 AM, Timothy Legge wrote:
>>> Hi
>>>
>>> This is somewhat off topic as it is related to my maintenance of the
>>> Perl XML::Sig module.
>>>
>>> DSA signatures are a base64 encoded concatenation of the r and s octet
>>> streams.  I can sign and verify DSA signatures with XML::Sig or xmlsec
>>> but occasionally the DSA signature validation fails (for both XML::Sig
>>> and xmlsec at the same time).
>>>
>>> I assume something is getting lost when I concatenate  r and s before
>>> it is base64 encoded.  Any thoughts based on how xmlsec generates the
>>> base64 encoded DSA signature?
>>>
>>> regards
>>>
>>> Tim
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>

From matyc at redhat.com  Thu Jan 21 07:58:42 2021
From: matyc at redhat.com (Matej Tyc)
Date: Thu, 21 Jan 2021 16:58:42 +0100
Subject: [xmlsec] Signature verification vs namespaces
Message-ID: <3e78559b-e688-cbbd-9a05-780d4315e24b@redhat.com>

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



From aleksey at aleksey.com  Thu Jan 21 08:41:29 2021
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 21 Jan 2021 08:41:29 -0800
Subject: [xmlsec] Signature verification vs namespaces
In-Reply-To: <3e78559b-e688-cbbd-9a05-780d4315e24b@redhat.com>
References: <3e78559b-e688-cbbd-9a05-780d4315e24b@redhat.com>
Message-ID: <a29a6665-0cb1-8dd9-b112-209fbc276402@aleksey.com>

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