Re: javakey -ic

Marianne Mueller (mrm@Eng)
Wed, 22 Jan 1997 22:31:07 -0800

Date: Wed, 22 Jan 1997 22:31:07 -0800
Message-Id: <199701230631.WAA01417@puffin.eng.sun.com>
From: Marianne Mueller <mrm@Eng>
To: Ulrich.Kriegel@isst.fhg.de
Subject: Re: javakey -ic

Hi,

We know that you can't create an identity unless you also declare it
to be trusted/untrusted. But, you can create an identity when you
declare it to be trusted -- I know that, semantically, this doesn't
make a lot of sense, but you can use this as a workaround while we
attend to the bugs.

% javakey -c mrm true

You can't create keyparis for non-signers, but, you can import
certificates that belong to non-signers.

I don't understand your concern here:

> what about my question on accessing certificates or public keys of
> objects stored in identitydb.obj. I cannot understand why one should
> generate key-pairs temporarely in programs if one could access the
> information one already has in the identitydb.obj. Maybe, I didn't
> catch the concept of having different mechanisms for signing jar-Files
> and streamed data.

There are reasons to import certificates and just use them for
verification -- that's the end-user perspective. then, there might
be developers who want to design and implement their own top-level
tools for handling keys and certificates. Those people might want
to use the signature APIs directly. But these are really two
different sets of end-users.

The whole key management/certificate management issue will broaden
over 1997, as we provide more tools and more APIs for the PKI
space. (PKI meaning Public Key Infrastructure)

Marianne

p.s. Pardon me for cc'ing java-security@java.sun.com. This is read
only by members of the JavaSoft security group. My reason for
cc'ing mail to this alias is that soon, I hope to set up an online
internet archive of Q&A sent&answered to the java-security email
alias.

> X-ENV: (mailgw1.fhg.de) Ulrich.Kriegel@isst.fhg.de -> mrm@Eng.Sun.com.VIA-SMTP
> Date: Thu, 23 Jan 1997 07:22:41 +0100
> From: Ulrich Kriegel <Ulrich.Kriegel@isst.fhg.de>
>
> Hi Marianne,
> there is another bug in javakey- an identity can only be created if
> the trusted-argument is supplied, otherwise one gets the following
> message:
>
> wzh:otter:~|8> javakey -c wzhfun
> legal options for create:
> no arguments <name> {trusted} create a new identity.
> s <name> {trusted} create a new signer.
>
> illegal arguments to create
>
> In JDK/1/1/beta3 it is impossible to generate key-pair for non-signers
>
> wzh:otter:~|22> rm identitydb.obj
> wzh:otter:~|23> javakey -c wzhfun true
> Operation successful
> wzh:otter:~|24> javakey -l
>
> Scope: sun.security.IdentityDatabase, source file: /home/otter/wzhfun/identitydb.obj
>
> wzhfun[identitydb.obj][trusted]
> wzh:otter:~|25> javakey -gk wzhfun DSA 1024 wzhfun_pub wzhfun_priv
> java.lang.ClassCastException: sun.security.provider.SystemIdentity
> at sun.security.provider.Main.generateCmd(Main.java:665)
> at sun.security.provider.Main.run(Main.java:1313)
> at sun.security.provider.Main.main(Main.java:1341)
> wzh:otter:~|26>
>
> So I could not try to import a certificate from a non-signer.
> But Marianne,
> what baout my question on accessing certificates or public keys of
> objectst stored in identitydb.obj. I cannot understand why one should
> generate key-pairs temporarely in programs if one could access the
> information one already has in the identitydb.obj. My be, I didn't
> catch the concept of having different mechanisms for signing jar-Files
> and streamed data. So it would be very helpful for me to get a hint
> what is wrong with my understanding.
>
> Yours
> -- ulrich
> ---------------------------------------------------------------------
> Dr. E.Ulrich Kriegel, ulrich.kriegel@isst.fhg.de, (++49 30) 20224-846
> Fraunhofer Institute for Software Engineering and Systems Engineering
> (FhG ISST), Kurstrasse 33, D-10117 Berlin, FRG
> fax: (++49 30) 20224-858 (or 799).
> For public key either send mail with subject ##public-key or look at
> http://www.isst.fhg.de/~ukriegel/public-key.html
> =====================================================================
>