Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

From: "Jim Schaad" <[email-masked]>
Date: Sun, 12 Aug 2012 11:56:02 -0700

> -----Original Message-----
> From: Harry Halpin [mailto:[email-masked]]
> Sent: Sunday, August 12, 2012 8:03 AM
> To: Jim Schaad; Karen O'Donoghue; [email-masked]; Michael
Jones
> Subject: JOSE WG request from W3C WebCrypto API
> 
> [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]
> 
> JOSE Chairs,
> 
> The Web Cryptography Working group has noted that the API requires some
> access to raw key material, and the issue of whether or not to use JWK or
> ASN.1 as the default format came up. Two issues have come out that we'd
> like to know the answer to:
> 
> 1) JWK does not define a private key format. Does the JOSE WG plan to
> support a JOSE-format for private keys? If so, when? Or 'maybe'?

The working group policy is that there will be no private key format defined
for JWK.  This issue has been explicitly discussed by the working group and
there are no plans to change that going forward.

> 
>   2) While we'd like encourage the use of JOSE over ASN.1, it seems like
for
> backwards compatibility having some level of ASN.1 support would be useful
> and we *need* a format that allows key material (both private and
> public) to be exported. Folks seem to leaning towards ASN.1 as a default
> format in the low-level API, and having JWK as a format that can be built
on
> top of that in a possible high-level API. Would that be OK?

It would probably be preferable to be able to import/export private key
material as ASN.1.  But to allow for the import/export of public key
material in either the ASN.1 or JOSE format.  This would simplify the
implementation efforts for JOSE developers.  

I don't believe that it would be good to have systems that use JOSE to need
to download script that did the ASN.1 to JOSE conversions.  If you supported
the ASN.1 blob at the SubjectPublicKeyInfo structure level, then an
independent function could be placed in systems to do the conversion between
the two formats.  If you make it a high-level API, I would be worried about
the support level provided by browsers.

> 
>   3) How stable do you believe the JOSE formats are right now? Do you
think
> they are stable enough now we can reference them in our API draft at end
of
> August? If not, when?  The W3C would like to and plan to use these formats
> where possible.

There are currently no open issues for discussion on the formats for
asymmetric key formats; however there are some questions about the set of
algorithms and key sizes for symmetric keys.  While I have no reason to
believe that there will be a change in the key formats, I cannot promise
that there will not be one.

Jim Schaad
Jose WG Chair

> 
> Feel free to forward this by JOSE WG for discussion. We'd like an answer
> before we send our document to FPWD at end of August.
> 
>   cheers,
>       harry

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Aug 2012 19:30:00 +0300

>> top of that in a possible high-level API. Would that be OK?

This is really interesting!

The entire work on JSON signing and encryption was started since the Web and browser guys told us that there no way they would ever want to use ASN.1. Completely impossible - not compatible with the way how Web applications are developed these days, and so on. 

Now, they ask for ASN.1 support.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 13 Aug 2012 12:47:00 -0700

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, August 13, 2012 9:30 AM
> To: Jim Schaad
> Cc: Hannes Tschofenig; 'Harry Halpin'; [email-masked]
> Subject: Re: [jose] JOSE WG request from W3C WebCrypto API
> 
> 
> >> backwards compatibility having some level of ASN.1 support would be
> >> useful and we *need* a format that allows key material (both private
> >> and
> >> public) to be exported. Folks seem to leaning towards ASN.1 as a
> >> default format in the low-level API, and having JWK as a format that
> >> can be built
> > on
> The entire work on JSON signing and encryption was started since the Web
> and browser guys told us that there no way they would ever want to use
> ASN.1. Completely impossible - not compatible with the way how Web
> applications are developed these days, and so on.
> 
> 

I think this may be a simple case of - all of the low level crypto libraries
that they might link to all support ASN.1 for dealing with asymmetric keys
and they are trying to avoid doing the conversion to JOSE for that work.
The other question is if we should just use ASN.1 for key formats in JOSE
rather than the JSON version if they are going to go with ASN.1 anyway.

Jim

---

From: Mike Jones <[email-masked]>
Date: Mon, 13 Aug 2012 20:24:10 +0000

This argument cuts both ways. If WebCrypto is considering using ASN.1 because we don't provide a private key representation, that may be sufficient grounds for us to consider doing so (either in JWK or in an extension spec).

-- Mike (who returns from vacation tomorrow)

________________________________
From: Jim Schaad
Sent: 8/13/2012 3:48 PM
To: 'Hannes Tschofenig'
Cc: 'Harry Halpin'; [email-masked]
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

Jim

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

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 13 Aug 2012 20:29:11 +0000

Private key was on list moving into JOSE as the requirements were discussed at the BoF and during the charter discussions

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, August 13, 2012 1:24 PM
To: Jim Schaad; 'Hannes Tschofenig'
Cc: 'Harry Halpin'; [email-masked]
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

-- Mike (who returns from vacation tomorrow)
________________________________
From: Jim Schaad
Sent: 8/13/2012 3:48 PM
To: 'Hannes Tschofenig'
Cc: 'Harry Halpin'; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

> Cc: Hannes Tschofenig; 'Harry Halpin'; [email-masked]<mailto:[email-masked]>

Jim

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

---

From: Axel Nennker <[email-masked]>
Date: Mon, 13 Aug 2012 19:14:01 +0200

There are two or more "they"...

