Re: [jose] Proposed Text

Hi Jim,

Thanks for taking a cut at this.  I agree that the "IETF applications"
distinction is not helpful.  Also, I don't think RFC 2119 language is
helpful here.

The security risk here is that an application will make a security decision
based on a field it doesn't understand.  We should focus on that.  (Like
you, I have trouble coming up with an example, but I guess I'm willing to
admit the possibility.

Revised text proposal:

*************************************************************

The JOSE header is extensible to include new header fields that a recipient
may or may not support.  Applications making use of JOSE need to ensure
that security decisions ignore any header fields that are not understood by
an implementation.  An application specification might do this by requiring
that a specific set of header fields be present in every JOSE object (and no
others), or it might specify a decision process in terms of specific fields,
and explicitly require implementations to ignore other fields.

The reason why the default position is that applications need to understand
and process all of the headers can be seen in the following example.  <Jones
et al provide a non-trivial example that demonstrates the security problem
associated with ignoring header fields.>

******************************************************************

On Sun, Feb 24, 2013 at 9:41 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> Sorry, I was missing a clause in the text
>
> IETF applications that use the JOSE work MUST
>
> I was trying to say that IETF documents using JOSE must do this, however we
> cannot really impose it on non IETF documents.
>
> Jim
>
>
> > -----Original Message-----
> > From: Russ Housley [mailto:housley@vigilsec.com]
> > Sent: Sunday, February 24, 2013 2:18 PM
> > To: Jim Schaad
> > Cc: jose@ietf.org
> > Subject: Re: [jose] Proposed Text - MUST understand
> >
> > How is an IETF application different than any other application?
> >
> > The Datatracker, rfcdiff, and xml2rfc will probably never need to use
> jose, so
> > I know that is not the intended meaning.  ;-)
> >
> > Russ
> >
> >
> > On Feb 24, 2013, at 3:32 PM, Jim Schaad wrote:
> >
> > > I am going to venture some proposed text to try and advance the
> > > discussion about the MUST understand all fields in the current
> > > document.  I acknowledge that the text is written from the point of
> > > view that I espouse, however I think that perhaps it does give a
> > > sufficient amount of credence to the point of view of other that it
> > > might provide a good starting point for discussions.
> > >
> > > This text is written standalone and as such I have not yet tried to
> > > incorporate it into the different documents and in the different
> locations.
> > > It is possible that the text will need to be somewhat repurposed when
> > > it appears in each of the different documents.
> > >
> > >
> > **********************************************************
> > ***
> > >
> > > Applications which use this specification SHOULD ensure that all of
> > > the fields in the header are used in either in making the trust
> > > decision or determining how to use the content.  IETF applications
> > > MUST have  default position of requiring that all fields in the header
> > > are known to and used by the application.  IETF applications which
> > > allow for fields in the header to be ignored MUST include a
> > > justification of why this decision was made and looking at the security
> > trade-offs of the decision.
> > >
> > > The reason why the default position is that applications need to
> > > understand and process all of the headers can be seen in the following
> > > example.  <Jones et al provide a non-trivial example that demonstrates
> > > the security problem associated with ignoring header fields.>
> > >
> > >
> > **********************************************************
> > ********
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>