That's close to my recollection as well. I'll summarize the primary
conclusions in a different way to hopefully make them even clearer to people
who weren't there:
(1) We will define JWK extensions to represent private and symmetric keys
(2) We will recommend protection of private and symmetric keys by encrypting
their JWK representations in a JWE
(3) We will define an additional JWA "alg" value for generation of a symmetric
key from a password (thus enabling password-based key protection schemes)
The two deliverables we agreed to were:
(A) The JWK extension document defining (1), which Mike will produce
(B) A key protection application document specifying (2) and (3), which Matt
will produce
Note that (B) will use the JWA registry to register (3), rather than adding (3)
to the JWA doc itself.
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Matt
Miller (mamille2)
Sent: Thursday, November 15, 2012 10:25 AM
To: [email protected]
Subject: [jose] Whiteboard Discussion MInutes
[ I urge the original participants to correct any omissions or glaring mistakes
]
Participants
============
* Richard Barnes
* John Bradley
* Joe Hildebrand
* Michael Jones
* Matt Miller
* Jim Schaad
"What's a JOSE"
===============
We started with a discussion of what the areas of concerns for JOSE are
(established or otherwise):
* public key
* private key
* symmetric key
* sign
* encrypt
* MAC
* wrapped keys
* passphrase-based wrapping
* algorithms
* extensibility
* common attributes
* serialization/syntax
Regarding Keys
==============
There was also discussion on whether wrapped keys were their own top-level
object, or an application of JWE. With this discussion, there was rough
consensus that keys (including symmetric keys) should have the ability to
include additional information (e.g. "expires" ).
For top-level, this is approximately as presented in the WG:
{
"typ":"transport",
"alg":RSA-OEAP",
"jwk":{ ... },
"val":base64url(pk-encrypt(jku, symmetric key value)) }
For JWE application, the key would have a JWK representation:
{
"typ":"AES",
"key":base64url(symmetric key value)
}
Which is then serialized to UTF-8 and used as the plaintext into JWE.
Given this, there was very rough consensus that we pursue the "wrapped keys as
JWE application" path, although it was suggested Richard provide a more
concrete example of the top-level model.
Regarding Encrypted Private Keys
================================
There was discussion and consensus on adding support for PBKDF2 to derive a
symmetric key from a password. The details are to be worked out as part of the
wrapped key document.
Regarding Organization
======================
There was discussion on the organization of items, and whether the current
documentation is sufficient. While there was no consensus on what the best
layout is, there was also no consensus on changing anything.
Work Items
==========
There was rough consensus on the following outputs, assuming no objections from
the rest of the WG:
* A document extending "RSA" and "EC" with the private key factors, plus a new
JWK for symmetric keys. Tentatively to be done by Mike Jones, starting with
draft-jones-jose-json-private-key
* A document that applies JWE to protecting keys (as JWK objects), and defines
an algorithm that uses PBKDF2 for passphrase-based protection. Tentatively to
be done by Matt Miller.
- m&m
Matt Miller < [email protected] >
Cisco Systems, Inc.
PS: If you are interested in the cryptic notes, the images are temporarily
available at < http://outer-planes.net/ietf/ietf85-josewg/ >.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
