Subject: [jose] A Unified Theory of JOSE Keys

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 13:42:53 -0500

I've posted some draft slides for my presentation on JOSE keys:
<http://ipv.sx/ietf86/jose-keys.pdf>
Some thoughts are below to get the discussion started early...

What I'm proposing here is that we re-factor JWK and JWA to address all of
the use cases we have for keys -- including public keys, wrapped/unwrapped
private/symmetric keys, and key attributes.  That is, instead of doing
wrapped symmetric keys in JWE, public keys in JWK, and the remainder
somewhere else, we should just do all key management in JWK.

This actually entails less work than you might imagine.  JWE provides us
with a wrapped symmetric key format, and Mike's recent draft provides an
unwrapped, JSON-based symmetric key format.  From these we can extrapolate
to wrapped private keys in a pretty straightforward fashion, and pick up
the ability to add attributes to keys as a bonus.  The slide deck
illustrates a proposed wrapping algorithm that would do this.

At the end of the slide deck, there's a proposal to edit JWK and JWA to add
key wrapping.  To make that a little more precise, I would imagine the
contents of the revised JWK draft to look something like the following
(omitting identical sections):
-----BEGIN-----
4.  JSON Web Key (JWK) Format
4.1.  "kty" (Key Type) Parameter
4.2.  "use" (Key Use) Parameter
4.3.  "alg" (Algorithm) Parameter
4.4.  "kid" (Key ID) Parameter
4.5.  "kat" (Wrapped Key Attributes) Parameter
4.6.  "wk" (Wrapped Key) Parameter
4.7.  "epk" (Ephemeral Public Key) Header Parameter
4.8.  "jku" (JWK Set URL) Header Parameter
4.9.  "jwk" (JSON Web Key) Header Parameter
4.10. "x5u" (X.509 URL) Header Parameter
4.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter
4.12. "x5c" (X.509 Certificate Chain) Header Parameter
4.13. "apu" (Agreement PartyUInfo) Header Parameter
4.14. "apv" (Agreement PartyVInfo) Header Parameter
5. Wrapped keys
5.1. Key Wrapping Procedure
5.2. Key Unwrapping Procedure
-----END-----
The revised JWA draft would just fold in the fields from
draft-jones-jose-json-private-and-symmetric-key, and add the obvious
encoding rules for RSA and EC keys.

Comments welcome!

Thanks,
--Richard

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 8 Mar 2013 19:42:25 +0000

Hi Richard,

As I read your note, you're proposing a special-purpose encryption format to use for keys.  I think it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.  Indeed, draft-miller-jose-jwe-protected-jwk already clearly describes using JWE to encrypt JWKs and it's straightforward.  No invention required.

I also think that you're wrong in saying that we don't have the capability to encrypt private keys.  The Miller draft can be used to encrypt both symmetric and private keys.

I also think that you're wrong in saying that we don't have the capability to have attributes for keys.  The JWK format allows fields to be added for additional key attributes, as needed.

Let's keep things simple and use the general-purpose encryption format we already have, rather than inventing a special-purpose one.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, March 8, 2013 10:43 AM
To: [email-masked]
Subject: [jose] A Unified Theory of JOSE Keys

What I'm proposing here is that we re-factor JWK and JWA to address all of the use cases we have for keys -- including public keys, wrapped/unwrapped private/symmetric keys, and key attributes.  That is, instead of doing wrapped symmetric keys in JWE, public keys in JWK, and the remainder somewhere else, we should just do all key management in JWK.

This actually entails less work than you might imagine.  JWE provides us with a wrapped symmetric key format, and Mike's recent draft provides an unwrapped, JSON-based symmetric key format.  From these we can extrapolate to wrapped private keys in a pretty straightforward fashion, and pick up the ability to add attributes to keys as a bonus.  The slide deck illustrates a proposed wrapping algorithm that would do this.

At the end of the slide deck, there's a proposal to edit JWK and JWA to add key wrapping.  To make that a little more precise, I would imagine the contents of the revised JWK draft to look something like the following (omitting identical sections):
-----END-----
The revised JWA draft would just fold in the fields from draft-jones-jose-json-private-and-symmetric-key, and add the obvious encoding rules for RSA and EC keys.

Comments welcome!

Thanks,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 14:58:41 -0500

Hi Tony,

On Fri, Mar 8, 2013 at 2:42 PM, Anthony Nadalin <[email-masked]>wrote:

>  Hi Richard,****
>
> ** **
>
> As I read your note, you’re proposing a special-purpose encryption format
> to use for keys.  I think it would be simpler to use the general-purpose
> encryption format we already have (JWE) to encrypt keys.  Indeed,
> draft-miller-jose-jwe-protected-jwk already clearly describes using JWE to
> encrypt JWKs and it’s straightforward.  No invention required.****
>
>
I'm not proposing anything new here.  The key wrapping is already in JWE.
 I'm just extending it to other than symmetric keys.  And, for what it's
worth, the same key wrapping techniques are used in CMS.

