Hi Eric,
we're currently implementing an open-source JOSE library and are looking for
possible use cases. Therefore I am quite interested in yours and want to
understand it better.
My current understanding is that you want to use a JWE to protect the HMAC key
during transmission (from Mastercard to your partner). The HMAC key would be
the payload of the JWE. For the use in a JWE, the format of the payload isn't
relevant since it is handled as bytes anyway. You can encode the HMAC key in
any format you like (including JWK or a more classic one like PEM/DER) as long
as the sending and the receiving site both understand the format.
However, for your concern the format doesn't matter. No matter how the key is
encoded, the information about the secret key is in there _somehow_ (for JWK,
it is in the k parameter). What I think you want is to export the HMAC key in
an encrypted form (the HSM performs the encryption before ever exposing
anything to the outside world) and only decrypt it _inside_ the HSM after it is
imported so the information is never exposed outside of a secure context (in
the RAM of some server for example). In this case, you're dependent on the HSM
to implement such a mechanism no matter the key format. If the HSMs you're
using were to implement this mechanism, I think JWE with an JWK as the payload
would be a feasible choice for the underlying format. But like you already
said, it requires support from the HSM manufacturers.
But depending on the support for Diffie-Hellman in the HSMs, you might be able
to use something different with JWK. Assuming you were able to exchange public
keys between Mastercard and your partner bank (you can use the X.509
certificate support in JWKs for this), you could simply perform a
Diffie-Hellman key exchange to generate a shared symmetric secret which you can
then use as the HMAC key. The exchanged public keys would use the JWK format in
this case.
I don't think there are any changes that could be made to the spec to better
support your use case. The spec does perfectly support your use case, the
problem is with the HSMs. An extension which defines how to communicate with
the HSMs to request an export/import of encrypted key material is probably more
what you want.
Does this help you?
--
Sincerely,
Erik Tesar
------- Original Message -------
On Tuesday, August 23rd, 2022 at 7:41 AM, Mike Jones
<[email protected]> wrote:
> Permit me to ask a clarifying question. You state that “the key itself to be
> in a clear-text format … is an explicit no-no” but surely that can’t be true
> of the public key, since, by definition, it’s public. Sure, that’s true of
> the private key.
>
> Are you trying to share the public key or also the private key? If the
> private key, then no matter what representation you use for it (JWK or
> other), you’ll have to protect to private key by other means – be it TLS
> encryption or other context-specific encryption.
>
> Best wishes,
>
> -- Mike
>
> From: Robins, Eric <[email protected]>
> Sent: Friday, August 19, 2022 9:40 AM
> To: [email protected]
> Cc: Devolder, Eric <[email protected]>; Mike Jones
> <[email protected]>
> Subject: RFC7517 (JWK) and potential changes for financial services
>
> You don't often get email from [email protected]. [Learn why this is
> important](https://aka.ms/LearnAboutSenderIdentification)
>
> Hi:
>
> As a financial services provider, Mastercard works frequently with applied
> cryptography, including the use of the JOSE patterns for identity credential
> management and message-level encryption and signing. Like many of our
> competitors and partners in this space, we make heavy use of hardware
> security modules (HSMs) and other such devices for the protection of
> cryptographic keys related to the signing and encryption of sensitive PII/PCI
> data.
>
> We recently ran across an interesting integration with one of our partner
> Issuing banks where we’ll need to share a sensitive key on a regular basis
> with them (an HMAC key in this case) that will be protected on both sides by
> HSMs. We’re looking at trying to standardize on a format for the sharing of
> that key and had considered the use of the JWK/JWE pattern but it appears
> that doing so requires the key itself to be in a clear-text format when
> written as the JWK (prior to being encrypted as a JWE). This is an explicit
> no-no for these types of keys, which never exist in such a format and are
> only recoverable as clear-text inside of the HSMs themselves.
>
> Thus, we’re at a bit of a crossroad here. We can’t – and our partners won’t
> either – export keys from our HSMs into a clear-text format prior to writing
> a JWK. Most HSM vendors don’t support exporting keys in a JWK/JWE format
> since they predate the JOSE standards, so we need to A>propose changes to the
> JWK standard, B>convince all major HSM manufacturers to support JOSE or C>not
> use JOSE.
>
> Would whoever manages this standard be open for a quick discussion for
> proposed changes to the RFC? Or, do you have recommendations as to how other
> financial services may be using this standard today? We’d love feedback here.
>
> Thanks in advance – looking forward to connecting…
>
> Eric Robins
>
> Corporate Security – Business Security Engineering/Architecture
>
> Mastercard
>
> 2200 Mastercard Blvd
>
> tel 636-722-7130
>
> CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for
> the use of the intended recipient and may contain information that is
> privileged, confidential or exempt from disclosure under applicable law. If
> you are not the intended recipient, any disclosure, distribution or other use
> of this e-mail message or attachments is prohibited. If you have received
> this e-mail message in error, please delete and notify the sender
> immediately. Thank you.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
