Subject: [jose] #155: Section 6.1.1 Template

From: "jose issue tracker" <[email-masked]>
Date: Mon, 19 Aug 2013 14:33:07 -0000

#155: Section 6.1.1 Template

 A.  Name - the SHOULD NOT is a problem without criteria for when it should
 be violated.  Since these are case sensitive, it is not immediate clear
 why this would be an issue.  On the other hand for readability then the
 SHOULD NOT would be MUST not.

 B.  What happens for I18N on case insensitive checking?

 C.  Why would you ever allow an algorithm to be in more than one location?
 This is bad crypto practice.  We used different names for the different
 GCM algorithms so that they were distinct and did not have this problem.

 D.  What happens for future key management of mac values in the future?
 Currently this requires that the template would be modified and items will
 occur in multiple locations.

 E.  See open issue on Implementation language

 F.  s/IETF/IESG/

 G.  Private specifications may want to register algorithms to reserve them
 for future release.  Is this a going to be allowable?

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

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

---

From: "jose issue tracker" <[email-masked]>
Date: Mon, 19 Aug 2013 14:34:00 -0000

Description changed by [email-masked]:

Old description:

> A.  Name - the SHOULD NOT is a problem without criteria for when it
> should be violated.  Since these are case sensitive, it is not immediate
> clear why this would be an issue.  On the other hand for readability then
> the SHOULD NOT would be MUST not.
>
> C.  Why would you ever allow an algorithm to be in more than one
> location?  This is bad crypto practice.  We used different names for the
> different GCM algorithms so that they were distinct and did not have this
> problem.
>
> Currently this requires that the template would be modified and items
> will occur in multiple locations.
>
> G.  Private specifications may want to register algorithms to reserve
> them for future release.  Is this a going to be allowable?

New description:

 F.  s/IETF/IESG/

 H.  There should be a list of required parameters that need to be present
 for each of these algorithms.

--

  algorithms             |  Resolution:
 Keywords:               |

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