Re: [cp-patches] FYI: Keyring fix

[Casey Marshall]

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

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.

that the old implementation of the adapter was allowing certain methods

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 public-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 field of GKR_CERTIFICATES | GKR_PRIVATE_KEYS | 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.

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

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 think we should allow for such a construction since it seems to be the a pair of differently located private and public keyrings, and combines

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.

PGP.sig
Description: This is a digitally signed message part