Re: [jose] #155: Section 6.1.1 Template

"jose issue tracker" <trac+jose@trac.tools.ietf.org> Sun, 27 October 2013 00:35 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: jose issue tracker <trac+jose@trac.tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, ietf@augustcellars.com
Date: Sun, 27 Oct 2013 00:35:37 -0000
Message-ID: <076.affe3eb24eadb3a61117dc3117c11545@trac.tools.ietf.org>
References: <061.ec9e375d0fecbdd7e8c8dbc8ef76179c@trac.tools.ietf.org>
In-Reply-To: <061.ec9e375d0fecbdd7e8c8dbc8ef76179c@trac.tools.ietf.org>
Resent-To: mbj@microsoft.com
Resent-Message-Id: <20131027003541.1722B11E81DA@ietfa.amsl.com>
Resent-Date: Sat, 26 Oct 2013 17:35:40 -0700
Resent-From: trac+jose@trac.tools.ietf.org
Cc: jose@ietf.org
Subject: Re: [jose] #155: Section 6.1.1 Template

#155: Section 6.1.1 Template

Description changed by ietf@augustcellars.com:

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.
>
> 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?
>
> H.  There should be a list of required parameters that need to be present
> for each of these algorithms.

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?

 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-
  ietf@augustcellars.com |  algorithms@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  Editorial    |   Milestone:
Component:  json-web-    |     Version:
  algorithms             |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

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

[jose] #155: Section 6.1.1 Template jose issue tracker
Re: [jose] #155: Section 6.1.1 Template jose issue tracker
Re: [jose] #155: Section 6.1.1 Template jose issue tracker
Re: [jose] #155: Section 6.1.1 Template jose issue tracker