First of all, lets make clear that we are talking here about xmlSecOpenSSL* functions.The issue is: why do you add "untrusted certs from x509store.". I think I know why, but wanted to hear it from you.
Nobody said that other crypto libraries should do the same. Because OpenSSL just
ignores these certs. This is a workaround for a "todo" in OpenSSL sources. Probably
other implementations should not do it.
It took some time and few XMLDSig mailing list searches before I painted the fullThe spec is a bit ambiguous about whether the certs_from_<X509Data> contains the public key to be used.
picture myself. My understanding is that:
1) all certs included or pointed to in a single <dsig:X509Data/> element should
either contain a signature key or be a part of certificates chain that points to
signature key;
2) one <dsig:X509Data/> element may contain multiple key certificates or certificates
chains but all of them (of course) contain *the same* key (for example, you can put
multiple certs with the same key signed with different root certs);
3) all certs for one certificate chain MUST be placed in one <dsig:X509Data/> element.
Examples (A0,A1,A2 and B0,B1,B2 are certificates chains with same key in A0 and
B0 certs):
1. (good) All in one.
One <dsig:X509Data/> element contain all 6 certs: A0, A1, A2, B0, B1 and B2.
2. (good) Two <dsig:X509Data/> elements.
First <dsig:X509Data/> element contain A0, A1 and A2. Second <dsig:X509Data/>
element contain B0, B1 and B2.
3. (bad) Invalid mix.
First <dsig:X509Data/> element contain A0 and A1. Second <dsig:X509Data/> element
has A2, B0, B1 and B2.
4. (bad) Unrelated cert.
One <dsig:X509Data/> element contain all 6 certs plus one unrelated cert: A0, A1, A2, B0,
B1, B2 and C (where C is something not related to A's and B's chain and do not contain
signature key).
Aleksey
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
