santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dittmann, Werner" <werner.dittm...@siemens.com>
Subject AW: [xml-sec] Some thought about the JCE provider
Date Tue, 21 Mar 2006 12:59:23 GMT
Raul,

also +1 for having a global setting available. Thus I would then
use the following algorithm:

- first check if a provider was set using XMLSignature / XMLCipher
  setJCEprovider method, if set use this an propgate it to the
  other implemntation classes.

- If no specific provider was set, check for a global setting and
  use it in the same way as for the specific setting

- otherwise do nothing, that is use standard provider

Thoughts?

Regards,
Werner


> -----Ursprüngliche Nachricht-----
> Von: raul.benito.garcia@gmail.com 
> [mailto:raul.benito.garcia@gmail.com] Im Auftrag von Raul Benito
> Gesendet: Dienstag, 21. März 2006 10:41
> An: security-dev@xml.apache.org
> Betreff: Re: [xml-sec] Some thought about the JCE provider
> 
> +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