> **
>
> I also think that you’re wrong in saying that we don’t have the capability
> to encrypt private keys.  The Miller draft can be used to encrypt both
> symmetric and private keys.
>

The Miller draft invents a *second* way of encrypting keys, in addition to
what JWE already has.  It's also much more inefficient, since you end up
doing two encryptions (JWE CMK, then key encryption) when you could be
doing one.

The Miller draft *is* a valuable contribution, though, because it adds PBE,
a notable omission from JWE.  That part should be folded into JWE or JWK,
wherever the key wrapping ends up.

> I also think that you’re wrong in saying that we don’t have the capability
> to have attributes for keys.  The JWK format allows fields to be added for
> additional key attributes, as needed.
>

We don't have a way to cryptographically bind attributes to keys.  JWK can
express the attributes, but it can't prevent them being changed by en route.

Let’s keep things simple and use the general-purpose encryption format we
> already have, rather than inventing a special-purpose one.
>

I agree that we should keep things simple.  This proposal is trying to keep
the number of ways we have to encrypt keys to one, instead of adding a new
way.

Thanks,
--Richard

>
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Friday, March 8, 2013 10:43 AM
> *To:* [email-masked]
> *Subject:* [jose] A Unified Theory of JOSE Keys****
>
> ** **
>
> I've posted some draft slides for my presentation on JOSE keys:****
>
> <http://ipv.sx/ietf86/jose-keys.pdf>****
>
> Some thoughts are below to get the discussion started early...****
>
> ** **
>
> somewhere else, we should just do all key management in JWK.****
>
> ** **
>
> illustrates a proposed wrapping algorithm that would do this.****
>
> ** **
>
> At the end of the slide deck, there's a proposal to edit JWK and JWA to
> add key wrapping.  To make that a little more precise, I would imagine the
> (omitting identical sections):****
>
> -----BEGIN-----****
>
> 4.  JSON Web Key (JWK) Format****
>
> 4.1.  "kty" (Key Type) Parameter****
>
> 4.2.  "use" (Key Use) Parameter****
>
> 4.3.  "alg" (Algorithm) Parameter****
>
> 4.4.  "kid" (Key ID) Parameter****
>
> 4.5.  "kat" (Wrapped Key Attributes) Parameter****
>
> 4.6.  "wk" (Wrapped Key) Parameter****
>
> 4.7.  "epk" (Ephemeral Public Key) Header Parameter****
>
> 4.8.  "jku" (JWK Set URL) Header Parameter****
>
> 4.9.  "jwk" (JSON Web Key) Header Parameter****
>
> 4.10. "x5u" (X.509 URL) Header Parameter****
>
> 4.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter****
>
> 4.12. "x5c" (X.509 Certificate Chain) Header Parameter****
>
> 4.13. "apu" (Agreement PartyUInfo) Header Parameter****
>
> 4.14. "apv" (Agreement PartyVInfo) Header Parameter****
>
> 5. Wrapped keys****
>
> 5.1. Key Wrapping Procedure****
>
> 5.2. Key Unwrapping Procedure****
>
> -----END-----****
>
> encoding rules for RSA and EC keys.****
>
> ** **
>
> Comments welcome!****
>
> ** **
>
> Thanks,****
>
> --Richard****
>
> ** **
>
> ** **
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Stephen Kent <[email-masked]>
Date: Sun, 10 Mar 2013 10:39:46 -0400

Anthony,

> Hi Richard,
>
> As I read your note, you're proposing a special-purpose encryption 
> format to use for keys.  I think it would be simpler to use the 
> general-purpose encryption format we already have (JWE) to encrypt 
> keys.  Indeed, draft-miller-jose-jwe-protected-jwk already clearly 
> describes
>

Without looking at the details of what is defined now, let me observe 
that it is generally considered to
be a bad idea to use the same mechanism to encrypt keys and data. 
Because one wants to prevent
inadvertent exposure of keys, we usually employ a different mechanism to 
encrypt them, and we mark them
as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an 
implementation of the crypto
used to support JOSE, it probably will be necessary to adhere to such 
conventions.

Steve

---

From: Leif Johansson <[email-masked]>
Date: Sun, 10 Mar 2013 16:06:27 +0100

On 03/10/2013 03:39 PM, Stephen Kent wrote:
> inadvertent exposure of keys, we usually employ a different mechanism
> to encrypt them, and we mark them
> as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for
> an implementation of the crypto
Interesting. Would you say that is a convention applied by FIPS 140 labs
or is that somewhere
in the FIPS specs?

        Cheers Leif

---

From: Stephen Kent <[email-masked]>
Date: Sun, 10 Mar 2013 11:29:18 -0400

Leif,

I fear my choice of words was poor, re "convention." NIST Special Pub 
800-38E defines key wrap
modes for AES (and tripe DES). FIPS 140-2, section 4.7.4, says (with 
regard to key entry):

*All encrypted secret and private keys, entered into or output from a 
cryptographic module and used in an Approved mode of operation, shall be 
encrypted using an Approved algorithm. *

** FIPS 140- So, combining these two NIST specs, one can infer that keys 
entered into a module, electronically, should be wrapped, not just 
encrypted as data.

