Re: Comments on best practices revision

>> 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