ASN.1 should never be MTI in JOSE nor WebCrypto. It is ok to use as a blob
maybe but when either WG specifies something that requires ASN.1 parsing
then we are on the wrong track I think.
 Am 13.08.2012 18:30 schrieb "Hannes Tschofenig" <[email-masked]
>:

> useful

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 15 Aug 2012 13:45:08 -0500

jose wg,

We have received a request for information from the W3C working group. 
We will be working on a response shortly. Comments welcome.

Thanks,
Karen

-------- Original Message --------
Subject: 	JOSE WG request from W3C WebCrypto API
Resent-Date: 	Sun, 12 Aug 2012 11:03:52 -0400 (EDT)
Resent-From: 	[email-masked]
Resent-To: 	[email-masked], [email-masked],
Date: 	Sun, 12 Aug 2012 17:02:30 +0200
From: 	Harry Halpin <[email-masked]>
To: 	Jim Schaad <[email-masked]>, Karen O'Donoghue 
<[email-masked]>, [email-masked], Michael Jones 
<[email-masked]>

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some
access to raw key material, and the issue of whether or not to use JWK
or ASN.1 as the default format came up. Two issues have come out that
we'd like to know the answer to:

  2) While we'd like encourage the use of JOSE over ASN.1, it seems like
for backwards compatibility having some level of ASN.1 support would be
useful and we *need* a format that allows key material (both private and
public) to be exported. Folks seem to leaning towards ASN.1 as a default
format in the low-level API, and having JWK as a format that can be
built on top of that in a possible high-level API. Would that be OK?

  3) How stable do you believe the JOSE formats are right now? Do you
think they are stable enough now we can reference them in our API draft
at end of August? If not, when?  The W3C would like to and plan to use
these formats where possible.

  cheers,
      harry

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 15 Aug 2012 13:53:16 -0500

My apologies folks... This was in my draft folder and I sent instead of 
deleted... please ignore and return to your previously scheduled 
discussion...

Thanks,
Karen

---

From: Mike Jones <[email-masked]>
Date: Wed, 15 Aug 2012 23:19:12 +0000

Thanks for writing, Harry and WebCrypto WG.
 
1)  About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation.  To make this concrete, I would propose the private key representations specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key.  You'll see that doing this is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys.  This could either remain a separate spec from JWK/JWA or be merged in, at the working group's preference.

I had previously agreed with the position that it was not necessary for JOSE to define private key representations because we didn't have a use case for it.  However, as I see it, the W3C WebCrypto API use case changes things.  Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the existing specs, than to leave this undone, and have it potentially be an area where otherwise standards-compliant implementations diverge, and where JSON-only solutions are not possible.

Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining private key formats.  (It simply requires the definition of public key formats and is silent on the topic of private keys.)

2)  I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates).  However, I believe it would be a shame to preclude JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense.

3)  It appears to me the JWK format is stable.  I believe the JWS format is stable as well.  The JWE format has known changes that will be applied shortly, based upon working group discussions at IETF 84 in Vancouver two weeks ago.  Some JWA changes will occur that are part of the JWE changes.  I don't anticipate significant changes after that.  (Making these changes is my highest priority as JOSE editor.  I'm hoping to have drafts out containing them by the end of August, which hopefully fits well with the WebCrypto schedule.)  I write all of the above with the caveat that the working group is, of course, free to change things as they see fit.

I look forward to a productive discussion of this coordination request in both working groups.

				Best wishes,
				-- Mike

P.S.  If you prefer, a HTML-formatted version of the private key spec is available at http://self-issued.info/docs/draft-jones-jose-json-private-key.html.  I also blogged about this draft specification at http://self-issued.info/?p=816.

-----Original Message-----
From: Harry Halpin [mailto:[email-masked]] 
Sent: Sunday, August 12, 2012 8:03 AM
To: Jim Schaad; Karen O'Donoghue; [email-masked]; Mike Jones
Subject: JOSE WG request from W3C WebCrypto API

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'?

  2) While we'd like encourage the use of JOSE over ASN.1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and
public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK?

  3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when?  The W3C would like to and plan to use these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August.

  cheers,
      harry

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 16 Aug 2012 10:46:46 +1000

Mike,

Thanks for making the effort to produce a draft:
http://tools.ietf.org/html/draft-jones-jose-json-private-key

Four comments:

1.
Your choice to extend the public key format to also hold the private key info might have some interesting consequences. It suggests you can have a single file (or single JSON object) that can be used by tools that needs a public key, and by tools that need a private key. However, I doubt that is very good practice. It just adds a risk that a private key is inadvertently exposed where it shouldn't be.

