- From: Scott Cantor <cantor.2@osu.edu>
- Date: Tue, 02 Sep 2008 21:35:47 -0400
- To: Pratik Datta <pratik.datta@oracle.com>
- CC: public-xmlsec@w3.org
>> I agree that this should be handed over to a different library, and >> not done by the XML Signature processing library, but XML signature >> processing library would need to parse this X509Data elements and >> create a certficate chain and then hand it over to a CertPathValidtor >> library. Sorry to follow up twice, I think I misread this and need to make a stronger point. It is in fact *bad* for a generalized signature implementation to do this. The signature library should NOT just hand them over to anything (or at least it should be optional). The *application* should be able to do this itself, because only the application is in a position to understand its trust requirements and do the appropriate thing. The signature library's job is to expose the information so that the application can access it and perform trust operations in conjunction with the verification process. There's nothing more frustrating than having to crack open a perfectly usable library because the author thinks there's only one way to handle a certificate. (That's assuming it's open source and you actually can.) This is one reason I made the comment, to emphasize the importance of leaving this open. (Obviously there are signature implementations that are not general purpose in which it may be perfectly appropriate to make these decisions.) -- Scott
Received on Wednesday, 3 September 2008 01:36:26 UTC