Steve
> Interesting. Would you say that is a convention applied by FIPS 140 
> labs or is that somewhere
> in the FIPS specs?
>
>         Cheers Leif
>
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 10 Mar 2013 15:29:34 +0000

I'll note that in JSON Web Encryption, we are already using standard methods for encrypting key values for the Content Master Key - specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement).

What we're talking about here, however, is encrypting potentially more than just key values - in this case, key values with associated key use information, algorithm information, key ID information, and potentially other attributes.  As such, using the JWK JSON representation of this information as the payload of a standard JWE encryption seems like the obvious solution, which doesn't require inventing anything we don't already have.

draft-miller-jose-jwe-protected-jwk already describes doing that.  I believe that we should adopt this as a working group document as soon as the rechartering is complete.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Sunday, March 10, 2013 8:06 AM
To: [email-masked]
Subject: Re: [jose] A Unified Theory of JOSE Keys

Hi Richard,

As I read your note, you're proposing a special-purpose encryption format to use for keys.  I think it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.  Indeed, draft-miller-jose-jwe-protected-jwk already clearly describes

Without looking at the details of what is defined now, let me observe that it is generally considered to
be a bad idea to use the same mechanism to encrypt keys and data. Because one wants to prevent
inadvertent exposure of keys, we usually employ a different mechanism to encrypt them, and we mark them
as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an implementation of the crypto
used to support JOSE, it probably will be necessary to adhere to such conventions.
Interesting. Would you say that is a convention applied by FIPS 140 labs or is that somewhere
in the FIPS specs?

        Cheers Leif

---

From: Richard Barnes <[email-masked]>
Date: Sun, 10 Mar 2013 15:29:09 -0400

So it seems to me that the group has three questions to answer when it
comes to wrapped keys:

Q1(Encryption): What mechanism will be used to encrypt key material,
possibly containing attributes?
    Answer 1.A: JWE
    Answer 1.B: Key wrap, derived from JWE

Q2(Packing): How should the wrapped key+attributes be expressed?
    Answer 2.A: JSON format (not packed)
    Answer 2.B: JSON, with binary parts expressed directly

JWE-within-JWK represents answer 1.A / 2.A.  The solution proposed in my
Unified Theory is 1.B / 2.B.

For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys
-- We should not do things that would preclude accreditation under major
security standards (e.g., FIPS)
-- We should choose encodings that minimize the size overhead imposed by
the encoding
If we agree on these principles, then the answers to the above questions
seem pretty clear.

It seems to me that Steve's point on Question 1 pretty much decides the
question for B.  If we want systems using JOSE to have any hope of getting
accreditation (e.g., under FIPS), then they will have to use standard
mechanisms for protecting keys, even if those keys are  packaged with other
attributes.  Mike's message misses the point that the key wrap algorithm
isn't actually being used to protect the key itself -- for that you would
use a normal, content-oriented encryption algorithm, in contravention of
the FIPS requirements.

Question 2 is mostly a question of backward compatibility and efficiency.
 If we want to have any hope of being backward-compatible with JWE key
wrapping -- that is, avoiding having two ways to do the same thing -- then
we need a way to handle the octets of a key directly, as opposed to
base64-encoded within a JSON object.  That would be option 2.B.

There are also compactness arguments for 1.B and 2.B.  If you do 1.A, then
in addition to the header, you have to carry a separate CMK, IV, and MAC
value.  If you're using AES-GCM with a 128-bit key, that's a total of 44
octets (16 CMK, 16 MAC, 12 IV).  In contrast, if you just do AES key wrap,
the wrapping algorithm adds a maximum of 16 octets to the object.  The
difference in case 2 is even greater, because you're talking about
double-base64 encoding, which entails a penalty of 30% of the payload.  If
you're protecting an AES key, this might only be a few octets, but if
you're protecting a 2048-bit RSA key, then you're talking hundreds of
octets.  So if you care about compactness, 1.B and 2.B make a lot more
sense.

To respond to Mike's specific points:

 I’ll note that in JSON Web Encryption, we are already using standard
> methods for encrypting key values for the Content Master Key – specifically
> AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key
> agreement).
>

However, the actual key you're wrapping is still protected with a
content-oriented algorithm.  So you're still violating the FIPS
requirements.

What we’re talking about here, however, is encrypting potentially more than
> just key values – in this case, key values with associated key use
> information, algorithm information, key ID information, and potentially
> other attributes.  As such, using the JWK JSON representation of this
> information as the payload of a standard JWE encryption seems like the
> obvious solution, which doesn’t require inventing anything we don’t already
> have.
>

Absolutely agree that JSON is the right representation.  But the key is
still included in that representation, so you need to apply key wrapping
algorithms to it.  And, as discussed above, it's a lot more efficient if
you pack the JSON so that the binary isn't double-encoded.

> draft-miller-jose-jwe-protected-jwk already describes doing that.  I
> believe that we should adopt this as a working group document as soon as
> the rechartering is complete.
>

