On 11/16/16, 8:55 AM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu@xxxxxxxxxxx on behalf of jmtapio@xxxxxxx> wrote:
On Wed, Nov 16, 2016 at 12:54:44PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> I find this approach very bad in general.
>
> PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication.
>
> SoftHSM misinterpreted this originally (older pkcs11 documents were less clear :), but they rectified this mistake. We should not repeat it.
I do agree that requiring authentication to access public keys is not
a very pleasant way to do PKCS11.
The point is not as much of being “not very pleasant”. The point is to avoid breaking it for everything and everybody else (like, forcing them to authenticate for public key operations – which would break all the existing scripts), for the sake of one screwed-up HSM device.
I am happy to listen to any alternative solutions
I’m OK with a hack to take care of one non-compliant device. I am not OK with having that hack as part of the mainstream code.
…given that we are unable to modify the HSM itself.
Are you so sure? Does SafeNet maybe have a firmware upgrade? Did your people talk to SafeNet, with PKCS#11 v2.40 document in hand? Perhaps they can be convinced…?
We solved the issue this way because we had a customer requirement to
support using Safenet Network HSM for some critical automated
connections. Unfortunately we have no way to influence how the HSM in
our case works as all we have to work with is a binary PKCS11 library
and a hardware box with closed source firmware.
Understood. But see above.
Btw as a response to other comments, the justification for using an
environment variable to point to a pin code file instead of
environment variable with a pin code is that there is a risk that
runtime environment might be inadvertently leaked in some debug
outputs or verification scripts.
Yes, very valid concern and approach. As I said, *my* concern is avoiding the need to provide a PIN for non-private keys and certs.
The main justification for the customer organization to use a network
HSM instead of local passwordless private keys is to prevent the key
from leaking.
This cannot be argued with. I’m doing something similar.
I believe this is a somewhat rare case but we feel it might be useful
to people other than us. Oh and we do appreciate the feedback.
The question is how to accommodate your needs without breaking it for everybody else. This is my main concern/objection.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
