Message-Id: <199905201709.KAA12748@laguna.eng.sun.com>
Date: Thu, 20 May 1999 10:09:07 -0700 (PDT)
From: Jan Luehe <luehe@laguna.eng.sun.com>
Subject: Re: Decrypting PKCS8 private keys
To: dtaylor@forge.com.au
David:
> Good point about not knowing what KeyFactory to ask for when you have
> encrypted PKCS8 key specs.
>
> The way I'd figured doing it was to have a class that knew about encrypted
> PKCS8 things, decrypted them, checked the alg and created an appropriate
> key factory before passing the decrypted spec in and returning a private
> key.
>
> I bring it up because, again, there is no standard way to do this. PKCS8 is
> pretty common, so I don't think it out of place for the encrypted things to
> get a mention and even a "right way to handle them" in the spec.
>
> Some providers have private (as in not JCE) classes to do this, some don't
> do it at all. My extra class should insulate my code from this, but then
> everyone has to do it.
A KeyFactory that was able to handle encrypted keys should
be able to determine the algorithm under which a key is
encrypted, instantiate a Cipher object for that (encryption) algorithm,
decrypt the key, determine the key algorithm, instantiate
a KeyFactory for that (key) algorithm, and parse the key
data into a Key object.
It would be great if we could have provided that functionality
in the JDK. However, the JDK knows nothing about the Cipher class,
which is defined in the JCE (because we want the JDK to be
generally exportable).
So we could have provided that functionality in the JCE.
But then you would still have needed those provider-specific extra
classes in the JDK.
Jan