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

[Nat Sakimura <[e-mail]>]

Especially after the X.509 fiasco, I strongly believe that having integrity
check over the metadata is a good thing. It is such a little effort that
gives us much more protection down the road. In this sense, I fully agree
with Ben here. We should have integrity protection over the header.

Nat

On Thu, Jun 21, 2012 at 8:07 AM, Mike Jones <[e-mail]>wrote:

>  Two years ago when the developer community needing a JSON-friendly token
> format was designing the JSON Web Token (JWT), we explicitly asked security
> experts whether the header parameters should be integrity protected or
> not.  Among them, Ben Laurie was one of the voices saying that securing
> them was the right thing to do.****
>
> ** **
>
> He argued that if the parameters can be protected in a practical manner,
> then they should.  Doing so provides an additional hurdle that attackers
> would have to surmount.  For example, if they can try to substitute a
> weaker authentication scheme, then they must figure out how to make it
> authenticate correctly despite some plaintext they can't control – the
> header parameters.****
>
> ** **
>
> Ben also took the position that paring security protocols down to the
> least you can get away with, given attacks you can think of, is not a good
> design principle.  If there is not a strong argument against including a
> feature that may make it harder for attackers, then that feature should be
> included.****
>
> ** **
>
> I agree with him.****
>
> ** **
>
> The decision to provide integrity protection for the headers is documented
> in the session notes at http://self-issued.info/?p=361, which said:****
>
> ** **
>
> *·**  What to sign (envelope.payload or just payload)?*****
>
> Given that the envelope is extensible and therefore may contain
> security-sensitive information, we reached a consensus (with input from Ben
> Laurie <http://www.links.org/> via IM) that the combination
> envelope.payload must be signed.****
>
> ** **
>
> I believe that logic is as sound today as it was then.****
>
> ** **
>
> For all these reasons, I therefore personally stand by the community’s
> decision to provide integrity protection for the headers.****
>
> ** **
>
>                                                             Best wishes,**
> **
>
>                                                             -- Mike****
>
> ** **
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> John Bradley
> Sent: Wednesday, June 20, 2012 3:57 PM
> To: Richard L.Barnes
> Cc: [e-mail]
> Subject: Re: [jose] New Version Notification for
> draft-barnes-jose-jsms-00.txt
>
> ** **
>
> 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.****
>
> ** **
>
> On 2012-06-19, at 7:00 PM, Richard L. Barnes wrote:****
>
> ** **
>
> > 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****
>
> > ****
>
> > ****
>
> > ****
>
> > ****
>
> > On Jun 19, 2012, at 5:10 PM, John Bradley wrote:****
>
> > ****
>
> >> 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.****
>
> >> ****
>
> >> ****
>
> >> On 2012-06-18, at 10:02 PM, Richard L. Barnes wrote:****
>
> >> ****
>
> >>> 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.****
>
> >>> ****
>
> >>> ****
>
> >>>> 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-seri**
> **
>
> >>>> alization-01 and****
>
> >>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-json-ser**
> **
>
> >>>> ialization-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.****
>
> >>> ****
>
> >>> See above.  These are super-clunky, and the need to be the main focus
> of the WG, not an afterthought.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- Not supporting multiple recipients****
>
> >>>> ****
>
> >>>> 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.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- 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.****
>
> >>> ****
>
> >>> 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.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- 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!)****
>
> >>> ****
>
> >>> 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.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- 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.****
>
> >>> ****
>
> >>> 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.****
>
> >>> ****
>
> >>> ****
>
> >>>> -- 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".****
>
> >>> ****
>
> >>> 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****
>
> >>> ****
>
> >>> ****
>
> >>> ****
>
> >>> ****
>
> >>> ****
>
> >>>> ****
>
> >>>>                                                   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****
>
> >>> ****
>
> >>> _______________________________________________****
>
> >>> jose mailing list****
>
> >>> [e-mail]****
>
> >>> https://www.ietf.org/mailman/listinfo/jose****
>
> >> ****
>
> > ****
>
> ** **
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>


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