No issues identified on the other two documents. > -----Original Message----- > From: Mike Jones [mailto:[email protected]] > Sent: Friday, February 21, 2014 1:04 PM > To: Jim Schaad > Cc: [email protected] > Subject: RE: [jose] Chair Review of Draft-ietf-jose-json-web-signature > > Is there any related feedback on JWE or JWK or are you done with your chair > review of them and no issues were identified? > > Thanks, > -- Mike > > -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Jim Schaad > Sent: Friday, February 21, 2014 10:30 AM > To: [email protected] > Cc: [email protected] > 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 protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
