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

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 21:43:33 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Friday, June 15, 2012 2:08 PM
To: [email-masked]
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: [email-masked]
> Subject: New Version Notification for draft-barnes-jose-jsms-00.txt
> Date: June 15, 2012 4:56:09 PM EDT
> To: [email-masked]
> 
> 
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 21:47:27 +0000

P.S.  I should add that since the initial discussions, many good ideas were also picked up from Eric & Joe's JSMS draft and incorporated into the JOSE specs - especially JWE and JWA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, June 15, 2012 2:44 PM
To: Richard L. Barnes; [email-masked]
Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt

Hi Richard,

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Friday, June 15, 2012 2:08 PM
To: [email-masked]
Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt

Dear JOSE WG,

Summary of differences:

Thanks,
--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jun 2012 18:00:17 -0400

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 22:31:39 +0000

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.

The JSON serialization drafts above do, again, in response to use cases presented by the working group.

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.

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!) 

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.

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:[email-masked]] 
Sent: Friday, June 15, 2012 3:00 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt

Cheers,
--Richard

---

From: Mike Jones <[email-masked]>
Date: Sat, 16 Jun 2012 00:07:52 +0000

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: [email-masked]
Subject: RE: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt

-- Not being JSON

				Best wishes,
				-- Mike

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]]
Sent: Friday, June 15, 2012 3:00 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Fwd: New Version Notification for draft-barnes-jose-jsms-00.txt

Cheers,
--Richard

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 15 Jun 2012 17:22:47 -0700

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

-- 
--Breno

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 16 Jun 2012 09:37:50 +0900

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

> > 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:
> >
> > XML Canonicalization has proven to be a horror, leading to more
> interoperability problems than any other aspect of XMLDSIG, XMLENC, SAML,
> or WS-*.
>

+1

> > 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
> >
> > Use them if you prefer if they better suit your use cases.  They could
> be adopted as working group documents, if there's interest.
> >
> > 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.
> >
> > 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!)
> >
> > 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.
> >
> > 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.)
> >
> > 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
> > 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
> >
> >
> >
> >> 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.
> >>
> >> 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:
> >>
> >> I've also thrown together an initial JavaScript implementation (based
> on NodeJS for some python crypto glue), which is on github:
> >>> URL:
> http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-00.txt
> >>> Status:
> http://datatracker.ietf.org/doc/draft-barnes-jose-jsms

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

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Jun 2012 23:17:12 -0400

+1

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 17 Jun 2012 20:19:45 -0700

<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

> Sent: Friday, June 15, 2012 5:08 PM
> To: Richard L. Barnes
> Cc: [email-masked]
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
> interoperability problems than any other aspect of XMLDSIG, XMLENC,
> SAML, or WS-*.
> 
> We chose #2. :-)
> 
>                                 -- Mike
> 
> 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
> 
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
> Use them if you prefer if they better suit your use cases.  They could be
> adopted as working group documents, if there's interest.
> 
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.
> 
> 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
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.
> 
to
> JSON.
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.
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
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".
current
> JW* specs are deficient in several ways, e.g.:
> -- Not being JSON
> 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
> 
> 
> 
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
> >
> > 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:
> >
> > I've also thrown together an initial JavaScript implementation (based on
> NodeJS for some python crypto glue), which is on github:
http://www.ietf.org/internet-drafts/draft-barnes-jose-jsms-
> 00.txt

---

From: Richard L. Barnes <[email-masked]>
Date: Mon, 18 Jun 2012 22:02:44 -0400

Hey Mike,

Thanks for having some back-and-forth with me on this.  I think this is a good discussion to have right now.  I would like to discuss some high-level points, and then I'll respond inline to your precise points.

tl;dr: In order to meet its deliverables, the WG needs to define JSON-based formats for integrity and confidentiality protections.  JWE and JWS don't fit that requirement, so we should re-consider their adoption and call for new candidates.

Major points:
1. JOSE is JSON
2. JSON does not imply canonicalization
3. Compactness and URL-safeness are still OK, as derivatives

Part 1: JOSE is JSON

The JOSE WG charter calls out four deliverables, three of which are explicitly required to be JSON:
-- "JSON-structured integrity protection"
-- "JSON-structured encryption"
-- "public keys as JSON-structured objects"
(The fourth is just a list of algorithms, which should be JSON as well, just as RFC 3370 is ASN.1.)

In light of these requirements, JWE and JWS are clearly not suitable candidates to fulfill the working group's milestones.  (At least in their current form.)  So ISTM that we need to step back and re-evaluate alternatives for the three above milestones, especially the first two.  (JWK is not as far off.)

As JSON-based mechanisms, though, the "JSON serialization" drafts are pretty half-hearted.  Because JWS and JWE include the cryptographic parameters within the integrity protection, they have to have the headers included as base64-encoded strings.  That obviously adds a lot of complexity to encoding and decoding -- for example, you have to keep the encoded header around even after you've decoded it! -- and just plain more octets.  The support for multiple recipients and multiple signatures is both unweildy (matching up parallel indices for headers and signatures) and inefficient (multiple integrity check values in encrypted objects).

By contrast, JSMS takes advantage of the cryptographic wisdom that went into CMS, while making the syntax pure JSON and as simple as possible.  Multiple signatures and multiple recipients are supported with absolute minimum overhead.  So I think it's worth consideration by the working group.

Part 2: JSON !=> canonicalization

I would like to dispel the myth that a JSON-based format requires canonicalization.  In JWE/JWS, the JSON header requires "canonicalization" (via base64url encoding) because it's included within the integrity protection.  I'm not aware of any reason for including the cryptographic parameters in the integrity check, instead of only integrity-protecting the content itself.  Indeed, if there were an attack based on non-integrity-protected cryptographic parameters, it would be a pretty big deal, since neither CMS nor IKE nor provides this protection.  (TLS does provide a signature over the algorithms, but only as a way to bind the public key to the session.)

Indeed CMS doesn't require canonicalization at all, except for attributes that are included in the protected content (signedAttrs / authenticatedAttrs), which need to be DER-encoded.  In JSMS, we don't allow those parameters, so there is no need for canonicalization at all.  All the "canonicalization" that's needed is to base64url-encode the protected content.  In that regard, JSMS is even simpler than JWE/JWS.

Part 3: Compactness and URL-safeness are still OK, as derivatives

I have absolutely no objection to defining a compact, URL-safe format.  Indeed, I did so in the JSMS draft, in Section 5.  Encoding the example from Section 3.1 of the JWS spec, we get the following JSMS object:

{ 
    "v":1,
    "t":"au",
    "a":"hs256",
    "c":"eyJpc3MiOiJqb2...0cnVlfQ",
    "mac":"pwM0gJNMLFxn8G1-juQFLrJtMEOR8_FeKIH3wIM_OAo",
    "ki":"rSIilRk8Ego"
}

