#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 protected] | [email protected] 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/> _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
