Subject: [jose] #18: Address MAC key lifetime concerns

From: "jose issue tracker" <[email-masked]>
Date: Fri, 05 Apr 2013 22:10:30 -0000

#18: Address MAC key lifetime concerns

 The point was raised on CFRG that it is beneficial to have short-lived MAC
 keys.
 <http://www.ietf.org/mail-archive/web/cfrg/current/msg03386.html>

 The current JWS specification works against this objective by relying on
 out-of-band mechanisms for provisioning MAC keys.  If there were a
 mechanism for providing short-lived keys wrapped under a long-lived key,
 as there is in JWE, this would not be an issue.

 The working group needs to do one of two things:
 1. Add wrapped keys to JWS
 2. Add security considerations to JWS REQUIRING that an application
 protocol ensure that key lifetimes are controlled.

 In the past, the group has resolved not to do (1) (see ISSUE-2), but it
 also has not done (2).  To resolve this issue, one of the two options
 above needs to be implemented.

-- 
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]   |      Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]
 Priority:  major        |     Status:  new
Component:  json-web-    |  Milestone:
  signature              |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/18>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Fri, 05 Apr 2013 22:15:23 -0000

Comment (by [email-masked]):

 As I have argued before, it is my strong opinion that option (1) is the
 simpler thing to do.  There is no great complexity: The key wrapping
 mechanism is already defined in JWE, so this would simply apply it to JWS
 as well.

 Writing the proper considerations for option (2) would be much harder,
 because you have to specify what an OOB protocol needs to do.  (Easier to
 just write the protocol!) Option (2) would also fail to address a known
 security gap in the base protocol, which seems irresponsible.   This
 protocol needs to be secure without having to rely on something external.

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/18#comment:1>
jose <http://tools.ietf.org/jose/>