> > > Section 3.6.
> > > I'm not going to object to "none", even though I think it's a very
> > > dangerous
> > > feature because of the risk of confusion between Secured and Unsecured
> > > JWS.
> > > But there needs to be stronger guidance:
> > > 1. An implementation SHOULD NOT support "none" unless the implementer
> > > knows that it will be used in application context s that require it.
> > > 2. If an implementation does support "none", then it MUST NOT accept it
> > > as part
> > > of generic JWS validation. Instead, it should require the application to
> > > explicitly
> > > signal that an Unsecured JWS is expected for a given validation operation.
> >
> > As discussed in the working group, your concern about applications
> > inappropriately allowing the use of "none" actually is an instance of a
> > more general concern that applications not allow *any* algorithms to be
> > used that are not appropriate in their application contexts. This concern
> > is already addressed in the specification at the end of Section 5.2 as
> > follows:
> >
> > "Finally, note that it is an application decision which algorithms are
> > acceptable in a given context. Even if a JWS can be successfully validated,
> > unless the algorithm(s) used in the JWS are acceptable to the application,
> > it SHOULD reject the JWS."
> >
> > Since your specific concern is already handled in a more general way, I
> > would like to request that you withdraw this DISCUSS on that basis. Also,
> > you were one of the contributing authors to the security considerations on
> > this topic in Section 8.5 of JWA (Unsecured JWS Security Considerations),
> > so it's not clear that there's any cause for you to come back with
> > additional wording change requests on this topic at this point.
> >
> > Thanks for reminding me about Section 8.5. I think I would be satisfied
> > here if the contents of Section 8.5 were just moved up to this section.
> > That way all of the requirements for implementing "none" will be together.
>
> Section 3.6 does end with the sentence "See Section 8.5 for security
> considerations associated with using this algorithm" so implementers are
> reminded to also pay attention to the security considerations. If we were to
> do what you requested, this would be the only algorithm for which the
> security considerations were included in the algorithm description, rather
> than in the security considerations section, which would be fairly weird and
> non-parallel, editorially.
>
> Actually, "none" is the only algorithm for which there are additional
> normative requirements in the Security Considerations. So it actually seems
> more sensible to move those requirements up.
> I'm really just asking for a copy/paste here, shouldn't be invasive. But I
> do think the level of indirection creates security risk.
I'm OK moving up the three sentences that actually do contain normative
requirements. Those are:
Implementations that support Unsecured JWS objects MUST NOT accept
such objects as valid unless the application specifies that it is
acceptable for a specific object to not be integrity-protected.
Implementations MUST NOT accept Unsecured JWS objects by default.
In order to mitigate downgrade attacks, applications MUST NOT signal
acceptance of Unsecured JWS objects at a global level, and SHOULD
signal acceptance on a per-object basis.
I'm not OK cluttering up the normative description of the algorithm with the
discussion text. Assuming you're OK leaving the discussion text and "for
example" text in 8.5, I think we have a way forward on this one. Please let me
know if that works for you.
> Again, given that you were an author of 8.5 and seemed fine with the
> resolution after the extensive discussion then, I'd ask you to clear the
> DISCUSS on that basis and not request that it be reworked again.
-- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
