hello Casey,
On Wednesday 29 March 2006 12:01, Casey Marshall wrote:
> On Mar 28, 2006, at 11:56 AM, Raif S. Naffah wrote:
> ...
> Note that there is a beginning of a keytool implementation in GNU
> Crypto CVS. Some of the basic functions work (list, export, and
> import, I think), so it may be he
On Mar 28, 2006, at 11:56 AM, Raif S. Naffah wrote:
hello Mark,
On Wednesday 29 March 2006 03:45, Mark Wielaard wrote:
...
I will send an email to FSF legal about using a (reimplementation)
of the JKS format.
Done and answered. We are free to reimplement this. File formats and
algorithms ar
hello Mark,
On Wednesday 29 March 2006 03:45, Mark Wielaard wrote:
> ...
> > I will send an email to FSF legal about using a (reimplementation)
> > of the JKS format.
>
> Done and answered. We are free to reimplement this. File formats and
> algorithms aren't copyrightable, so any code we write to
Hi,
On Fri, 2006-03-24 at 11:57 +0100, Mark Wielaard wrote:
> OK, that is good. Do we actually have any alternative KeyStore format?
> If yes then we should as Roman says use this as default for now.
I see we do, GKR, defined in gnu.javax.crypto.jce.keyring.GnuKeyring.
But KeyStore.getDefaultTyp
On Fri, 2006-03-24 at 04:16 +1100, Raif S. Naffah wrote:
> On Thursday 23 March 2006 23:18, Roman Kennke wrote:
> > ...A jarsigner can well be
> > implemented without JKS and have a Provider plugged in for different
> > keystore formats. This would be done via the
> > java.security.KeyStore.getInst
On Mar 23, 2006, at 11:11 AM, Casey Marshall wrote:
On Mar 23, 2006, at 3:47 AM, Audrius Meskauskas wrote:
Maybe one person can look into that code, write the brief draft of
the documentation and then another can implement it using that
documentation only? This would be the possibility to w
On Mar 23, 2006, at 3:47 AM, Audrius Meskauskas wrote:
Maybe one person can look into that code, write the brief draft of
the documentation and then another can implement it using that
documentation only? This would be the possibility to work with
formats for that there is no other specific
hello Roman,
On Thursday 23 March 2006 23:18, Roman Kennke wrote:
> ...A jarsigner can well be
> implemented without JKS and have a Provider plugged in for different
> keystore formats. This would be done via the
> java.security.KeyStore.getInstance() method AFAICS. I think this is
> what Sun's ja
Hi there,
I have looked into this area lately too. A jarsigner can well be
implemented without JKS and have a Provider plugged in for different
keystore formats. This would be done via the
java.security.KeyStore.getInstance() method AFAICS. I think this is what
Sun's jarsigner also does via the --
hello Mark,
On Thursday 23 March 2006 22:06, Mark Wielaard wrote:
> On Thu, 2006-03-23 at 21:16 +1100, Raif S. Naffah wrote:
> ...i'd like a second opinion on a legal-related issue.
> >
> > the tool reads and uses private and public cryptographic data from
> > a keystore that is in a proprietary f
Maybe one person can look into that code, write the brief draft of the
documentation and then another can implement it using that documentation
only? This would be the possibility to work with formats for that there
is no other specification available apart from the released piece of the
implem
Hi Raif,
On Thu, 2006-03-23 at 21:16 +1100, Raif S. Naffah wrote:
> i now have a working first (rough) cut of the above.
Very cool!
> but before i check
> the code in i'd like a second opinion on a legal-related issue.
>
> the tool reads and uses private and public cryptographic data from a
>
hello all,
i now have a working first (rough) cut of the above. but before i check
the code in i'd like a second opinion on a legal-related issue.
the tool reads and uses private and public cryptographic data from a
keystore that is in a proprietary format: "JKS" from Sun. the code i
use to
13 matches
Mail list logo
