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

[John Bradley <[e-mail]>]

Sorry, I meant Authenticated Encryption from your earlier email to the list.

> 
> The AEAD algorithm class is called Authenticated encryption with additional
> data.  This is the term for the art.  Note that this does not imply sender
> origination which is the additional service one wants signatures for.  There
> is a debate if you get sender origination even with static-static key
> agreement.

I was not trying to imply identification of the sender.

Though debate or not,  people use HMAC with symmetric keys to infer sender, I suspect that they will do the same with AEAD or CBC+HMAC.

That argues for equivalent integrity protection of the header in encryption as signing, to my mind.

Sorry I got the term wrong.

John B.

On 2012-06-26, at 6:35 PM, Jim Schaad wrote:

> 
> 
>> -----Original Message-----
>> From: John Bradley [mailto:[e-mail]]
>> 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.
> 
> Jim would not call that sender verification.  Jim would call that integrity
> protection on the transmitted content.  There is no concept of data
> origination with any type of AE algorithm.
> 
> 
>> 
>> 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-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
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>> 
> 
>