That draft has some excellent suggestions for password-based key wrapping.
 We should incorporate that into whatever solution we come up with.  But
for the reasons discussed above, it's wrong in using JWK for the
encapsulation.

I also disagree that we need a separate document for this.  If we're going
to avoid having two ways to wrap keys, this needs to be part of JWE/JWK.

--Richard

> ****
>                                                             -- Mike****
> Of *Leif Johansson
> *Sent:* Sunday, March 10, 2013 8:06 AM
> *To:* [email-masked]
> *Subject:* Re: [jose] A Unified Theory of JOSE Keys****
>
> ** **
>
> On 03/10/2013 03:39 PM, Stephen Kent wrote:****
>
> Anthony,****
>
> ** **
>
> Hi Richard,****
>
>  ****
>
> draft-miller-jose-jwe-protected-jwk already clearly describes****
>
>
> conventions.****
>         Cheers Leif****

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Mar 2013 13:30:29 +1100

“A Unified Theory of JOSE Keys” <http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.

It looks like a key is a JSON object with any number of name/value pairs. For some names, the value is a base64[url]-encoding of binary data.

To wrap a key, its name/value pairs are divided into 3 groups:

1.       non-confidential name/value pairs

2.       confidential non-binary name/value pairs

3.       confidential binary name/value pairs

The first group are put into the “kat” (key attributes?) field of the output.

The second group — if its not empty — becomes the first binary segment of the plaintext (as a UTF-8-encoded JSON object). “wj”:true in the output indicates the second group is present.

The third group (in order) become subsequent binary segments of the plaintext. The names in the third group (and their order) is determined by the type of the key being wrapped (“kty” attribute).

The plaintext is wrapped (encrypted), then base64url-encoded to give the “wk” attribute in the output.

Q1. The examples of wrapping an RSA key include “d”:… in “kat”. I assume this is a typo. “kat” would include “n” and “e”, but “d” (the private exponent) would always be encrypted and hence be inside “wk”.

Q2. Does key wrapping give integrity protection that you might want for name/value pairs even when they are not confidential. For instance, could it be useful to include, say, “e” inside “wk” instead of within “kat”? Do recipients need to check both the first binary segment and “kat” when looking for any attribute not explicitly listed in the “encoding rules”? Does the first binary segment take precedence over “kat”?

Q3. Should “kty” (key type) appear within “kat”? The examples show it as a top-level attribute instead.

A4. The symmetric key examples don’t include a key type (“kty”). Is it implied by something at a higher level (eg a JWE), or is there a default value meaning “a shared symmetric secret, with no specific associated crypto algorithm”?

Q5. Using a VARINT (variable-length integer) instead of 2 bytes would be better for encoding the length of binary segments. 2 bytes (64 KB max) might be too small, particularly if the binary encoding is used for all JOSE messages (eg JWE) not just keys.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Monday, 11 March 2013 6:29 AM
To: Mike Jones
Cc: Leif Johansson; [email-masked]
Subject: Re: [jose] A Unified Theory of JOSE Keys

So it seems to me that the group has three questions to answer when it comes to wrapped keys:

Q1(Encryption): What mechanism will be used to encrypt key material, possibly containing attributes?
    Answer 1.A: JWE
    Answer 1.B: Key wrap, derived from JWE

JWE-within-JWK represents answer 1.A / 2.A.  The solution proposed in my Unified Theory is 1.B / 2.B.

For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys
-- We should not do things that would preclude accreditation under major security standards (e.g., FIPS)
-- We should choose encodings that minimize the size overhead imposed by the encoding
If we agree on these principles, then the answers to the above questions seem pretty clear.

It seems to me that Steve's point on Question 1 pretty much decides the question for B.  If we want systems using JOSE to have any hope of getting accreditation (e.g., under FIPS), then they will have to use standard mechanisms for protecting keys, even if those keys are  packaged with other attributes.  Mike's message misses the point that the key wrap algorithm isn't actually being used to protect the key itself -- for that you would use a normal, content-oriented encryption algorithm, in contravention of the FIPS requirements.

Question 2 is mostly a question of backward compatibility and efficiency.  If we want to have any hope of being backward-compatible with JWE key wrapping -- that is, avoiding having two ways to do the same thing -- then we need a way to handle the octets of a key directly, as opposed to base64-encoded within a JSON object.  That would be option 2.B.

There are also compactness arguments for 1.B and 2.B.  If you do 1.A, then in addition to the header, you have to carry a separate CMK, IV, and MAC value.  If you're using AES-GCM with a 128-bit key, that's a total of 44 octets (16 CMK, 16 MAC, 12 IV).  In contrast, if you just do AES key wrap, the wrapping algorithm adds a maximum of 16 octets to the object.  The difference in case 2 is even greater, because you're talking about double-base64 encoding, which entails a penalty of 30% of the payload.  If you're protecting an AES key, this might only be a few octets, but if you're protecting a 2048-bit RSA key, then you're talking hundreds of octets.  So if you care about compactness, 1.B and 2.B make a lot more sense.

I’ll note that in JSON Web Encryption, we are already using standard methods for encrypting key values for the Content Master Key – specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement).

However, the actual key you're wrapping is still protected with a content-oriented algorithm.  So you're still violating the FIPS requirements.

What we’re talking about here, however, is encrypting potentially more than just key values – in this case, key values with associated key use information, algorithm information, key ID information, and potentially other attributes.  As such, using the JWK JSON representation of this information as the payload of a standard JWE encryption seems like the obvious solution, which doesn’t require inventing anything we don’t already have.

Absolutely agree that JSON is the right representation.  But the key is still included in that representation, so you need to apply key wrapping algorithms to it.  And, as discussed above, it's a lot more efficient if you pack the JSON so that the binary isn't double-encoded.

That draft has some excellent suggestions for password-based key wrapping.  We should incorporate that into whatever solution we come up with.  But for the reasons discussed above, it's wrong in using JWK for the encapsulation.

I also disagree that we need a separate document for this.  If we're going to avoid having two ways to wrap keys, this needs to be part of JWE/JWK.

--Richard

                                                            -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 00:58:57 -0400

Hi James,

Thanks for the excellent summary of this approach.  You said it much better
than I did.  Answers to your questions inline below.

On Mon, Mar 11, 2013 at 10:30 PM, Manger, James H <
[email-masked]> wrote:

> “A Unified Theory of JOSE Keys” <http://www.ipv.sx/ietf86/jose-keys.pdf>
> looks quite good.****
>
> ** **
>
> It looks like a key is a JSON object with any number of name/value pairs.
> For some names, the value is a base64[url]-encoding of binary data.****
>
> ** **
>
> To wrap a key, its name/value pairs are divided into 3 groups:****
>
> **1.       **non-confidential name/value pairs****
>
> **2.       **confidential non-binary name/value pairs****
>
> **3.       **confidential binary name/value pairs****
>
> ** **
>
> The first group are put into the “kat” (key attributes?) field of the
> output.****
>
> ** **
>
> The second group — if its not empty — becomes the first binary segment of
> the plaintext (as a UTF-8-encoded JSON object). “wj”:true in the output
> indicates the second group is present.****
>
> ** **
>
> The third group (in order) become subsequent binary segments of the
> plaintext. The names in the third group (and their order) is determined by
> the type of the key being wrapped (“kty” attribute).****
>
> ** **
>
> The plaintext is wrapped (encrypted), then base64url-encoded to give the
> “wk” attribute in the output.****
>
> ** **
>
> ** **
>
> Q1. The examples of wrapping an RSA key include “d”:… in “kat”. I assume
> this is a typo. “kat” would include “n” and “e”, but “d” (the private
> exponent) would always be encrypted and hence be inside “wk”.
>
>
Yes, that is a typo.  Fixed in my local copy.

> Q2. Does key wrapping give integrity protection that you might want for
> name/value pairs even when they are not confidential. For instance, could
> it be useful to include, say, “e” inside “wk” instead of within “kat”? Do
> recipients need to check both the first binary segment and “kat” when
> looking for any attribute not explicitly listed in the “encoding rules”?
> Does the first binary segment take precedence over “kat”?
>

This proposal does not allow for attributes that are integrity-protected
but not confidentiality-protected.  They get both services or neither.  Off
the top of my head, I can't think of a simple way to do this with standard
key-wrapping techniques.

You have correctly guessed my intent for decoding: I was thinking that the
recipient would first decode two dictionaries, the one from "kat", and the
one from "wk".  It would then merge them by inserting the fields from "wk"
into the "kat" object, overwriting if necessary.  So protected fields
("wk") would take precedence over unprotected fields ("kat").

> top-level attribute instead.

I'm a little split on this.  The point of "kty" is to indicate how the
recipient should reconstruct a JSON object out of the "wk" value.  As a
processing rule, it seems to make sense at the top level, but it also needs
to be added to the final unwrapped key object (like the fields in "kat").
 Note that there's no ambiguity about the type of the wrapped key, because
the presence of "alg" signifies that wrapping has been applied.  So I don't
think it matters much one way or the other.

> A4. The symmetric key examples don’t include a key type (“kty”). Is it
> implied by something at a higher level (eg a JWE), or is there a default
> value meaning “a shared symmetric secret, with no specific associated
> crypto algorithm”?
>

In the spirit of trying to produce JWE as a degenerate case, I was thinking
that an absent "kty" value would indicate a symmetric key.  This sort of
makes sense, given that the point of the "kty" in this case is to tell you
what the Encoding Rules are for "wk"; an absent "kty" basically means
there's no internal structure (modulo "wj"), which is the same as a
symmetric key would have.

Q5. Using a VARINT (variable-length integer) instead of 2 bytes would be
> better for encoding the length of binary segments. 2 bytes (64 KB max)
> might be too small, particularly if the binary encoding is used for all
> JOSE messages (eg JWE) not just keys.
>

That would be fine.  Pick your favorite binary integer format :)  I was
just trying to be simple for this initial proposal.

I would note that a fixed-length integer is easier to deal with in some
languages.  E.g., in JavaScript, you can write 1-, 2-, or 4-octet unsigned
integers using a DataView over an ArrayBuffer.  Maybe you could do
something really bad, like use the first bit of the first octet to indicate
whether the number is 2 or 4 bytes.

Cheers,
--Richard

> --****
> James Manger****
> *Sent:* Monday, 11 March 2013 6:29 AM
> *To:* Mike Jones
> *Cc:* Leif Johansson; [email-masked]
>
> comes to wrapped keys:****
>
> ** **
>
> possibly containing attributes?  ****
>
>     Answer 1.A: JWE****
>
>     Answer 1.B: Key wrap, derived from JWE****
>
> ** **
>
> Q2(Packing): How should the wrapped key+attributes be expressed?****
>
>     Answer 2.A: JSON format (not packed)****
>
>     Answer 2.B: JSON, with binary parts expressed directly ****
>
> ** **
>
> Unified Theory is 1.B / 2.B.  ****
>
> ** **
>
> For context, I'm working from a few principles here:****
>
> -- We should not define multiple ways to wrap symmetric keys****
>
> security standards (e.g., FIPS)****
>
> the encoding****
> seem pretty clear.****
> the FIPS requirements.****
>
> ** **
>
> base64-encoded within a JSON object.  That would be option 2.B.****
>
> ** **
>
> sense.****
> To respond to Mike's specific points:****
>
> ** **
>
> agreement).****
> requirements.****
> What we’re talking about here, however, is encrypting potentially more
> than just key values – in this case, key values with associated key use
> have.****
> you pack the JSON so that the binary isn't double-encoded.****
>
>   ****
>
> the rechartering is complete.****
>
> ** **
>
> encapsulation.****
> to avoid having two ways to wrap keys, this needs to be part of JWE/JWK.**
> **
>
> ** **
>
> --Richard****
>
> ** **
>
>                                                             -- Mike****
>
>

---

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 12 Mar 2013 18:43:10 +0000

Richard,

draft-ietf-jose-json-web-algorithms-08 defines A128KW and A256KW as using the RFC3394 AES Key Wrap.
When you use them here do you mean the RFC5649 AES Key Wrap with Padding since the plaintext is not guaranteed to be a multiple of 64 bits?

Are the examples in your slides all assuming an existing key wrapping key has been pre-established?
Should there also be examples showing how to asymmetrically encrypt keys?
Are the current JWE mechanisms used to get the key wrapping key to the recipient?
(I think I'm missing the big picture of where (if anywhere) this plugs into JWE?)

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, March 08, 2013 1:43 PM
To: [email-masked]
Subject: [jose] A Unified Theory of JOSE Keys

-----END-----

Comments welcome!

Thanks,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 15:07:55 -0400

Hi Mike,

> draft-ietf-jose-json-web-algorithms-08 defines A128KW and A256KW as using
> the RFC3394 AES Key Wrap.****
>
> When you use them here do you mean the RFC5649 AES Key Wrap with Padding
> since the plaintext is not guaranteed to be a multiple of 64 bits?
>

Yes. So that would impose 64 bits + [0,64] bits of size overhead.

> has been pre-established?

Yes, the examples in the slides assume an existing pre-shared KEK between
the sender and recipient.

> Should there also be examples showing how to asymmetrically encrypt keys?

Yes, once this gets turned into a draft.  (An examples document might be a
good milestone for this WG.)

> ****
>
> Are the current JWE mechanisms used to get the key wrapping key to the
> recipient?****
>
> (I think I’m missing the big picture of where (if anywhere) this plugs
> into JWE?)
>

No, I'm not positing how the pre-shared key was established.

The idea is that the first example slide ("The Wrapping Algorithm (symm)")
illustrates the current wrapping process for JWE.  On the left side is a
representation of a raw, unwrapped CMK.  On the right side is the wrapped
CMK, including two JWE header fields ("alg", "kid") and the content of the
CMK component of the JWE (in the "wk" field) -- basically, the a slice out
of a JWE.

As I suggested above, one of the goals is to produce a unified approach to
key protection.  That means we would need to have JWE key wrapping as a
special case of our more general algorithm.

--Richard

> Mike****
> *Sent:* Friday, March 08, 2013 1:43 PM
> *To:* [email-masked]

---

From: Mark Watson <[email-masked]>
Date: Tue, 12 Mar 2013 22:58:54 +0000

Richard,

Regarding the proposal for a binary-optimized JSON encoding, isn't this a bit orthogonal to the problem at hand ?

I understand that this is one area where such a thing would be useful, but there have been various attempts to define such things in the past (BSON, ubjson, …). A big advantage of JSON is that the data is self-describing, in terms of types: you don't need any external "document type definition" or "schema" to decode and manipulate a JSON object.

If you are going to specify something like this, I'd suggest at least include the member names that have been moved to the binary segment somewhere. So then a decoder can undo the translation and give back a regular JSON object with base64-encoded members, without access to this side-information.

But I would ask if this trouble is really worth it for the 25% space saving ?

…Mark

On Mar 11, 2013, at 7:30 PM, Manger, James H wrote:

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Monday, 11 March 2013 6:29 AM
To: Mike Jones
Cc: Leif Johansson; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] A Unified Theory of JOSE Keys

--Richard

                                                            -- Mike
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Wed, 13 Mar 2013 15:46:43 -0400

I would actually be completely ok with that -- if the wrapping in JWE were
consistent.  But I suspect some folks will balk at the ~65% size increase:

// 128-bit raw key
XXXXXXXXXXXXXXXX
 // Wrapped raw key
XXXXXXXXXXXXXXXXXXXXXXXX
// Base64 of wrapped raw key
Tt/CS0aWHHv9PaKsTQHTIxLt8f8DYP0a <------ Solution 2.B, 32 bytes
// JWK of key
{"k":"QEhAwEkOEtstCaEEd8sKig"}
// Wrapped JWK
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
// Base64 of wrapped JWK
+N9iVxLSMs8/wzuK42pd7PClztFxy+AwRTTyV8ZzSsIO2VIGPxOge <------ Solution 2.A,
53 bytes

On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson <[email-masked]> wrote:

>  Richard,
>
>  Regarding the proposal for a binary-optimized JSON encoding, isn't this
> a bit orthogonal to the problem at hand ?
>
>  I understand that this is one area where such a thing would be useful,
> but there have been various attempts to define such things in the past
> (BSON, ubjson, …). A big advantage of JSON is that the data is
> self-describing, in terms of types: you don't need any external "document
> type definition" or "schema" to decode and manipulate a JSON object.
>
>  If you are going to specify something like this, I'd suggest at least
> include the member names that have been moved to the binary segment
> somewhere. So then a decoder can undo the translation and give back a
> regular JSON object with base64-encoded members, without access to this
> side-information.
>
>  It looks like a key is a JSON object with any number of name/value
> pairs. For some names, the value is a base64[url]-encoding of binary data.
> ****
>  ** **
>  1.       non-confidential name/value pairs****
>  2.       confidential non-binary name/value pairs****
>  3.       confidential binary name/value pairs****
>  ** **
>  The second group — if its not empty — becomes the first binary segment
> of the plaintext (as a UTF-8-encoded JSON object). “wj”:true in the output
> exponent) would always be encrypted and hence be inside “wk”.****
>  ** **
> Does the first binary segment take precedence over “kat”?****
>  ** **
>  Q3. Should “kty” (key type) appear within “kat”? The examples show it as
> a top-level attribute instead.****
>  ** **
> crypto algorithm”?****
> JOSE messages (eg JWE) not just keys.****
>  ** **
>  ** **
>  --****
>  James Manger****
>  ** **
>   JWE-within-JWK represents answer 1.A / 2.A.  The solution proposed in
> my Unified Theory is 1.B / 2.B.  ****
>   ** **
>   -- We should not do things that would preclude accreditation under
> major security standards (e.g., FIPS)****
>   -- We should choose encodings that minimize the size overhead imposed
> by the encoding****
>   If we agree on these principles, then the answers to the above
> questions seem pretty clear.****
>   ** **
>   Question 2 is mostly a question of backward compatibility and
> efficiency.  If we want to have any hope of being backward-compatible with
> JWE key wrapping -- that is, avoiding having two ways to do the same thing
> -- then we need a way to handle the octets of a key directly, as opposed to
>   There are also compactness arguments for 1.B and 2.B.  If you do 1.A,
> then in addition to the header, you have to carry a separate CMK, IV, and
> MAC value.  If you're using AES-GCM with a 128-bit key, that's a total of
> 44 octets (16 CMK, 16 MAC, 12 IV).  In contrast, if you just do AES key
> wrap, the wrapping algorithm adds a maximum of 16 octets to the object.
>  The difference in case 2 is even greater, because you're talking about
>   That draft has some excellent suggestions for password-based key
> wrapping.  We should incorporate that into whatever solution we come up
> with.  But for the reasons discussed above, it's wrong in using JWK for the
> encapsulation.****
>   ** **
>   I also disagree that we need a separate document for this.  If we're
> going to avoid having two ways to wrap keys, this needs to be part of
> JWE/JWK.****
>   ** **
>   --Richard****
>   ** **
>
>                                                               -- Mike****
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 13 Mar 2013 16:05:11 -0400

One other thing to note is that we're effectively *already* *defining* a
binary-optimized JSON in the definition of JWS and JWE.  Consider the
following JSON structure:

{
    "alg": "A128KW",
    "enc": "A128GCM",
    "kid": "ceci",
    "key": "...",
    "iv": "...",
    "ciphertext": "...",
    "mac": "..."
}

If you apply the algorithm in the slides, with the encoding rules ["key",
"iv", "ciphertext", "mac"], and with base64 instead of length/value
encoding, then you get a well-formed JWE.

My proposal is just to do the same thing, but to concatenate the parts in
binary rather than text.

---

From: Mark Watson <[email-masked]>
Date: Wed, 13 Mar 2013 20:11:23 +0000

