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

[Nat Sakimura <[e-mail]>]

On Sat, Jun 16, 2012 at 9:22 AM, Breno de Medeiros <[e-mail]> wrote:

> On Fri, Jun 15, 2012 at 5:07 PM, Mike Jones <[e-mail]>
> wrote:
> > 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-*.
>
> All our experience with signatures says that defining new
> canonicalization mechanisms should be avoided at all costs. Not only
> they lead to expensive interoperability issues, they may lead to
> frequent security issues.
>

+1


>
> >
> > 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-01and
> >
> 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
>
>
>
> --
> --Breno
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en