jarsigner tool

[Raif S. Naffah]

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 do the reading from such a keystore* is available at 
.

i'd like a ruling on whether it's ok to import and use this code in GNU 
Classpath.


* the keystore i used for testing was generated by Sun's JDK 1.4.2_11 
keytool.


TIA + cheers;
rsn


pgp18apu4vSqK.pgp
Description: PGP signature

Re: jarsigner tool

[Mark Wielaard]

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 
> keystore that is in a proprietary format: "JKS" from Sun.  the code i 
> use to do the reading from such a keystore* is available at 
> .
> 
> i'd like a ruling on whether it's ok to import and use this code in GNU 
> Classpath.

Unfortunately no. The last time this came up FSF legal didn't like us
using code which was written by reverse engineering the original code
and format. And for which no public documentation was available at all.
We can ask again of course. And maybe just using the description of the
format (which I believe is also documented outside the code you
reference itself) and then letting someone else write a new
implementation for it is OK.

The question is also whether we really need to support this undocumented
keystore format. There are open formats. And we can also work towards
something like http://metastatic.org/text/gnu-keyring.txt

What is your opinion? Is it important enough to support this JKS format
to try and jump through some legal hoops? Or can we just stick to open
keystore formats?

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part

Re: jarsigner tool

[Audrius Meskauskas]

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 
implementing code.




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 do the reading from such a keystore* is available at 
.


i'd like a ruling on whether it's ok to import and use this code in GNU 
Classpath. 
TIA + cheers;

rsn



Unfortunately no.
 


(...)


Cheers,

Mark
 

Re: jarsigner tool

[Raif S. Naffah]

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 format: "JKS" from Sun.  the
> > code i use to do the reading from such a keystore* is available at
> > .
> >
> > i'd like a ruling on whether it's ok to import and use this code in
> > GNU Classpath.
>
> Unfortunately no. The last time this came up FSF legal didn't like us
> using code which was written by reverse engineering the original code
> and format. And for which no public documentation was available at
> all. We can ask again of course. And maybe just using the description
> of the format (which I believe is also documented outside the code
> you reference itself) and then letting someone else write a new
> implementation for it is OK.
>
> The question is also whether we really need to support this
> undocumented keystore format. There are open formats. And we can also
> work towards something like
> http://metastatic.org/text/gnu-keyring.txt
>
> What is your opinion? Is it important enough to support this JKS
> format to try and jump through some legal hoops? Or can we just stick
> to open keystore formats?

i think yes for two reasons:

1. for everything Java, Sun sets the pace.  in practice if Sun offers a 
format, an API, etc... Java programmers will use it in preference to 
any other alternative.  an example would be the log4j logging API v/s 
jdk logging.

2. if the alternative is not a drop-in replacement, there will always be 
a reticence, by Java programmers, to that alternative compared to what 
Sun offers.  an example is our endeavor (GNU Classpath), to match the 
behavior of Sun's JDKs, incl. bugs!


cheers;
rsn


pgpLSm0rPacPC.pgp
Description: PGP signature

Re: jarsigner tool

[Roman Kennke]

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 --provider and/or --storetype
arguments. So my opinion is that we should have a jarsignder
implementation that uses this API and the same options but a different
default

/Roman

Am Donnerstag, den 23.03.2006, 12:47 +0100 schrieb Audrius Meskauskas:
> 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 
> implementing code.
> 
> >>
> >>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 do the reading from such a keystore* is available at 
> >>.
> >>
> >>i'd like a ruling on whether it's ok to import and use this code in GNU 
> >>Classpath. 
> >>TIA + cheers;
> >>rsn
> >>
> >
> >Unfortunately no.
> >  
> >
> (...)
> 
> >Cheers,
> >
> >Mark
> >  
> >
> 
> 

Re: jarsigner tool

[Raif S. Naffah]

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 jarsigner also does via the --provider and/or --storetype
> arguments. So my opinion is that we should have a jarsignder
> implementation that uses this API and the same options but a
> different default

my implementation does that.


cheers;
rsn


pgpYR2fKcofKj.pgp
Description: PGP signature

Re: jarsigner tool

[Casey Marshall]

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 specification available apart  
from the released piece of the implementing code.




That is, in fact, what the documentation comments for that class do,  
which are rendered here: .  
This is a simple, English description of the format, and I don't  
think (but, not-a-lawyer, yadda yadda) if someone were to use this to  
construct their own implementation, even if this description was  
obtained through reverse engineering.


I mean, as far as the *idea* of that format goes:

  - No-one can claim it's a trade secret, because Sun licenses the  
source to third parties.
  - No-one can make a copyright claim, because it's a simple English  
description of an algorithm, not Sun's code itself.

  - This format is unlikely to be patented.

So, if I reverse-engineer this format, then write a simple document  
describing the format and give that description to someone else, the  
question is how "tainted" that person is. I don't think here in the  
US this taints the other person much at all. Do any other  
jurisdictions (of which the present company is a resident) have  
lenient enough laws such that using this description to write a new  
implementation doesn't taint them?

Re: jarsigner tool

[Casey Marshall]

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 work with  
formats for that there is no other specification available apart  
from the released piece of the implementing code.