Perhaps the following sort of format would be better:
  {
    "public":{"alg":"...},
    "private":{"d":...}
  }

2.
The rule that integers MUST not be shortened if they have leading 0's is silly. It implies you cannot encode an integer without knowing a larger context (eg you cannot encode d without specifying n, in the context of an RSA key). This rule applies to the private exponent, but the opposite rule applies to the public exponent. Yuck.

Either always forbidding leading zeros, or always allowing them (so receivers MUST support them), would be much better rules.

I just noticed the "MUST not omit leading 0's" rule applies to the RSA modulus in JWA (section 5.3.1 "mod" Modulus Parameter). The rule is even sillier in this case. It effectively says "the modulus MUST be encoded as the size someone/something though the modulus should be, instead of as the size it actually is". This seems to have no purpose other than to mislead (eg trick a component that only looks at the encoded length into thinking the key is longer/stronger than it actually is).

3.
An RSA private key format needs to support calculations that use the Chinese Remainder Theorum (CRT), by allowing p, q, d mod p-1, d mod q-1, and qinv to be specified -- not just d. CRT calculations offer too much of a performance boost to ignore (2 or 4 times faster, can't remember which off the top of my head).

An RSA modulus can actually have more than 2 prime factors. An RSA private key format should theoretically support that as well. That is, support an array of {prime, exponent, coefficient}, instead of hardwiring fields for 2 primes.
See RFC3447 "PKCS #1: RSA Cryptography Specifications, version 2.1".

4.
I am not sure if it has been asked before (by me or someone else), but is there really any benefit from wrapping the JSON array of key objects in another JSON object with a single member "keys" [JWK section 5 "JSON Web Key Set (JWK Set) Format"]? This is adding an extension point with no currently-known use, but without any backward compatibility since any extension MUST be understood. 

--
James Manger

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 17 Aug 2012 11:26:58 +0900

Thanks Mike.

Would it not be a good idea to mandate that private key file must be
encrypted? As far as I remember, one of the reason for not producing
private key format was from the fear that developers leave the exported
keys in a insecure manner.

Thoughts?

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <[email-masked]>wrote:

> 1)  About private keys, given the WebCrypto use case, I personally think
> it would be valuable for JOSE to define a JSON private key representation.
>  To make this concrete, I would propose the private key representations
> specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key.
>  You'll see that doing this is very simple; it just defines two additional
> members for the JWK structure for representing the private parts of
> Elliptic Curve and RSA keys.  This could either remain a separate spec from
> JWK/JWA or be merged in, at the working group's preference.
>
> I had previously agreed with the position that it was not necessary for
> JOSE to define private key representations because we didn't have a use
> case for it.  However, as I see it, the W3C WebCrypto API use case changes
> things.  Better for JOSE to be responsive to WebCrypto and add this simple
> extension, either as a new spec or in the existing specs, than to leave
> this undone, and have it potentially be an area where otherwise
> standards-compliant implementations diverge, and where JSON-only solutions
> are not possible.
>
> Finally, I'll note that the JOSE charter
> http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining
> private key formats.  (It simply requires the definition of public key
> formats and is silent on the topic of private keys.)
>
> 2)  I agree on the likely need for WebCrypto support ASN.1 for backwards
> compatibility in some cases (just as the JOSE specs allow the use of X.509
> certificates).  However, I believe it would be a shame to preclude
> JSON-only solutions by not supporting key import/export in JWK format,
> where such solutions make sense.
>
> 3)  It appears to me the JWK format is stable.  I believe the JWS format
> is stable as well.  The JWE format has known changes that will be applied
> shortly, based upon working group discussions at IETF 84 in Vancouver two
> weeks ago.  Some JWA changes will occur that are part of the JWE changes.
>  I don't anticipate significant changes after that.  (Making these changes
> is my highest priority as JOSE editor.  I'm hoping to have drafts out
> containing them by the end of August, which hopefully fits well with the
> WebCrypto schedule.)  I write all of the above with the caveat that the
> working group is, of course, free to change things as they see fit.
>
> P.S.  If you prefer, a HTML-formatted version of the private key spec is
> available at
> http://self-issued.info/docs/draft-jones-jose-json-private-key.html.  I
> also blogged about this draft specification at
> http://self-issued.info/?p=816.
>
> on top of that in a possible high-level API. Would that be OK?
>
> think they are stable enough now we can reference them in our API draft at
> end of August? If not, when?  The W3C would like to and plan to use these
> formats where possible.
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Aug 2012 10:13:57 -0400

Nat, how would you store the private key that you encrypted the private 
key with? And what key would you use to encrypt your 
private-key-encrypter key? It's turtles all the way down, and not in a 
good way.

I personally really like having a parallel format to JWK for private 
keys, and I even asked (off list) for this feature about six months 
back. My use case was simple, and still valid: I have a server that 
takes in a configuration file with all kinds of already-sensitive 
information, like database passwords and admin user lists. I would love 
to be able to put my public and private keys in there without dropping 
to an ASN.1 structure. I realized that with JWK, I could store my public 
keys, but didn't have any place to put the private keys. At the time, we 
punted and went with a container-native certificate store with 
self-signed certificates, but this setup remains overkill and a bad fit 
for what we actually care about, the keys. But in order to get the keys, 
we had to generate a self-signed cert with a fake certificate authority 
and junk metadata just to fit the format. A JWK/JPK structure (to coin 
an acronym for the soup) would be able to handle this quite nicely, and 
it parallels what the WebCrypto WG is after, from what I gather. It 
would be fairly easy to add support for shared HMAC secrets in the same 
format as well.

However, I do agree with one point that was brought up: I don't 
necessarily like putting the two in the same structure. I think it's 
quite *functional* this way, but it seems like it could cause a problem 
like the private bits getting leaked. On the other hand, this feeling 
could be a case of premature intuition-based optimization [1], so I'm 
not sure how much credence to give it.

  -- Justin

