[cp-patches] FYI: Keyring fix

Casey Marshall csm at gnu.org
Thu May 4 02:02:49 UTC 2006

On May 3, 2006, at 6:16 PM, Raif S. Naffah wrote:

> hello Casey,
> On Thursday 04 May 2006 10:22, Casey Marshall wrote:
>> On May 3, 2006, at 3:09 PM, Raif S. Naffah wrote:
>>> On Thursday 04 May 2006 07:22, Casey Marshall wrote:
>>>> On May 3, 2006, at 5:33 AM, Raif S. Naffah wrote:
>>>>> the attached patch --already committed-- makes it possible to use
>>>>> the default keystore type and implementation to work with the
>>>>> keytool.
>>>> Is that really necessary? I was under the impression that you
>>>> usually need one keyring type or the other, depending on what you
>>>> are doing with it. When does `keytool' need both?
>>> i'm afraid it is.  consider the case where you first run the
>>> keytool with a -genkey command followed by an -import command of a
>>> trusted certificate; both with no -keystore option (to use a
>>> default .keystore file).  with the 1st command the .keystore is
>>> created as a private keyring. it will fail for the 2nd because it's
>>> expecting a public one.
>> But, it sounds like that equivalent to passing `-keystore
>> ~/.keystore' to both subcommands. I mean, it doesn't sound like
>> there's any technical limitation, just that a particular usage
>> pattern no longer works.
> using a -keystore option does not address the issue.  the problem is
> that the old implementation of the adapter was allowing certain  
> methods
> of the KeyStore interface on a private keyring, and others on the
> public one; throwing an exception if it is not of the right type.  to
> me this is a faulty implementation of the specs.

Well, the old implementation was following the way the GKR format was  
supposed to work: you can put your private keys and personal  
certificate chains in one file, and your trusted certificates in  
another. This is the behavior I wanted out of the keyring format at  
the time: you shouldn't keep both kinds of credentials in the same  
file, so we don't support it. Other key and certificate storage  
formats do this.

I don't think the KeyStore spec requires that the implementation  
support every method, and nor should it, because not every format  
supports putting every kind of credential into the same keystore, and  
GKR is one of these.

`keytool <command> -keystore <file>' runs <command>, loading the  
keystore <file>. Your argument still sounds specious because you can  
use `-genkey -keystore private-keystore' then `-import -keystore  

I'm still not convinced that keytool or anything else requires a  
format that supports both private keys and trusted certs. I wouldn't  
be surprised if there were applications that did, however, since what  
Sun does often becomes the de facto standard, so I'm not totally  
against doing this concatenation thing, even if it does subvert the  
whole point of the usage field.

And better still would be a keyring implementation that had a usage  
GKR_PUBLIC_CREDENTIALS, so you really are storing everything in one  
keyring, not two keyrings glued together.

>> I'm not arguing against making that behavior (and being able to keep
>> public and private keys in one file) work, but I think you should
>> consider backwards compatibility.
> i think we should allow for such a construction since it seems to  
> be the
> only way of offering a correct implementation of the KeyStore
> interface.
> as for backward compatibility, this can be addressed by offering an
> additional command to the keytool that reads a single-type keyring, or
> a pair of differently located private and public keyrings, and  
> combines
> them into one file.  users can then use this command to migrate their
> data and start using the keytool for their command-line operations.

I don't see why adding a non-standard utility program to upgrade  
files makes more sense than supporting single and concatenated files  
in the code itself.

> it should not be hard to write and document this new command, but  
> do we
> have enough users out there to warrant this work?

Probably not, but we can still avoid this completely with a simple  
change to support single-private, single-public, OR private-followed- 
by-public. And, it makes it somewhat incompatible with the internal  
keyring API, where you can write out a public or private store with  
the internal API (one kind per file), but then not read it again with  
the KeyStore API.

You can accomplish this really easily by not throwing an exception in  
`loadPrivateKeyring' if the usage isn't a private keyring, and adding  
an EOF check in `loadPublicKeyring.' I'm interested in any argument  
for why you shouldn't do that.

And, bogus file formats have a way of sticking around (make, anyone?)  
so if you kludge around this, we will be stuck with it for a long,  
long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 478 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060503/7b04f4ca/PGP.pgp

More information about the Classpath-patches mailing list