Use signing key on HSM to sign assertions

[Ian Young]

> On 7 May 2018, at 15:19, Peter Schober <peter.schober at univie.ac.at> wrote:
> 
> * Cantor, Scott <cantor.2 at osu.edu> [2018-05-07 15:37]:
>> I believe xmlsectool has some tested support for using PKCS11 for
>> signing
> 
> That should work fine, IIRC. Rainer published some examples at
> https://github.com/identinetics/keymgmt/blob/master/install/tests/test_hsm_token.sh#L346
> 
> But maybe the IDP (and XmlSecTool, while we're at it) should grow
> support for the pyeleven "API"? https://github.com/IdentityPython/pyeleven


The way almost all Java applications (including OpenSAML, the IdP, the MDA and XMLSecTool) do cryptography is in in terms of cryptographic objects like PublicKey and KeyStore provided by the Java API. There's a provider mechanism allowing people to plug in specific implementations. Sometimes HSM vendors allow you to plug something in at this level. If someone wanted to write a Java provider that talked to pyeleven, we could probably use it (that's the whole point of this abstraction layer), but I think it's very unlikely that we'd ever write something like that ourselves. It's not a simple thing, as PKCS#11's idea of what tokens can do doesn't map trivially across to the Java primitives. (I still have the scars)

As Scott says, the _other_ problem going in at this level is that the business of configuring which providers to be used in which context isn't necessarily as fine-grained in OpenSAML and the IdP as they would have to be to allow "only replace the functionality which does the assertion signing". XMLSecTool and the MDA don't have this problem, the former because it's only ever doing one thing at a time and the second because each Stage is separately configured and it's easy to just use different factory beans to generate the credentials to use.

The main way Java applications talk to native PKCS#11 libraries (and HSM vendors often supply one of these as well) is through a built-in provider that implements a PKCS#11 bridge. Again, if pyeleven provides an actual native PKCS#11 library, all of our products could in principle talk to it through the bridge. Again, I think that absent some real use case people need us to support, we're very unlikely to write such a native library ourselves.

The third thing I think it's vanishingly likely we'd want to get into would be having the actual applications grow support for a separate cryptographic framework that wasn't mediated by the Java crypto API. We rely on things like Santuario for XML DSIG that would make those essentially rewrites.

Cheers,

   -- Ian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3854 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20180508/a8c7dacb/attachment.p7s>