That is, in fact, what the documentation comments for that class  
do, which are rendered here: . This is a simple, English description of the format, and  
I don't think (but, not-a-lawyer, yadda yadda) if someone were to  
use this to construct their own implementation,


"they would not be tainted,"

:-P


even if this description was obtained through reverse engineering.

I mean, as far as the *idea* of that format goes:

  - No-one can claim it's a trade secret, because Sun licenses the  
source to third parties.
  - No-one can make a copyright claim, because it's a simple  
English description of an algorithm, not Sun's code itself.

  - This format is unlikely to be patented.

So, if I reverse-engineer this format, then write a simple document  
describing the format and give that description to someone else,  
the question is how "tainted" that person is. I don't think here in  
the US this taints the other person much at all. Do any other  
jurisdictions (of which the present company is a resident) have  
lenient enough laws such that using this description to write a new  
implementation doesn't taint them?

Re: jarsigner tool

[Mark Wielaard]

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.getInstance() method AFAICS. I think this is
> > what Sun's jarsigner also does via the --provider and/or --storetype
> > arguments. So my opinion is that we should have a jarsignder
> > implementation that uses this API and the same options but a
> > different default
> 
> my implementation does that.

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 will
send an email to FSF legal about using a (reimplementation) of the JKS
format.

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part

Re: jarsigner tool

[Mark Wielaard]

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.getDefaultType() does still return jks. This is actually
bug http://gcc.gnu.org/PR25673

> 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 conform to the
description given (see below) is OK. Now all we need is someone willing
to actually implement this and add it as a standard KeyStore format we
support.

Cheers,

Mark

The format of JKS files is, from the start of the file: 

 1. Magic bytes. This is a four-byte integer, in big-endian byte
order, equal to 0xFEEDFEED.
 2. The version number (probably), as a four-byte integer (all
multibyte integral types are in big-endian byte order). The
current version number (in modern distributions of the JDK) is
2.
 3. The number of entrires in this keystore, as a four-byte integer.
Call this value n
 4. Then, n times: 
 1. The entry type, a four-byte int. The value 1 denotes a
private key entry, and 2 denotes a trusted certificate.
 2. The entry's alias, formatted as strings such as those
written by DataOutput.writeUTF(String).
 3. An eight-byte integer, representing the entry's creation
date, in milliseconds since the epoch. 

Then, if the entry is a private key entry: 

 1. The size of the encoded key as a four-byte int,
then that number of bytes. The encoded key is
the DER encoded bytes of the
EncryptedPrivateKeyInfo structure (the
encryption algorithm is discussed later).
 2. A four-byte integer, followed by that many
encoded certificates, encoded as described in
the trusted certificates section.

Otherwise, the entry is a trusted certificate, which is
encoded as the name of the encoding algorithm (e.g.
X.509), encoded the same way as alias names. Then, a
four-byte integer representing the size of the encoded
certificate, then that many bytes representing the
encoded certificate (e.g. the DER bytes in the case of
X.509). 

 5. Then, the signature.

Decrypting the key works as follows: 

 1. The key length is the length of the ciphertext minus 40. The
encrypted key, ekey, is the middle bytes of the ciphertext.
 2. Take the first 20 bytes of the encrypted key as a seed value,
K[0].
 3. Compute K[1] ... K[n], where |K[i]| = 20, n = ceil(|ekey| / 20),
and K[i] = SHA-1(UTF-16BE(password) + K[i-1]).
 4. key = ekey ^ (K[1] + ... + K[n]).
 5. The last 20 bytes are the checksum, computed as H =
SHA-1(UTF-16BE(password) + key). If this value does not match
the last 20 bytes of the ciphertext, output FAIL. Otherwise,
output key.

The signature is defined as SHA-1(UTF-16BE(password) + US_ASCII("Mighty
Aphrodite") + encoded_keystore). 

(Above, SHA-1 denotes the secure hash algorithm, UTF-16BE the big-endian
byte representation of a UTF-16 string, and US_ASCII the ASCII byte
representation of the string.) 



signature.asc
Description: This is a digitally signed message part

keytool. was: jarsigner tool

[Raif S. Naffah]

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 conform to
> the description given (see below) is OK. Now all we need is someone
> willing to actually implement this and add it as a standard KeyStore
> format we support.

this is great news!

until a volunteer raises his/her hand and contribute the implementation, 
i'll start working on the keytool tool.


cheers;
rsn


pgpEjZwKoJ3Pq.pgp
Description: PGP signature

Re: keytool. was: jarsigner tool

[Casey Marshall]

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 aren't copyrightable, so any code we write to conform to
the description given (see below) is OK. Now all we need is someone
willing to actually implement this and add it as a standard KeyStore
format we support.


this is great news!

until a volunteer raises his/her hand and contribute the  
implementation,

i'll start working on the keytool tool.



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 helpful to start with that code  
instead of from scratch.

Re: keytool. was: jarsigner tool

[Raif S. Naffah]

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 helpful to start with that code
> instead of from scratch.

thanks.  i'll see what i can borrow from there.


cheers;
rsn


pgpiSdWOiLwgs.pgp
Description: PGP signature