+1 to me.... But as user I also think it will be very good to have a global(over writable) configuration like we have right now. I should check the provider at position 2. But I think we should add this info in the xml-sec FAQ...
Regards, Raul On 3/21/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > Raul, > > to define it explicitly I would not modify existing method > signature but add a new method for XMLSignature and XMLCipher > to set a provider, somthing like "setJCEProvider(String id)" . > > This way the implementation can check and propagate the info > to other classes is required. > > Defining a specific provider may be required if the application > that uses XMLSignature or XMLCipher is not authorized to register > new JCE providers but have the requirement to use a specific > JCE provider, maybe because of some specific implementation of > an algorithm. > > Of course, if no JCEProvider was set the standard provider will > be used. > > > Just as a note: > When registering a new JCE provider never ever insert it at > position 1 - this position seems to be resereved by Sun for the > provider that validates the JCE provider jar file. This provider > does not have other methods. Registering a new provider at > position 2 is ok. Doing so guarantees that this provider will be > used if it provides the necessary algorithm. > > > Regards, > Werner > > > -----Ursprüngliche Nachricht----- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Im Auftrag von Raul Benito > > Gesendet: Montag, 20. März 2006 18:31 > > An: security-dev@xml.apache.org > > Betreff: Re: [xml-sec] Some thought about the JCE provider > > > > Hi Werner, > > > > I have been thinking about your proposal I don't see how it's > > possible to implement your second approach without changing the public > > API (a see the biggest problem while verifying). But I'm sure you > > already have an idea. Can you share with me? > > > > Regards, > > > > Raul > > > > On 3/12/06, Werner Dittmann <[EMAIL PROTECTED]> wrote: > > > All, > > > > > > currently xml-sec use two different ways to specify which provider > > > to use for a specific algorithm: > > > > > > 1. Set the provider id is a class variable in JCEMapper. An explicit > > > check must be made to see if the provider id is set and > > then use it. > > > > > > 2. The XMLCipher uses different getInstance(...) methods to specify > > > a provider. Thus it is sort of an explicit definition. > > > > > > Porposal: Use only one way to specify a JCE provider. I would opt > > > for the second way (definie ti explicitly). For some time we could > > > declare the "old" method as deprecated. > > > > > > In that sens I would also propose to implement a sort of fallback > > > mechanisms if the specified provider is either not avaliable or does > > > not provider the required algorithm. In such a case > > > > > > - issue a "log.warning" message (not an error) and > > > > > > - fallback to a standard provider. Only if this also fails throw an > > > exception. > > > > > > What do you think? > > > > > > Regards, > > > Werner > > > > > > > > > -- > > http://r-bg.com > > > -- http://r-bg.com
