Fwd: Re: [dss-x] HSM Proxy DSS profile

[Frank Cornelis]

FYI...

-------- Original Message --------

Subject:	Re: [dss-x] HSM Proxy DSS profile
Date:	Thu, 23 May 2013 09:50:29 +0200
From:	Cornelis Frank <Frank.C...@fedict.be>
To:	Andreas Kuehne <kue...@trustable.de>
CC:	ds...@lists.oasis-open.org <ds...@lists.oasis-open.org>

Hi Andreas,


On 05/21/2013 05:37 PM, Andreas Kuehne wrote:

Indeed, this Proxy HSM offers raw PKCS1 signature operations, but
using a centralized key management, whereas the idea behind Local Sig
Comp is that the client itself holds the signing token (e.g., a smart
card).

but from my point of view a HSM and a smart card is nearly the same. It
doesn't have a full DSS implementation but an interface to sign PKCS1
type signatures. And there are a bunch of private keys available for
signing, several thousands on a HSM, a few on a smart card.

Technically an HSM and a smart card are indeed quite similar. The big difference between the two is how they are used. Where an HSM sits behind the DSS service, the smart card sits 'in front' on the web browser. Interfacing with HSMs has been standardized at the API level via PKCS#11. As for smart card interfacing within a web browser context, the W3C Web Crypto API looks promising:
    http://www.w3.org/TR/WebCryptoAPI/
As indicated under "18. Key Discovery" there is still some work to be done in this area. It would be interesting if this API would provision key store discovery
functionality, maybe as an extension to their Crypto interface. We certainly have to keep an eye on what's going on in this working group.

They could go in different directions here. For example:
    keyStore = window.crypto.getKeyStore("MSCAPI");
And from here on you basically model something like the java.security.KeyStore:
    http://docs.oracle.com/javase/6/docs/api/java/security/KeyStore.html
The challenge here is to make this as platform independent as possible, and as 'pluggable' as possible while keeping in mind the effort already done to connect to smart card devices by means of the various existing PKCS#11 libraries. So, they could also do something like:
    keyStore = window.crypto.getKeyStore("PKCS11", "/path/to/p11.so", ...);
Of course, not every smart card device comes with PKCS#11 drivers, so an ordinary APDU interface would also be interesting. Here you would need to cover two aspects. One is an API similar to the Java Smart Card I/O API:
    http://docs.oracle.com/javase/6/docs/jre/api/security/smartcardio/spec/
The other part is the possibility to register new key store types from within Javascript itself:
    window.crypto.registerKeyStoreType("BeID",    
        myServiceProviderInterfaceImplementation);
so a web developer could do something like:
    <script type="text/javascript" src="beid.js"/>
    <script type="text/javascript">
        // and now simply start using the BeID key store type
        var keyStore = window.crypto.getKeyStore("BeID");
        var key = keyStore.getKey("Authentication");
        var signer = window.crypto.sign( algorithmSign, key);
        // ...
    </script>
where beid.js is some Javascript that registers a new BeID key store type with an implementation based on the (to be invented) Javascript Smart Card I/O API. Of course, this all comes with very interesting security issues like handling the smart card PIN code from within Javascript. So enough reasons for them to skip the key store discovery for a while...

I've read your feedback on the Local Sig Comp profile. Decomposing the
work would indeed make sense as I'm afraid that the current scope is
way too broad. No matter how the actual connection between the DSS and
the PKCS1 device has been implemented, the first problem that you need
to tackle (and that, from an interoperability point of view, actually
demands for standardization) is the protocol between the web
application and a DSS service over web browsers. Hence in my view the
first work package is constructing an OASIS DSS profile that defines
message level security as I already suggested in:

https://lists.oasis-open.org/archives/dss-x/201209/msg00028.html

Later on we could try to also detail on the actual DSS-PKCS1-device
protocol, but again, in my view this is merely a DSS service
implementation detail. I.e., similar to SAML where the actual
authentication mechanism is also completely out of scope as it is
business/technology specific and from an interop-point-of-view
actually doesn't matter at all.

What do you think about using DSS as the interface to the HSM, but
profiled down to just produce PKCS1? We can use the existing transport
security options ...

Well, this is exactly what I'm doing for the HSM Proxy product. Latest specs for this are available at:
    http://hsm-proxy.googlecode.com/files/hsm-proxy-ws-specs-0.3.0.pdf
Do you think it's worth it to turn this into an OASIS DSS-X profile?
Also, HSM usage involves much more than just key usage. For the key management we also already have the W3C XKMS2 specifications:
    http://www.w3.org/TR/xkms2/


Kind Regards,
Frank.