Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt

["Jim Schaad" <[e-mail]>]

<no hat>

While I agree that there are issues that have been amply demonstrated with
XML and canonicalization.  I don't know that I would completely agree with
the fact that no canonicalization algorithm has been defined.  I believe
that there may be a benefit in having a canonicalization for writing out the
JSON, and then transporting the canonicalized version of the JSON structure
to the recipient.  The problem with XML was that the recipient had to read
in the structure and then attempt to perform the same canonicalization as
the sender did.

Note that CMS does not require that the same steps as occur as for XML,
however S/MIME does say that one needs to canonicalize the body before
performing the hash functions.  However there is a requirement that the body
not be changed in transport and that the recipient can just use the string
received.

I am not convinced that the JOSE work is not going to need to require that a
new serialization/de-serialization functions are not going to be required to
be written in order for the system to be secure.  Already the documents are
imposing requirements on the serialization process that are not in the core
JSON documents and thus it may not be reasonable to assume that the standard
code will work correctly.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Mike Jones
> Sent: Friday, June 15, 2012 5:08 PM
> To: Richard L. Barnes
> Cc: [e-mail]
> Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-
> jsms-00.txt
> 
> Hi Richard,
> 
> Since your message has been kicking around in the back of my mind, I'll
add
> one more data point on the "Not being JSON" comment.  As the designers of
> JWT and the resulting JOSE specs saw it, there were two clear choices to
able
> to sign/encrypt JSON data structures:
> 
> (1)  Define a canonicalization algorithm and always operate on the
canonical
> forms
> (2)  Base64 encode a representation of the data structure to preserve the
> precise representation
> 
> XML Canonicalization has proven to be a horror, leading to more
> interoperability problems than any other aspect of XMLDSIG, XMLENC,
> SAML, or WS-*.
> 
> We chose #2. :-)
> 
>                                 -- Mike
> 
> -----Original Message-----
> From: Mike Jones
> Sent: Friday, June 15, 2012 3:32 PM
> To: 'Richard L. Barnes'
> Cc: [e-mail]
> Subject: RE: [jose] Fwd: New Version Notification for
draft-barnes-jose-jsms-
> 00.txt
> 
> Fair enough.  I'll briefly respond to each in turn.  Before doing so, I'll
say that
> I'm writing in the spirit of trying to increase mutual understanding and
> consensus, rather than taking the point of view that the status quo is the
> only reasonable outcome.
> 
> -- Not being JSON
> 
> This was by design, so that the results are URL-safe.  This is required,
for
> instance, for them to be used as OAuth Bearer Tokens.  At the request of
the
> working group, closely related pure-JSON drafts were also published.  See:
> 
>
http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization
-
> 01 and
> http://tools.ietf.org/html/draft-jones-json-web-encryption-json-
> serialization-01
> 
> Use them if you prefer if they better suit your use cases.  They could be
> adopted as working group documents, if there's interest.
> 
> -- Not supporting multiple recipients
> 
> The JSON serialization drafts above do, again, in response to use cases
> presented by the working group.
> 
> -- Lacking clear distinctions between signing and MAC
> 
> Functionally, these are very similar operations, at least from an
> implementation perspective, so it's not clear that making a clear
distinction
> would help either developers or adoption in any practical way.  They
achieve
> overlapping, but admittedly sometimes different goals.  I believe that
> developers can be trusted to use the algorithms that achieve their
> applications' goals without making a hard distinction between the two.
But
> I'd be interested in hearing your thoughts on why you believe a
brighter-line
> distinction might be useful or necessary.
> 
> -- Lacking clear processing instructions for different key establishment
> modalities
> 
> This seems like an area where the existing drafts could be refined to add
> descriptions for additional establishment modalities, possibly based upon
> your ideas and descriptions, should the working group decide to do so.
What
> additional modalities do you have use cases for that you believe are not
> achievable or straightforward with the existing drafts?  The existing
> modalities supported are largely those that existing developers had told
us
> they needed and draw both from the precursor draft-jones-json-web-*
> documents and draft-rescorla-jsms.
> 
> Bear in mind that the balance that the current drafts try to strike is
keeping
> the Mandatory to Implement (MTI) feature footprint small enough that
> developers, including Web developers, are likely to adopt the specs, while
> still providing enough functionality to make them generally useful.  As in
any
> balance, it's often possible to shift things a bit and still maintain the
balance,
> but I'd like people to keep the ubiquitous adoption goal front-and-center
> when proposing additional functionality.
> 
> Ubiquitous deployment and usefulness trump theoretical completeness.
> (Just look at XMLDSIG and XMLENC to understand that!)
> 
> -- Lack of clear typing of objects
> 
> Most JSON documents aren't clearly typed; instead, developers and
> implementations understand from context what the meaning of each field is.
> XML is clearly typed, but developers are voting with their feet by moving
to
> JSON.
> 
> What practical advantages resulting from overlaying a typing
infrastructure
> on JSON do you believe are worth the potential costs of doing so?  BTW,
I'm
> not opposed to having a JSON schema description of the JOSE JSON data
> structures like JSMS did in
http://tools.ietf.org/html/draft-rescorla-jsms-
> 00#appendix-A, but I'll remark that this an informative tool, not a
normative
> one.
> 
> -- Lack of versioning for future extensibility
> 
> An optional version field could be added if the working group desires,
> however the last time the working group discussed it, they decided not to
do
> so.  Rather, specs like this effectively become "versioned" when revised
in a
> way that new fields are added.  If you understand the new fields, you
> support that new version.  (Note that this is independent of whether there
is
> a version number field, which according to some participants in the
previous
> discussion, they regarded as therefore being redundant information.)
> 
> I'm not religious about not having a version number field, but often "less
is
> more".
> 
>                                 Best wishes,
>                                 -- Mike
> 
> -----Original Message-----
> From: Richard L. Barnes [mailto:[e-mail]]
> Sent: Friday, June 15, 2012 3:00 PM
> To: Mike Jones
> Cc: [e-mail]
> Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-
> jsms-00.txt
> 
> Ok, so maybe I should have phrased my lead-in differently.  IMO, the
current
> JW* specs are deficient in several ways, e.g.:
> -- Not being JSON
> -- Not supporting multiple recipients
> -- Lacking clear distinctions between signing and MAC
> -- Lacking clear processing instructions for different key establishment
> modalities
> -- Lack of clear typing of objects
> -- Lack of versioning for future extensibility
> 
> Looking at the current specs, it didn't seem to me that it would be simple
to
> adapt them to address these deficiencies.  So I just did a re-write.  If
you
> think they can be addressed within the current framework, please explain.
I
> just found it simpler to start from whole cloth.
> 
> Cheers,
> --Richard
> 
> 
> 
> On Jun 15, 2012, at 5:43 PM, Mike Jones wrote:
> 
> > Hi Richard,
> >
> > If you're puzzled by specific design decisions in the JOSE documents, I
> encourage you to ask about them on the list.  The documents have
significant
> history going back to mid-2010 when convergence discussions started among
> people with four different JSON signing & encryption proposals.  JWT and
the
> current JOSE specs and implementations are the result.  I realize that not
all
> the JOSE participants were part of those discussions from the beginning
> (although many were) and so teasing out the rationale for specific
decisions
> might help people better understand the choices made, and hopefully
> thereby increase consensus behind the eventual working group choices.
> >
> > If the list that you're puzzled by is the bulleted list below, maybe we
can
> start a discussion on that basis.
> >
> >                               Best wishes,
> >                               -- Mike
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Richard L. Barnes
> > Sent: Friday, June 15, 2012 2:08 PM
> > To: [e-mail]
> > Subject: [jose] Fwd: New Version Notification for
> > draft-barnes-jose-jsms-00.txt
> >
> > Dear JOSE WG,
> >
> > Like Mr. Manger, once I finally got around to doing a thorough review of
> the JW* specs, I was kind of puzzled by some of the design decisions.  So
I
> also went through and wrote an alternative format, this time taking a more
> of a cue from CMS.  A link to the document is below.
> >
> > Summary of differences:
> >
> >   o  JSMS is pure JSON, whereas in JWE and JWS only the header
> >      parameters are represented in JSON.
> >
> >   o  JSMS allows for full algorithm agility in key agreement, while JWE
> >      only allows ECDH-ES.
> >
> >   o  JSMS supports multiple recipients for EncryptedData and
> >      AuthenticatedData objects via the inclusion of multiple WrappedKey
> >      objects.  Sending a JWE to multiple recipients requires re-
> >      encryption of the entire object for each recipient.
> >
> >   o  The signature and MAC functions of the JWS object are separated
> >      into SignedData and AuthenticatedData JSMS objects.
> >
> >   o  JSMS parameters are not integrity-protected, as they are in JWE
> >      and JWS.
> >
> >   o  The "typ" and "zip" parameters are not defined in JSMS, but could
> >      be added without significant change.
> >
> >   o  JSMS requires that recipients MUST ignore unknown header
> >      parameters, in order to facilitate extensibility.
> >
> > I've also thrown together an initial JavaScript implementation (based on
> NodeJS for some python crypto glue), which is on github:
> > <https://github.com/bifurcation/jsms>
> >
> > Comments are very welcome.
> >
> > Thanks,
> > --Richard
> >
> >
> >
> > Begin forwarded message:
> >
> >> From: [e-mail]
> >> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt
> >> Date: June 15, 2012 4:56:09 PM EDT
> >> To: [e-mail]
> >>
> >>
> >> A new version of I-D, draft-barnes-jose-jsms-00.txt has been
> >> successfully submitted by Richard Barnes and posted to the IETF
> >> repository.
> >>
> >> Filename:     draft-barnes-jose-jsms
> >> Revision:     00
> >> Title:                JavaScript Message Security Format
> >> Creation date:        2012-06-15
> >> WG ID:                Individual Submission
> >> Number of pages: 25
> >> URL:
http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-
> 00.txt
> >> Status:          http://datatracker.ietf.org/doc/draft-barnes-jose-jsms
> >> Htmlized:        http://tools.ietf.org/html/draft-barnes-jose-jsms-00
> >>
> >>
> >> Abstract:
> >>  Many applications require the ability to send cryptographically
> >> secured messages.  While the IETF has defined a number of formats for
> >> such messages (e.g.  CMS) those formats use encodings which are not
> >> easy to use in modern applications.  This document describes the
> >> JavaScript Message Security format (JSMS), a new cryptographic
> >> message format which is based on JavaScript Object Notation (JSON)
> >> and thus is easy for many applications to generate and parse.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
> >
> >
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
> 
> 
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose