Subject: [jose] Proposed Text - MUST understand

From: "Jim Schaad" <[email-masked]>
Date: Sun, 24 Feb 2013 12:32:52 -0800

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.>

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

---

From: Russ Housley <[email-masked]>
Date: Sun, 24 Feb 2013 17:17:49 -0500

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

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 24 Feb 2013 18:41:32 -0800

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:[email-masked]]
> Sent: Sunday, February 24, 2013 2:18 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [jose] Proposed Text - MUST understand
> 
> The Datatracker, rfcdiff, and xml2rfc will probably never need to use
jose, so
> I know that is not the intended meaning.  ;-)
> 
> Russ
> 
> 
> > 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.
> >
> > 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.>
> >
> >

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Feb 2013 17:32:00 -0500

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.

On Sun, Feb 24, 2013 at 9:41 PM, Jim Schaad <[email-masked]> wrote:

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