On Mar 13, 2013, at 12:46 PM, Richard Barnes wrote:

I would actually be completely ok with that -- if the wrapping in JWE were consistent.  But I suspect some folks will balk at the ~65% size increase:]

IIUC, what you mean by consistent is that JOSE should define a single key wrapping algorithm, and that this should be used to create the "wk" for JWE as well as being used 'stand-alone' for other key wrapping applications. This algorithm would have the following inputs and outputs:

Inputs
- Type of key to be wrapped
- Key to be wrapped
- Key attributes (optional, possibly split into protected and unprotected)
- Type of Key Encryption Key (AES or RSA)
- Key Encryption Key

Output:
- Wrapped key data (binary data)
- Key attributes (optional, unprotected ones)

Your proposal (roughly, assuming you want it to fall back to exactly what is in JWE for the wrapped CMK case)
(1) Construct a JWK of the key to be wrapped, including any attributes, but excluding fields known to be binary according to the key type
(2) If the resulting JWK is empty and there is only only binary field for the key
- the data to be wrapped is that single binary field
Otherwise
- prepend the JWK with a length field
- prepend each binary field from the key with a length field
- the data to be wrapped is the concatenation of the above
(3) Apply the key wrapping algorithm to the data to be wrapped, using the Key Encryption Key

This could be modified as follows:
(1) Construct a JWK of the key to be wrapped, including any attributes
(2) If the resulting JWK contains a single binary field
- the data to be wrapped is that single binary field
Otherwise
- the data to be wrapped is the JWK object
(3) Apply the key wrapping algorithm to the data to be wrapped, using the Key Encryption Key

I don't see that one is more "consistent" than the other: both have a great big "IF" in step 2 that calls out the simple symmetric key case.

…Mark

// 128-bit raw key
XXXXXXXXXXXXXXXX
 // Wrapped raw key
XXXXXXXXXXXXXXXXXXXXXXXX
+N9iVxLSMs8/wzuK42pd7PClztFxy+AwRTTyV8ZzSsIO2VIGPxOge <------ Solution 2.A, 53 bytes

On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson <[email-masked]<mailto:[email-masked]>> wrote:
Richard,

…Mark

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Monday, 11 March 2013 6:29 AM
To: Mike Jones
Cc: Leif Johansson; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] A Unified Theory of JOSE Keys

--Richard

                                                            -- Mike

jose mailing list

---

From: Richard Barnes <[email-masked]>
Date: Wed, 13 Mar 2013 16:19:13 -0400

I might be able to live with that compromise.  It might take a little
thinking to say precisely what that "IF" statement is conditioned on, but I
think it's doable.  I'm going to set about writing a draft for this Real
Soon Now, in which I'll try to elaborate a solution along these lines.

--Richard

On Wed, Mar 13, 2013 at 4:11 PM, Mark Watson <[email-masked]> wrote:

> consistent.  But I suspect some folks will balk at the ~65% size increase:]
>
>
>  IIUC, what you mean by consistent is that JOSE should define a single
> key wrapping algorithm, and that this should be used to create the "wk" for
> JWE as well as being used 'stand-alone' for other key wrapping
> applications. This algorithm would have the following inputs and outputs:
>
>  Inputs
> (1) Construct a JWK of the key to be wrapped, including any attributes,
> but excluding fields known to be binary according to the key type
>  I don't see that one is more "consistent" than the other: both have a
> great big "IF" in step 2 that calls out the simple symmetric key case.
>
>  …Mark
>
>
>  // 128-bit raw key
> XXXXXXXXXXXXXXXX
>  // Wrapped raw key
> XXXXXXXXXXXXXXXXXXXXXXXX
>>     “A Unified Theory of JOSE Keys” <
>> http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.****
>>  ** **
>>  The plaintext is wrapped (encrypted), then base64url-encoded to give
>> the “wk” attribute in the output.****
>>  ** **
>>  ** **
>>  Q1. The examples of wrapping an RSA key include “d”:… in “kat”. I
>> assume this is a typo. “kat” would include “n” and “e”, but “d” (the
>> private exponent) would always be encrypted and hence be inside “wk”.****
>>  ** **
>>  Q3. Should “kty” (key type) appear within “kat”? The examples show it
>> as a top-level attribute instead.****
>>  ** **
>>  Q5. Using a VARINT (variable-length integer) instead of 2 bytes would
>> be better for encoding the length of binary segments. 2 bytes (64 KB max)
>>   *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Richard Barnes
>>   It seems to me that Steve's point on Question 1 pretty much decides
>> the question for B.  If we want systems using JOSE to have any hope of
>> getting accreditation (e.g., under FIPS), then they will have to use
>> standard mechanisms for protecting keys, even if those keys are  packaged
>> with other attributes.  Mike's message misses the point that the key wrap
>> algorithm isn't actually being used to protect the key itself -- for that
>> you would use a normal, content-oriented encryption algorithm, in
>> contravention of the FIPS requirements.****
>>   ** **
>>   Absolutely agree that JSON is the right representation.  But the key
>> is still included in that representation, so you need to apply key wrapping