#155: Section 6.1.1 Template Description changed by [email protected]:
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- [email protected] | [email protected] 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