[1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/

On 08/16/2012 10:26 PM, Nat Sakimura wrote:
> private key format was from the fear that developers leave the 
> exported keys in a insecure manner.
>
> Thoughts?
>
> Nat
>
> On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     1)  About private keys, given the WebCrypto use case, I personally
>     think it would be valuable for JOSE to define a JSON private key
>     representation.  To make this concrete, I would propose the
>     private key representations specified in
>     http://tools.ietf.org/html/draft-jones-jose-json-private-key.
>      You'll see that doing this is very simple; it just defines two
>     additional members for the JWK structure for representing the
>     private parts of Elliptic Curve and RSA keys.  This could either
>     remain a separate spec from JWK/JWA or be merged in, at the
>     working group's preference.
>
>     I had previously agreed with the position that it was not
>     necessary for JOSE to define private key representations because
>     we didn't have a use case for it.  However, as I see it, the W3C
>     WebCrypto API use case changes things.  Better for JOSE to be
>     responsive to WebCrypto and add this simple extension, either as a
>     new spec or in the existing specs, than to leave this undone, and
>     have it potentially be an area where otherwise standards-compliant
>     implementations diverge, and where JSON-only solutions are not
>     possible.
>
>     http://datatracker.ietf.org/wg/jose/charter/ does not preclude
>     defining private key formats.  (It simply requires the definition
>     of public key formats and is silent on the topic of private keys.)
>
>     2)  I agree on the likely need for WebCrypto support ASN.1 for
>     backwards compatibility in some cases (just as the JOSE specs
>     allow the use of X.509 certificates).  However, I believe it would
>     be a shame to preclude JSON-only solutions by not supporting key
>     import/export in JWK format, where such solutions make sense.
>
>     3)  It appears to me the JWK format is stable.  I believe the JWS
>     format is stable as well.  The JWE format has known changes that
>     will be applied shortly, based upon working group discussions at
>     IETF 84 in Vancouver two weeks ago.  Some JWA changes will occur
>     that are part of the JWE changes.  I don't anticipate significant
>     changes after that.  (Making these changes is my highest priority
>     as JOSE editor.  I'm hoping to have drafts out containing them by
>     the end of August, which hopefully fits well with the WebCrypto
>     schedule.)  I write all of the above with the caveat that the
>     P.S.  If you prefer, a HTML-formatted version of the private key
>     spec is available at
>     http://self-issued.info/docs/draft-jones-jose-json-private-key.html.
>      I also blogged about this draft specification at
>     From: Harry Halpin [mailto:[email-masked] <mailto:[email-masked]>]
>     To: Jim Schaad; Karen O'Donoghue; [email-masked]
>     <mailto:[email-masked]>; Mike Jones
>     The Web Cryptography Working group has noted that the API requires
>     some access to raw key material, and the issue of whether or not
>     to use JWK or ASN.1 as the default format came up. Two issues have
>     come out that we'd like to know the answer to:
>
>     1) JWK does not define a private key format. Does the JOSE WG plan
>     to support a JOSE-format for private keys? If so, when? Or 'maybe'?
>
>       2) While we'd like encourage the use of JOSE over ASN.1, it
>     seems like for backwards compatibility having some level of ASN.1
>     support would be useful and we *need* a format that allows key
>     material (both private and
>     default format in the low-level API, and having JWK as a format
>     that can be built on top of that in a possible high-level API.
>     Would that be OK?
>
>       3) How stable do you believe the JOSE formats are right now? Do
>     you think they are stable enough now we can reference them in our
>     API draft at end of August? If not, when?  The W3C would like to
>     and plan to use these formats where possible.
>
>     Feel free to forward this by JOSE WG for discussion. We'd like an
>     answer before we send our document to FPWD at end of August.
>
>       cheers,
>           harry
>
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Fri, 17 Aug 2012 17:07:56 +0000

Replies inline.

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 5:47 PM
To: Mike Jones; [email-masked]
Subject: private keys, leading zeros

Mike,

You’re welcome. ;-)

Four comments:

1.

  {

    "public":{"alg":"...},

    "private":{"d":...}

  }

For what it’s worth, having a format that can represent either public or public/private seems to be fairly common practice for crypto APIs.  For instance, see http://msdn.microsoft.com/en-us/library/system.security.cryptography.cngkeyblobformat.aspx.  I believe that similar functions are also available for Java, etc.

2.

This language was actually just copied from JWK.  The goal is to facilitate direct conversion from the base64url encoded representations of the byte arrays to the byte arrays for the key values, with no “shifting” or “prepending” required.  Many crypto APIs will expect byte arrays of specific lengths, that include the leading zeros.  It seemed better to mandate that the leading zeros be included so that the resulting byte arrays can be used as-is, rather than potentially having to prepend them if they are missing before using the byte array.

That being said, if the working group decides to change this to say that leading zeros may be omitted, we could do that, although it would mean that implementations have more to do when importing keys.

3.

This makes sense.  Is there existing practice for such representations that you can point us to that we could borrow from?

Is this used in practice?  The code that I’ve looked at doesn’t support this.  If it’s just a theoretical case, rather than a practical one, I don’t see any need for us to support it.

4.

This allows deployments to define and use other members to provide additional information about the key set.  Jim Schaad had suggested defining the registry for these member for exactly this purpose, which made sense to me.

--

James Manger

---

From: Mike Jones <[email-masked]>
Date: Fri, 17 Aug 2012 17:16:34 +0000

Nat, I agree that a JWK containing a private key *could* be encrypted, but requiring that seems to be overkill, in part, for the reasons that Justin describes.  There are many contexts where it is normal/safe to handle private key information - just like it's normal/safe to handle plaintext password values.  (Analogously, there are also contexts where this information should/must be encrypted.)  Knowing when private keys should/must be encrypted seems like a higher-level context-dependent decision.

Justin, per my reply to James, putting the two in the same structure seems to be existing practice for other APIs.  It's certainly the simplest solution.  I don't see that the safety properties would be any different whether there are "public" and "private" members with sub-members for the key fields, or simply a flat structure of key members, which is currently what's specified.  In both cases, if there is private key information present, it *must* be appropriately protected.

                                                            Best wishes,
                                                            -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Friday, August 17, 2012 7:14 AM
To: Nat Sakimura
Cc: Mike Jones; Jim Schaad; [email-masked]; Harry Halpin; [email-masked]; Karen O'Donoghue
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way.

I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well.

However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it.

 -- Justin

Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner.

Thoughts?

Nat
On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for writing, Harry and WebCrypto WG.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: Harry Halpin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, August 12, 2012 8:03 AM
To: Jim Schaad; Karen O'Donoghue; [email-masked]<mailto:[email-masked]>; Mike Jones
Subject: JOSE WG request from W3C WebCrypto API

JOSE Chairs,

  cheers,
      harry

jose mailing list

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Aug 2012 13:21:06 -0400

> Justin, per my reply to James, putting the two in the same structure 
> seems to be existing practice for other APIs.  It's certainly the 
> simplest solution.  I don't see that the safety properties would be 
> any different whether there are "public" and "private" members with 
> sub-members for the key fields, or simply a flat structure of key 
> members, which is currently what's specified.  In both cases, if there 
> is private key information present, it **must** be appropriately 
> protected.
>
Right, when you put it in those terms it makes more sense. The keys are 
going to be contained in the same root object structure either way, and 
it'd be just as likely for someone to accidentally grab the public keys 
in both cases.

  -- Justin
>
> *From:*Justin Richer [mailto:[email-masked]]
> *Sent:* Friday, August 17, 2012 7:14 AM
> *To:* Nat Sakimura
> *Cc:* Mike Jones; Jim Schaad; [email-masked]; Harry 
> Halpin; [email-masked]; Karen O'Donoghue
> *Subject:* Re: [jose] JOSE WG request from W3C WebCrypto API
>
> Nat, how would you store the private key that you encrypted the 
> private key with? And what key would you use to encrypt your 
> information, like database passwords and admin user lists. I would 
> love to be able to put my public and private keys in there without 
> dropping to an ASN.1 structure. I realized that with JWK, I could 
> store my public keys, but didn't have any place to put the private 
> keys. At the time, we punted and went with a container-native 
> certificate store with self-signed certificates, but this setup 
> remains overkill and a bad fit for what we actually care about, the 
> keys. But in order to get the keys, we had to generate a self-signed 
> cert with a fake certificate authority and junk metadata just to fit 
> the format. A JWK/JPK structure (to coin an acronym for the soup) 
> would be able to handle this quite nicely, and it parallels what the 
> WebCrypto WG is after, from what I gather. It would be fairly easy to 
> add support for shared HMAC secrets in the same format as well.
>
> quite *functional* this way, but it seems like it could cause a 
> problem like the private bits getting leaked. On the other hand, this 
> feeling could be a case of premature intuition-based optimization [1], 
> so I'm not sure how much credence to give it.
>
>  -- Justin
>
>     Would it not be a good idea to mandate that private key file must
>     be encrypted? As far as I remember, one of the reason for not
>     producing private key format was from the fear that developers
>     leave the exported keys in a insecure manner.
>
>     Thoughts?
>
>     Nat
>
>     http://datatracker.ietf.org/wg/jose/charter/
>     <http://datatracker.ietf.org/wg/jose/charter/> does not preclude

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Aug 2012 14:01:38 -0400

Meant to say "accidentally grab the private keys" below, obviously. I 
care somewhat less about who grabs my public keys.

  -- Justin

On 08/17/2012 01:21 PM, Justin Richer wrote:
>> members, which is currently what's specified.  In both cases, if 
>> there is private key information present, it **must** be 
>> appropriately protected.
>>
> Right, when you put it in those terms it makes more sense. The keys 
> are going to be contained in the same root object structure either 
> way, and it'd be just as likely for someone to accidentally grab the 
> public keys in both cases.
>
>  -- Justin
>>
>> private-key-encrypter key? It's turtles all the way down, and not in 
>> a good way.
>>
>> feeling could be a case of premature intuition-based optimization 
>> [1], so I'm not sure how much credence to give it.
>>
>>  -- Justin
>>
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     1)  About private keys, given the WebCrypto use case, I
>>     personally think it would be valuable for JOSE to define a JSON
>>     private key representation.  To make this concrete, I would
>>     propose the private key representations specified in
>>     responsive to WebCrypto and add this simple extension, either as
>>     a new spec or in the existing specs, than to leave this undone,
>>     and have it potentially be an area where otherwise
>>     standards-compliant implementations diverge, and where JSON-only
>>     solutions are not possible.
>>
>>     allow the use of X.509 certificates).  However, I believe it
>>     would be a shame to preclude JSON-only solutions by not
>>     supporting key import/export in JWK format, where such solutions
>>     make sense.
>>
>>     The Web Cryptography Working group has noted that the API
>>     requires some access to raw key material, and the issue of
>>     whether or not to use JWK or ASN.1 as the default format came up.
>>     Two issues have come out that we'd like to know the answer to:
>>
>>     1) JWK does not define a private key format. Does the JOSE WG
>>     plan to support a JOSE-format for private keys? If so, when? Or
>>     'maybe'?
>>

---

From: Harry Halpin <[email-masked]>
Date: Fri, 17 Aug 2012 14:51:49 +0200

