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

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

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