[xmlsec] X509Data

[Jason Dale]

Aleksey,
Thank you for your reply.
>
>> "The entire certificate chain of the signer, including the root
>> certificate, ...
> Well, you can have root/trusted cert in the signed document but you
> also MUST have it in the client in order to establish trust.
>
Yes, that's a different part of the document.

>
>> X509Data elements. Each of the X509Data elements shall correspond to one
>> certificate in the chain, and contain one X509IssuerSerial element and
>> one
>> X509Certificate element. The certificates may appear in any order."
>> The research I've done seems to indicate that the entire certificate
>> chain
>> must be in one X509Data element.  Unfortunately I've not been able to
>> get
>> a definitive statement from the XML Digital Signature page that says
>> that.
>>  While researching this email, I just noticed the bit about the
>
>  From XMLDsig spec
>
> An X509Data element within KeyInfo contains one or more identifiers
> of keys or X509 certificates....
>
> My reading of this is that each X509Data element is a self contained
> "pointer" to the key/certificate. Though, I can see arguments
> against it.
>
The X509Data element seems to be almost an orphan of all the elements in
the KeyInfo element.  It seems to me that the child elements of the
KeyInfo elements are there solely to identify the key that will validate
the signature.  The addition of the certificate chain just seems to
introduce noise into this process, and add unnecessary complication.  I'm
just learning this, so I probably don't have the finer points (or even the
coarser points).

>> I have a couple of questions then.  Suppose I am unable to convince the
>> author that his version is incorrect, and I have to work under those
>> constraints.  How would you go about it?  I have a few ideas, but I
>> would
>> appreciate the advice.
> Well, nothing is impossible, it's only software :) Probably the easiest
> change to xmlsec would be to accumulate the content of all the X509Data
> elements before actually processing them. Should not be too bad from
> implementation point of view.
>
Yes, that seemed to be the most logical way.  Another thought I had was,
since the documents aren't terribly large, to simply create a temporary
copy of the document and dump all the certificates into one X509Data tag,
then proceed as normal with the copy.

>> Second, a more philosophical question I suppose.  How much of a fight
>> should I put up on this?  Or am I completely mistaken in my assessment?
>
> I would say that this significantly depends on the goals of your project
> and the behavior of other XMLDSig implementations (sorry, I never run
> into this problem before). If all other toolkits are different from
> xmlsec then xmlsec needs to be fixed :) If you project does not care
> about interoperability  (though it might be a bad idea long term)
> then this is one story. If you want to have interoperability and
> all other XMLDsig toolkits do the same as xmlsec does then it is
> another story.
>
I pointed out the interoperability issue to the author.  His reply was
that he didn't expect 3rd party validation to be possible.  But since
there is a desire to eventually publish this spec, I don't know how they
plan to avoid interoperability problems.

> BTW, please if you will be doing research of other xmldsig toolkits
> behavior then I would really appreciate if you can post your results
> here.
>
Sorry, I should have mentioned that the author uses the Apache library. 
He informed me that library would validate the signature if the key
happened to be in the first X509Data element.  (Hence the "get lucky"
comment).  My experience with xmlsec is that the validation fails because
the chain can't be validated.

>
> Thanks,
> Aleksey
>
>

Jason