> 1)  About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation.  To make this concrete, I would propose the priva…
cheer
If that could be done, that would be great. Just keep WebCrypto in the loop.
> 2)  I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates).  However, I believe it would be a…

My feeling, and we've expressed this on telecons, is that we want JOSE 
compatibility, especially to encourage WebApp developers who are not 
crypto experts, as I imagine they would likely rather deal with JOSE 
than ASN.1. Our API is likely going to have a "lower-level" for general 
application programming version that will support ASN.1 due , and a 
"higher-level" one for WebApp developers come out later (in about 6 
months).
> 3)  It appears to me the JWK format is stable.  I believe the JWS format is stable as well.  The JWE format has known changes that will be applied shortly, based upon working group discussions at I…

I think the JOSE WG is moving ahead of us nicely, so I imagine having 
things stabilized in about 6 months would be perfect in order to be used 
with the "higher-level" API.

   cheers,
        harry

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 18 Aug 2012 12:27:03 +0900

The rationale for having the encrypted keys were because I thought that the
main use case were to transfer keys from one system to another, while it
stays within a system, hopefully we can use platform supplied storage
mechanism and key store.

Now, your use case is different. You want to use the JWK private key stored
in the local file system to sign or encrypt messages. For that, I agree it
is turtles all the way. System implementers needs to be careful on how the
process authentication is done when allowing the access to the key file is
done though.

=nat via iPhone

On Aug 17, 2012, at 11:15 PM, Justin Richer <[email-masked]> wrote:

 Nat, how would you store the private key that you encrypted the private
key with? And what key would you use to encrypt your private-key-encrypter
key? It's turtles all the way down, and not in a good way.

I personally really like having a parallel format to JWK for private keys,
and I even asked (off list) for this feature about six months back. My use
case was simple, and still valid: I have a server that takes in a
configuration file with all kinds of already-sensitive information, like
database passwords and admin user lists. I would love to be able to put my
public and private keys in there without dropping to an ASN.1 structure. I
realized that with JWK, I could store my public keys, but didn't have any
place to put the private keys. At the time, we punted and went with a
container-native certificate store with self-signed certificates, but this
setup remains overkill and a bad fit for what we actually care about, the
keys. But in order to get the keys, we had to generate a self-signed cert
with a fake certificate authority and junk metadata just to fit the format.
A JWK/JPK structure (to coin an acronym for the soup) would be able to
handle this quite nicely, and it parallels what the WebCrypto WG is after,
from what I gather. It would be fairly easy to add support for shared HMAC
secrets in the same format as well.

However, I do agree with one point that was brought up: I don't necessarily
like putting the two in the same structure. I think it's quite *functional*
this way, but it seems like it could cause a problem like the private bits
getting leaked. On the other hand, this feeling could be a case of
premature intuition-based optimization [1], so I'm not sure how much
credence to give it.

 -- Justin

 Thanks Mike.

 Thoughts?

 Nat

_______________________________________________
jose mailing [email-masked]://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 18 Aug 2012 20:02:19 +0930

Mike,

You have said that you think that doing this as JOSE structures would be
useful.  It is not clear to me that there is actually a use case defined
here that bears that out.

Who is responsible for building and encrypting (or decrypting and parsing)
the structure? Are we suggesting that the private keys be exported in the
clear and it is up to the JOSE developer to encrypt them or are we saying
that it is up to the WebCrypto system to do this on behalf of the JOSE
developer?

If we say it is the JOSE developer, then this introduces lots of places
where the private keys will be handled insecurely - if nothing else from
just hanging around in memory until they get cleaned up.

If we say that it is the WebCrypto system that does this, then we are saying
that we don't really care what the format of the private key blobs is
internally, we just need to know how to deal with them from the scripting
side - which would be as a blob of some type (either a binary blob or a
string blob).  

Finally, how much do we want this to be a portable method of doing key
transport?  All of the browsers currently have a method of doing an import
and export of an ASN.1 private key blob.  What is the additional benefit
that you think would be obtained from the WebCrypto side from having a
second format that all of the browsers would need to support, but which
might not have the same level of support from various operating systems and
key devices?  Would this then lead to scripters needing to have two
different sets of import/export code depending on what the internal
structure was and potentially needed to switch between the two structures?

I think it makes sense to allow for the use of JOSE public keys since that
is being passed in the message structure itself.  I don't believe that it
makes a great deal of sense at this point in time to have a private key
structure defined.

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 8:49 AM
> To: Harry Halpin; Jim Schaad; Karen O'Donoghue; [email-masked]
> Cc: [email-masked]
> Subject: RE: JOSE WG request from W3C WebCrypto API
> 
it
> would be valuable for JOSE to define a JSON private key representation.
To
> make this concrete, I would propose the private key representations
Elliptic
> Curve and RSA keys.  This could either remain a separate spec from JWK/JWA
> or be merged in, at the working group's preference.
> 
JOSE
> to define private key representations because we didn't have a use case
for
> it.  However, as I see it, the W3C WebCrypto API use case changes things.
> Better for JOSE to be responsive to WebCrypto and add this simple
this
> undone, and have it potentially be an area where otherwise standards-
> compliant implementations diverge, and where JSON-only solutions are not
> possible.
> 
formats
> and is silent on the topic of private keys.)
> 
JSON-only
> solutions by not supporting key import/export in JWK format, where such
> solutions make sense.
> 
is
> stable as well.  The JWE format has known changes that will be applied
I
> don't anticipate significant changes after that.  (Making these changes is
my
> highest priority as JOSE editor.  I'm hoping to have drafts out containing
them
> by the end of August, which hopefully fits well with the WebCrypto
> schedule.)  I write all of the above with the caveat that the working
group is,
> of course, free to change things as they see fit.
> 
> I look forward to a productive discussion of this coordination request in
both
> working groups.
> available at http://self-issued.info/docs/draft-jones-jose-json-private-
> key.html.  I also blogged about this draft specification at http://self-
> issued.info/?p=816.
> 
for
on
think
of