If we remove the decorative spaces and base64url-encode, we only use 88 octets more than JWS (267 vs. 179).  If we take this a step further and define an explicit compact format for AuthenticatedData, we can emulate JWS by moving the content and MAC fields outside and dot-combining.  That avoids double-base64url-encoding, and only takes up 11 more octets than a JWS (190 vs 179).  (I've put the code to generate these in the Github project linked earlier.)

So it's fine to have a compact, URL-safe format for an objective, but it makes *much* more sense to derive that from a full-size, usable, JSON format than the other way around.

Responses to specific points inline below.

> Use them if you prefer if they better suit your use cases.  They could be adopted as working group documents, if there's interest.

See above.  These are super-clunky, and the need to be the main focus of the WG, not an afterthought.

> The JSON serialization drafts above do, again, in response to use cases presented by the working group.

See above.  Because of the unnecessary inclusion of the header in the integrity check, this is far less efficient than it should be.

> 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 pract…

It's important if you want to do MACs with anything other than pre-shared keys.  If you want to do anything more advanced, you need to have wrapped keys, in which case an object with a MAC starts to look a lot more like a JWE than a JWS.

> Ubiquitous deployment and usefulness trump theoretical completeness.  (Just look at XMLDSIG and XMLENC to understand that!) 

I agree that we need to find a reasonable MTI.  The current JSMS draft doesn't really specify which parts are MTI, beyond basic things like base64url encoding and ignoring unknown fields.

My main concern is that JWS and JWE don't really tell me which fields need to be present for which use case.  If I'm putting a MAC on a JWS vs. a signature, do I need "jwk" or "jku" fields to be populated?  Whereas in JSMS, I think these things are much clearer due to the separation of the use cases (Signed/Authenticated/Encrypted) and the isolation of signatures and wrapped keys into sub-objects.

> 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 descripti…

I actualy don't have a hugely urgent requirement here either.  It's something that others in the WG had requested, which is trivial to add in JSMS, but not in JWE/JWS -- again because of the unnecessary integrity protection of the header.

> I'm not religious about not having a version number field, but often "less is more".

Indeed, I'm not religious either.  It just seems like a general good idea to state this directly as opposed to having parsers divine it based on which fields are present.  To quote RFC 5652:
"
   Each of the major data structures includes a version number as the
   first item in the data structure.  The version numbers are intended
   to avoid ASN.1 decode errors.  Some implementations do not check the
   version number prior to attempting a decode, and if a decode error
   occurs, then the version number is checked as part of the error
   handling routine.  This is a reasonable approach; it places error
   processing outside of the fast path.  This approach is also forgiving
   when an incorrect version number is used by the sender.
"

Best,
--Richard

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 19 Jun 2012 15:22:33 +0000

That is certainly a unique interpretation, which I would have to disagree with based upon the charter, as the charter does state as you point out "JSON-structured" and not "JSON-based". I'm still struggling to understand your issues with the current drafts.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L.Barnes
Sent: Monday, June 18, 2012 7:03 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

Hey Mike,

Major points:
1. JOSE is JSON

Part 1: JOSE is JSON

{ 
    "v":1,
    "t":"au",
    "a":"hs256",

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

Best,
--Richard

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 19 Jun 2012 11:39:34 -0400

Not to rat-hole on semantics, but I have a hard time reading "JSON-structured" as meaning something other than "compliant with RFC 4627".  And JWS/JWE objects are not.

To again try to summarize major issues with the current drafts:

1. They're not JSON, thus not responsive to the charter

2. They include cryptographic parameters under integrity protection, which means:
2.1. They essentially preclude a pure JSON encoding, unless there is JSON canonicalization
2.2. It is very inefficient for them to support things like multiple recipients 

As a result of the above, they're very difficult to use for anything but the simplest use cases.  

My proposal would be for the WG to start from a format that (1) is JSON, and (2) has simpler cryptographic processing.  From there, we can profile down to something simpler, that looks more like JWE/JWS.  Existence proof is below.

--Richard

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Jun 2012 17:10:21 -0400

Hi Richard,

Originally we only integrity protected the header for signing.  We added the integrity protection to encryption as part of AEAD, as encryption can also be used for sender verification.

I understand the argument that it makes things simpler if we don't integrity protect the header information.

However xmldsig,  provides integrity over those elements to prevent possible downgrade attacks by manipulating the algorithms.   

CMS may not typically provide that integrity protection but I think Jim Schaad and Sean Terner created RFC5752 to address downgrade attacks.
Given they are on this list they can speak to their view on integrity over the crypto parameters.

I also recall when working on InfoCards there was a Monte Carlo/Brown Bag attack that needs to be considered if we move to something more like a detached signature.

The other design consideration is that we wanted to be able to sign arbitrary byte strings not just JSON.   You could sign XML if you wanted. 
That prevented us from including meta-data in the body as we didn't want to touch it.   That left us with the header to include additional elements in.  
Not integrity protecting those elements as well would be a problem.  

I am not a CMS expert but I believe it allows for signing of arbitrary attributes not unlike the current JOSE spec.

Especially for something that will be used with JWT security tokens I will have a hard time making the argument to NIST and others that need to approve this format that not integrity protecting the header parameters is appropriate defence in depth, for something that might be replacing signed SAML assertions in some applications.

I do understand how not integrity protecting the header will make some things easier, however I can't agree that the benefit outweighs the disadvantages.

Regards
John B.

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Jun 2012 17:19:21 -0400

Sorry I included the wrong link for the Monte Carlo/Brown Bag attack. This is a paper better explaining it. http://domino.research.ibm.com/library/cyberdig.nsf/papers/73053F26BFE5D1D385257067004CFD80/$File/rc23691.pdf

Regards
John B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 19 Jun 2012 19:00:01 -0400

Hey John,

Interesting points, but I don't think they actually apply here.

With regard to downgrade attacks: 

The attack that RFC 5752 is concerned with is when an attacker strips signatures from a signed message, so that the only ones left are ones he can tamper with.  So the integrity protection here is "horizontal"; it goes across signatures.  The integrity protection in JWS/JWE is "vertical" -- it only protects one signer's parameters -- so it is, so to speak, orthogonal.

With regard to "brown bag" attacks:

The root of this attack is ambiguity about what content is *signed* vs. what content is *used*.  If an application doesn't verify that it's actually using the stuff that's signed, then it can be tricked into accepting something unsigned. (Cf. <http://en.wikipedia.org/wiki/Confused_Deputy>)  

However, I don't think any of the current proposals have that problem.  In JWE/JWS, the signed content is right there between the dots, and in JSMS, it's in the "content" element.  The current JSMS draft does allow detached signatures, but with a "voids your warranty" sticker on it.

In any case, these attacks have nothing to do with whether the cryptographic parameters are integrity-protected with the content.  The example attacks in the IBM still work regardless -- the whole point of the attack is that the cryptographic processing is the same, only the (non-crypto) matching of content is flawed.

With regard to "arbitrary attributes":

We can have that here, too, but you need canonicalization.  And base64-encoding is not not canonicalization -- it just waves its hands over the question of equivalence.  In my opinion, we should keep the cryptographic object simple by disallowing attributes, and push the attributes you would sign inside of the thing being signed.  If people really do want attributes, it doesn't seem to me like JSON canonicalization is very hard.  I can do it in 19 lines of python: 
<http://pastebin.com/ptUfn0c3>

With regard too "meta-data in the body":

It seems to me like if we're trying to define a general format for applying security protections, then we ought to keep out things that aren't strictly security relevant.  Those things can go in application-specific content types (e.g., SAML) without polluting the general purpose header.  

With regard to "defense in depth" and selling this to government agencies:

CMS, via S/MIME, is in broad use across multiple federal agencies and large enterprises.  JSMS is essentially a profile of CMS (see Section 7), and has the same security properties.

Cheers,
--Richard

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 19 Jun 2012 16:08:05 -0700

> However, I don't think any of the current proposals have that problem.  In JWE/JWS, the signed content is right there between the dots, and in JSMS, it's in the "content" element.  The current JSMS…

There is no point of defining a security mechanism with a *void*
warranty. It's harmful.

-- 
--Breno

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 19 Jun 2012 19:15:13 -0400

> There is no point of defining a security mechanism with a *void*

Heh, that's the story of XML-DSig in a nutshell.

Seriously, what I meant to say was that to cover the "Brown bag" risks, the document just needs to say something like, "if your application uses JOSE as a detached signature, then you need to make sure that the content that's used is the content that was signed."  JSMS does that currently, to an extent, but could be stronger.

The only way you get around that is to disallow detached signatures, which I think is probably not something we want to do, given the large number of use cases that would rule out.  (E.g., anything resembling S/MIME)

--Richard

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Jun 2012 18:57:26 -0400

Hi Richard,

While for PKCS 1.5 the hash algorithm is baked into the padding and not susceptible to modification with ECDH or RSA-PSS it is not.
There are possible hash truncation attacks by shortening SHA256 to SHA224 as an example (I know we preclude truncated hashes at the moment).

The bad feeling I get around this is that if there is a scenario where the attacker controls the plaintext to be signed and there is no signer controlled text contributed there are potential bad things that could happen down the road.

This bit us with x509 certs not that long ago (yes with MD5 admittedly) where the attacker could use a certificate extension to include extra data and cause a pre collided hash to be generated.
Having part of the signed data outside the control of an attacker is a good thing.  (having a nonce or message ID in the envelope is possible though not yet required in JWS.)

I am still of the opinion that putting the base64 encoded envelope inside the hash calculation is a valid way to allow additional attributes.  
Another structure to hold the attributes adds more complexity,  as would saying that they need to be inside the signed object.

I think part of this is that as one of the openID Connect authors I look at this as a necessary security token format, for OAuth and Connect.  
For that simple processing with one signature is a high priority for adoption.

From a general signing/encrypting of documents point of view you legitimately have different priorities.

I know it is hard to prove a negative but It is also going to be difficult for me to go back to security people at google Facebook and other places and explain how not integrity protecting the header could be better than integrity protecting it.

It seems that I would be reduced to arguing that this is no worse than CMS and that hasn't been proven insecure yet.   

Allowing a possible attacker to control the hash output, and not integrity protecting the additional data, seems like something I am bound to regret in the future.

Regards
John B.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 21 Jun 2012 09:46:44 -0600

> For that simple processing with one signature is a high priority for adoption.

+1.

A simple JSON friendly model supporting a single signature over the
entire message (including headers) is an important case for adoption
(and security). JWS provides that now and there are already numerous
interoperable JWS implementations available or in the works.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jun 2012 17:53:05 -0400

> interoperable JWS implementations available or in the works.

I'm not sure how people think that integrity-protecting the header makes things *simpler*, especially since it adds a whole new decoding step and makes the parsing more complicated.

Pseudocode without integrity protection (assuming JSMS format, but JWS could be made to look similar):
function verify(json) {
    jose = JSON.parse(json);
    // Check algorithm values 
    return Crypto.SignatureAlgorithm.verify(jose.content, jose.keys[0].signature, jose.keys[0].key);
}

Pseudocode with integrity protection (assuming JWS format):
function verify(jws) {
    (txtHeader, content, signature) = jws.split("\.");
    protectedBody = header + "." + content
    jsonHeader = base64url.decode(txtHeader);
    header = JSON.parse(jsonHeader);
    return Crypto.SignatureAlgorithm.verify(content, signature, header.jwk);
}

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jun 2012 17:55:21 -0400

>    return Crypto.SignatureAlgorithm.verify(content, signature, header.jwk);

Err, sorry, that should read:
    protectedBody = txtHeader + "." + content;
and 
    return Crypto.SignatureAlgorithm.verify(protectedBody, signature, header.jwk);

See how hard it is to get right?  :)

--Richard

---

From: Brian Campbell <[email-masked]>
Date: Tue, 26 Jun 2012 10:16:36 -0600

I wasn't suggesting that integrity-protecting the header itself makes
things simpler. Rather that a desirable goal is for support of a
relatively simple model utilizing a single signature over the whole
message. And that we already have that in JWS.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 13:46:10 -0400

I agree with that goal!  I disagree that JWS is a good solution.  

It is true that JWS provides a relatively simple mechanism for a single signature, but:
1. It could be simpler (see below)
2. JWS header protection is useless for the single-signature case, and makes the multiple-signature/recipient case harder

--Richard