Subject: Re: [jose] #155: Section 6.1.1 Template

From: "jose issue tracker" <[email-masked]>
Date: Thu, 07 Nov 2013 02:40:09 -0000

#155: Section 6.1.1 Template

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

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.
>
> * FIXED
>
> 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.
>
> * WON'T FIX - because we are not fixing the fact that alg is overloaded.
>
> 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.
>
> * WON'T FIX - there is a proposal for how to deal with this.  I don't
> like it but the argument is that we can't break backwards compatibility.
>
> E.  See open issue on Implementation language
>
> F.  s/IETF/IESG/
>
> * FIXED
>
> G.  Private specifications may want to register algorithms to reserve
> them for future release.  Is this a going to be allowable?
>
> * WON'T FIX - currently not forbidden as long as the document exists.
>
> H.  There should be a list of required parameters that need to be present
> for each of these algorithms.
>
> * WON'T FIX - the group currently thinks having it in the body of the
> text is sufficient.

New 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.

 * FIXED

 B.  What happens for I18N on case insensitive checking?

 * WON'T FIX - we will assume that this is not going to be an issue

 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.

 * WON'T FIX - because we are not fixing the fact that alg is overloaded.

 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.

 * WON'T FIX - there is a proposal for how to deal with this.  I don't like
 it but the argument is that we can't break backwards compatibility.

 E.  See open issue on Implementation language

 F.  s/IETF/IESG/

 * FIXED

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

 * WON'T FIX - currently not forbidden as long as the document exists.

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

 * WON'T FIX - the group currently thinks having it in the body of the text
 is sufficient.

--

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

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