---

From: "Manger, James H" <[email-masked]>
Date: Sun, 19 Aug 2012 20:46:23 +1000

Additions with [JM] prefix

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 5:47 PM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: private keys, leading zeros

Mike,

You’re welcome. ;-)

Four comments:

1.

  {

    "public":{"alg":"...},

    "private":{"d":...}

  }

[JM] I think this shows the opposite. The CngKeyBlobFormat class represents a format, not an actual key. It has separate formats for private keys (EccPrivateBlob, GenericPrivateBlob, Pkcs8PrivateBlob) and public keys (EccPublicBlob, GenericPublicBlob).

2.

3.

[JM] RFC 3447 “PKCS #1: RSA Cryptography Specifications, version 2.1”, section A.1.2 RSA private key syntax, for the RSAPrivateKey ASN.1 type.

4.

[JM] Except that “providing additional information about the key set” will be barely deployable as it will break all existing systems (such as crypto libraries) at that time due to the MUST understand rule.

For a set of keys, how about using a JSON object with field names that are key-ids, and the values are JWKs.

  { “2012-06”:{“alg”:”RSA”,…}, “2012-05”:{“alg”:”RSA”,…}}

That makes it easy/intuitive to find the key needed for a JOSE message from the key-id in that message.

It means the JSON fragment syntax defined in the JSON pointer draft spec can be sensible used with a URI that points to a set of keys:  {"jku":"http://example.com/~jim/keys.jwk#/2012-06" }

--

James Manger

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 Aug 2012 10:14:05 -0400

> The rationale for having the encrypted keys were because I thought 
> that the main use case were to transfer keys from one system to 
> another, while it stays within a system, hopefully we can use platform 
> supplied storage mechanism and key store.
That makes sense. In that case, I think it would make more sense to just 
use an existing encryption container like JWE with the public and 
private key structure as the payload. Or just use TLS.

>
> Now, your use case is different. You want to use the JWK private key 
> stored in the local file system to sign or encrypt messages. For that, 
> I agree it is turtles all the way. System implementers needs to be 
> careful on how the process authentication is done when allowing the 
> access to the key file is done though.

Yes, absolutely. But in our use case (service configuration) it's 
already being stored and protected in a place that houses other 
sensitive secrets, and it needs to be treated as sensitive just like the 
rest of them.

  -- Justin

>
> On Aug 17, 2012, at 11:15 PM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>>     defining private key formats.  (It simply requires the
>>>     definition of public key formats and is silent on the topic of
>>>     private keys.)
>>>
>>>     3)  It appears to me the JWK format is stable.  I believe the
>>>     JWS format is stable as well.  The JWE format has known changes
>>>     that will be applied shortly, based upon working group
>>>     discussions at IETF 84 in Vancouver two weeks ago.  Some JWA
>>>     changes will occur that are part of the JWE changes.  I don't
>>>     anticipate significant changes after that.  (Making these
>>>     changes is my highest priority as JOSE editor.  I'm hoping to
>>>     have drafts out containing them by the end of August, which
>>>     hopefully fits well with the WebCrypto schedule.)  I write all
>>>     of the above with the caveat that the working group is, of
>>>     course, free to change things as they see fit.
>>>
>>>     whether or not to use JWK or ASN.1 as the default format came
>>>     up. Two issues have come out that we'd like to know the answer to:
>>>
>>>     seems like for backwards compatibility having some level of
>>>     ASN.1 support would be useful and we *need* a format that allows
>>>     key material (both private and
>>>       3) How stable do you believe the JOSE formats are right now?
>>>     Do you think they are stable enough now we can reference them in
>>>     our API draft at end of August? If not, when?  The W3C would
>>>     like to and plan to use these formats where possible.
>>>
>>>     Feel free to forward this by JOSE WG for discussion. We'd like
>>>     an answer before we send our document to FPWD at end of August.
>>>
>>>       cheers,
>>>           harry
>>>
>>>
>>>
>>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 23 Aug 2012 18:15:19 +0000

The use cases come from the WebCrypto spec, which requires key import/export, and one of the supported import/export formats is JWK.  See http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyImporter-interface, for instance.  Search for "export" in the spec for other pertinent sections.

I'm not saying that the private key format necessarily needs to be part of JWK itself.  The right solution might very well be an optional supplemental spec.

But I do think that it would be a good thing for JOSE to try to be responsive to the W3C's request in this regard.  That why I created http://tools.ietf.org/html/draft-jones-jose-json-private-key-00 to facilitate concrete discussion of the possible solution space.

				Best wishes,
				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Saturday, August 18, 2012 3:32 AM
To: Mike Jones; 'Harry Halpin'
Cc: [email-masked]
Subject: RE: JOSE WG request from W3C WebCrypto API

Mike,

You have said that you think that doing this as JOSE structures would be useful.  It is not clear to me that there is actually a use case defined here that bears that out.

