[cp-patches] FYI: Keyring fix
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
>>>> 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
> 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
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.
> 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
> 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
> 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,
-------------- next part --------------
A non-text attachment was scrubbed...
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