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

[Anthony Nadalin <[e-mail]>]

Used all the time as its quicker than CBC mocde very simple if I have just 1 block of data 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Tuesday, June 26, 2012 3:40 PM
To: Anthony Nadalin; 'John Bradley'
Cc: 'Richard L. Barnes'; [e-mail]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

Under what circumstances would people use ECB?  

> -----Original Message-----
> From: Anthony Nadalin [mailto:[e-mail]]
> Sent: Tuesday, June 26, 2012 2:03 PM
> To: John Bradley
> Cc: Richard L. Barnes; Jim Schaad; [e-mail]
> Subject: RE: [jose] New Version Notification for 
> draft-barnes-jose-jsms- 00.txt
> 
> AES-ECB is also a popular alternative
> 
> -----Original Message-----
> From: John Bradley [mailto:[e-mail]]
> Sent: Tuesday, June 26, 2012 1:59 PM
> To: Anthony Nadalin
> Cc: Richard L. Barnes; Jim Schaad; [e-mail]
> Subject: Re: [jose] New Version Notification for 
> draft-barnes-jose-jsms- 00.txt
> 
> Yes that is why we added the composite HMAC + AES-CBC.   We can debate if
> that is an algorithm or mandatory integrity with non AEAD algorithms, 
> but
the
> effect of integrity protecting the header remains in both cases.
> 
> John B.
> 
> On 2012-06-26, at 4:30 PM, Anthony Nadalin wrote:
> 
> > Not sure there was a WG decision and what that would mean if there 
> > was,
> as there are many libraries out there that don't support the 
> encryption
with
> integrity algorithms, so need to support alternative means of things 
> like
key
> wrap that could have an integrity check.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf 
> > Of John Bradley
> > Sent: Tuesday, June 26, 2012 12:30 PM
> > To: Richard L. Barnes
> > Cc: Jim Schaad; [e-mail]
> > Subject: Re: [jose] New Version Notification for 
> > draft-barnes-jose-jsms-00.txt
> >
> > There was a WG decision to not allow encryption without integrity.   Jim
> and others call that sender verification.
> >
> > Or on simple terms no AES-CBC without a mandatory MAC integrity.
> >
> > The JWE/JWS specs don't control the body.   That is intended to be
arbitrary
> content.
> >
> > We do have s JWT spec that covers the body for security tokens.   The
idea
> was to separate that from signing and encryption so that signing and 
> encryption can be used for other objects.
> >
> > John B.
> >
> > On 2012-06-26, at 1:43 PM, Richard L. Barnes wrote:
> >
> >>> Now that we are mandating JWE sender verification people will be 
> >>> using
> JWE with symmetric keys or key agreement.
> >>> In those cases one can easily argue that the header should be
protected
> as much as in HMAC.
> >>
> >> Can you clarify the scope of "we are mandating"?
> >>
> >>
> >>> There may well be signing_time or other elements that would go 
> >>> into
> the header as well for JWE.
> >>
> >> Why do these need to go into the header rather than the body?
> >>
> >> --Richard
> >>
> >>
> >>
> >>
> >>> Regards
> >>> John B.
> >>>
> >>> On 2012-06-25, at 7:48 PM, Jim Schaad wrote:
> >>>
> >>>> <personal>
> >>>>
> >>>> Richard,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail] [mailto:[e-mail]] On 
> >>>>> Behalf Of Richard L. Barnes
> >>>>> Sent: Monday, June 25, 2012 2:35 PM
> >>>>> To: Nat Sakimura
> >>>>> Cc: Mike Jones; [e-mail]
> >>>>> Subject: Re: [jose] New Version Notification for
> >>>>> draft-barnes-jose-jsms- 00.txt
> >>>>>
> >>>>> Hi Nat,
> >>>>>
> >>>>> I'm not sure what X.509 fiasco you're referring to.  There was a 
> >>>>> recent
> >>>> MD5
> >>>>> fiasco [1], but that's an attack on MD5, not X.509.  In fact, 
> >>>>> there have
> >>>> been
> >>>>> recommendations for preventing this attack in X.509 since 2005 [2].
> >>>>> As
> >>>> was
> >>>>> noted on the SAAG list, the real news here is that Microsoft 
> >>>>> wasn't
> >>>> following
> >>>>> any of those recommendations.
> >>>>>
> >>>>> JWS would have had the same problem as X.509.  The attack did 
> >>>>> not modify the cryptographic parameters (anything that would 
> >>>>> have gone in the header), it would not have been thwarted by the 
> >>>>> integrity protection we're worrying about.
> >>>>>
> >>>>> Actually, the header signing that JWS does makes it even nicer 
> >>>>> for the
> >>>>> attacker: Flame used a "chosen prefix" attack, so since the JWS 
> >>>>> header
> >>>> value
> >>>>> is entirely static for a given signer, it's easy to use as a 
> >>>>> fixed
prefix.
> >>>> If JWS just
> >>>>> signed the content, then the application could include a 
> >>>>> something random up front to prevent such prefix-based attacks.
> >>>>>
> >>>>
> >>>> I don't believe that this is a true statement.  If you had a 
> >>>> prefix or just signed what was given to you (i.e. no prefix), it 
> >>>> would make no difference in terms of the attack for Flame.  Flame 
> >>>> could always use a fixed prefix of its own design rather than 
> >>>> using the fixed header that is generated by having JWS sign the 
> >>>> header
> information.
> >>>>
> >>>>> It's tempting to say that we should just add randomness to the 
> >>>>> JOSE
> >>>> format.
> >>>>> But the real lesson of the Flame/MD5 attacks is operational:  If 
> >>>>> you're
> >>>> signing
> >>>>> something that somebody else gave you, make sure that you're not 
> >>>>> signing exactly what they gave you.  Follow the recommendations 
> >>>>> of RFC 4270.  In other contexts, there's no need of similar 
> >>>>> random elements; it just adds complexity.
> >>>>
> >>>> This is definitely a true statement in all events and is 
> >>>> something that should be added to the Security Considerations section.
> >>>>
> >>>> That being said, I think that there are valid reasons for wanting 
> >>>> to protect the header information by some authentication processing.
> >>>> PKIX certificates protect the signature algorithm information (by 
> >>>> copying the data into the to be signed block) and CMS has long 
> >>>> allowed for information to be included in the signed attributes 
> >>>> area that identifies the algorithms used, the certificates used 
> >>>> and so forth.  There are also other things that we might find to 
> >>>> be convenient to be placed in the header information that is 
> >>>> current not there (a signing time and embedded content type comes 
> >>>> to mind) that would be a product either of specific types of 
> >>>> signatures or
> becomes a common attribute to be placed there.
> >>>>
> >>>> In terms of encryption operations, I remember in the past that I 
> >>>> have had either corrupted encrypted streams or corrupted IVs and 
> >>>> had a successful decryption that later generated other problems 
> >>>> when trying to parse.  This is less of an issue with AEAD 
> >>>> algorithms as they have a much stricter rule on when the stream
> decrypts correctly.
> >>>>
> >>>> Jim
> >>>>
> >>>>>
> >>>>> --Richard
> >>>>>
> >>>>>
> >>>>>
> >>>>> [1] 
> >>>>> <http://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf>
> >>>>> [2] <http://tools.ietf.org/html/rfc4270#section-5.1>
> >>>>>
> >>>>>
> >>>>> On Jun 21, 2012, at 11:11 AM, Nat Sakimura wrote:
> >>>>>
> >>>>>> 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 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-j
> >>>>>>>>>> so
> >>>>>>>>>> n
> >>>>>>>>>> -seri
> >>>>>>
> >>>>>>>>>> alization-01 and
> >>>>>>
> >>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-
> >>>>>>>>>> js
> >>>>>>>>>> o
> >>>>>>>>>> n-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
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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