santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raul Benito" <r...@apache.org>
Subject Re: [xml-sec] Some thought about the JCE provider
Date Tue, 21 Mar 2006 09:41:04 GMT
+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 <werner.dittmann@siemens.com> 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: raul.benito.garcia@gmail.com
> > [mailto:raul.benito.garcia@gmail.com] 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 <Werner.Dittmann@t-online.de> 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

Mime
View raw message