Subject: Re: [jose] Chair Review of Draft-ietf-jose-json-web-signature

From: Mike Jones <[email-masked]>
Date: Mon, 3 Mar 2014 12:28:37 +0000

Thanks, Jim.  These issues and the related JWA issue were addressed in the -22 drafts.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, February 21, 2014 10:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [jose] Chair Review of Draft-ietf-jose-json-web-signature

This is a review of the documents from a process point of view.  All items here MUST be fixed prior to the document progressing.

1.  Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).

     The "crit" (critical) Header Parameter indicates that extensions to
     the initial RFC versions of [[ this specification ]] and [JWA] are being
     used that MUST be understood and processed.  Its value is an array
     listing the Header Parameter names present in the JWS Header that use
     those extensions.  If any of the listed extension Header Parameters are
     not understood and supported by the receiver, it MUST reject the JWS. 
     Senders must not include Header Parameter names defined by the initial
     RFC versions of [[ this specification ]] or [JWA] for use with JWS,
     duplicate names, or names that do not occur as Header Parameter names
     within the JWS Header in the "crit" list. Senders MUST not use the empty
     list "[]" as the "crit" value. Recipients MAY reject the JWS if the
     critical list contains any Header Parameter names defined by the initial
     RFC versions of [[ this specification ]] or [JWA] for use with JWS, or
     any other constraints on its use are violated.  This Header Parameter
     MUST be integrity protected, and therefore MUST occur only within the JWS
     Protected Header, when used.  Use of this Header Parameter is OPTIONAL.

     This Header Parameter MUST be understood and processed by implementations.

2.  Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)

	If there is a reason to reference TLS 1.0 rather than the current version of TLS, then there needs to be explicit justification made as to why this is the case.

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose