I’m not sure I understand yet the issue that is being addressed with this work.
Certainly many JOSE libraries already support HSMs. We have customers using HSMs with our JOSE library via PKCS#11. But most of our use-cases typically only ever publish public keys as JWKs. You can already encode an identifier for a local private key using the key id (kid) header, so it’s not clear to me why you would need anything else if no actual key material is being transported. So what are the actual use-cases that need to be solved? Presumably some sort of communication between two parties that share access to the same HSM? — Neil > On 26 Feb 2019, at 23:29, Stefan Berger <[email protected]> wrote: > > Nathaniel McCallum <[email protected]> wrote on 11/01/2018 07:07:55 PM: > > > > > https://tools.ietf.org/html/draft-mccallum-jose-pkcs11-jwk-00 > > > > I plan to update this in the upcoming months and publish it as an > > independent draft. Likewise, we are implementing it here: > > > > https://github.com/latchset/jose > > > > Your contributions are welcome! > > > > RFC 7516 A.4.1 shows examples for encrypting the CEK with an RSA key and an > AES key: > > {"alg":"RSA1_5","kid":"2011-04-29"} > > and > > {"alg":"A128KW","kid":"7"} > > https://tools.ietf.org/html/rfc7516#appendix-A..4.1 > > > Would one add a p11 field for pkcs11 support in this case? Would kid still > have a meaning here? Or could one encode the pkcs11 URI in the kid field? > Similarly, one could come up with a kmip URI (missing any standard for it) > and put that into the kid, like this : "kid": "kmip:uuid=<uuid>".. An > implementation would have to have some sort of configuration file to look up > the credentials to access the server where the key with that UUID is located. > > Stefan > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