Who is responsible for building and encrypting (or decrypting and parsing) the structure? Are we suggesting that the private keys be exported in the clear and it is up to the JOSE developer to encrypt them or are we saying that it is up to the WebCrypto system to do this on behalf of the JOSE developer?

If we say it is the JOSE developer, then this introduces lots of places where the private keys will be handled insecurely - if nothing else from just hanging around in memory until they get cleaned up.

If we say that it is the WebCrypto system that does this, then we are saying that we don't really care what the format of the private key blobs is internally, we just need to know how to deal with them from the scripting side - which would be as a blob of some type (either a binary blob or a string blob).  

Finally, how much do we want this to be a portable method of doing key transport?  All of the browsers currently have a method of doing an import and export of an ASN.1 private key blob.  What is the additional benefit that you think would be obtained from the WebCrypto side from having a second format that all of the browsers would need to support, but which might not have the same level of support from various operating systems and key devices?  Would this then lead to scripters needing to have two different sets of import/export code depending on what the internal structure was and potentially needed to switch between the two structures?

I think it makes sense to allow for the use of JOSE public keys since that is being passed in the message structure itself.  I don't believe that it makes a great deal of sense at this point in time to have a private key structure defined.

Jim

it
To
> additional members for the JWK structure for representing the private 
> parts of
Elliptic
> Curve and RSA keys.  This could either remain a separate spec from 
JOSE
for
this
> compliant implementations diverge, and where JSON-only solutions are 
> not possible.
> 
> defining private key formats.  (It simply requires the definition of 
> public key
formats
> backwards compatibility in some cases (just as the JOSE specs allow 
> the use of X.509 certificates).  However, I believe it would be a 
> shame to preclude
JSON-only
> solutions by not supporting key import/export in JWK format, where 
> such solutions make sense.
> 
> format
is
> shortly, based upon working group discussions at IETF 84 in Vancouver 
> two weeks ago.  Some JWA changes will occur that are part of the JWE changes.
I
my
them
group is,
both
> working groups.
> 
> 				Best wishes,
> 				-- Mike
> 
> P.S.  If you prefer, a HTML-formatted version of the private key spec 
> is available at 
> http://self-issued.info/docs/draft-jones-jose-json-private-
> key.html.  I also blogged about this draft specification at 
> http://self- issued.info/?p=816.
> 
> some access to raw key material, and the issue of whether or not to 
> use JWK or
> ASN.1 as the default format came up. Two issues have come out that 
for
on
think
of
> August? If not, when?  The W3C would like to and plan to use these 
> formats where possible.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Aug 2012 21:57:40 +0300

I had noticed the need for a mechanism to carry a privacy key in a 
JSON-based format already with the work on the OAuth-HOTK document. 
Without it I was only able to generate the public/private key pair on 
the client and to make the public key available to the authorization 
server. With Mike's new draft I can now off-load the expensive 
asymmetric key generation to the server.

I also know that this is not a mechanism that every use case would need 
and hence it good that it is defined as a separate extension, as Mike did.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 24 Aug 2012 18:16:19 +1000

Hannes,

Is carrying this directly in JSON better than carrying as a binary blob
using the current PKCS#8 format?

I remain unconvinced that this is a true statement given the number of
different ways that it can be messed up.

Jim

> Sent: Friday, August 24, 2012 4:58 AM
> To: Mike Jones
> Cc: Jim Schaad; 'Harry Halpin'; [email-masked]
> I had noticed the need for a mechanism to carry a privacy key in a JSON-
> based format already with the work on the OAuth-HOTK document.
> Without it I was only able to generate the public/private key pair on the
client
> and to make the public key available to the authorization server. With
Mike's
> new draft I can now off-load the expensive asymmetric key generation to
> the server.
> 
and
> hence it good that it is defined as a separate extension, as Mike did.
> 
> > The use cases come from the WebCrypto spec, which requires key
> import/export, and one of the supported import/export formats is JWK.  See
> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyImporter-
> interface, for instance.  Search for "export" in the spec for other
pertinent
> sections.
> >
> > I'm not saying that the private key format necessarily needs to be part
of
> JWK itself.  The right solution might very well be an optional
supplemental
> spec.
> >
> > But I do think that it would be a good thing for JOSE to try to be
responsive
> to the W3C's request in this regard.  That why I created
> http://tools.ietf.org/html/draft-jones-jose-json-private-key-00 to
facilitate
> concrete discussion of the possible solution space.
> >
> > 				Best wishes,
> > 				-- Mike
> >
here that
> bears that out.
that
> it is up to the WebCrypto system to do this on behalf of the JOSE
developer?
> > If we say it is the JOSE developer, then this introduces lots of places
where
> the private keys will be handled insecurely - if nothing else from just
hanging
> around in memory until they get cleaned up.
> >
string
> blob).
that
> you think would be obtained from the WebCrypto side from having a second
> format that all of the browsers would need to support, but which might not
> have the same level of support from various operating systems and key
> devices?  Would this then lead to scripters needing to have two different
> sets of import/export code depending on what the internal structure was
> and potentially needed to switch between the two structures?
> >
> > I think it makes sense to allow for the use of JOSE public keys since
that is
> being passed in the message structure itself.  I don't believe that it
makes a
> great deal of sense at this point in time to have a private key structure
> defined.
> >
> > Jim
> >
> >
> >> specified in
> >> stable as well.  The JWE format has known changes that will be
> >> applied shortly, based upon working group discussions at IETF 84 in
> >> Vancouver two weeks ago.  Some JWA changes will occur that are part of
> the JWE changes.
> > I
> >> you