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

[John Bradley <[e-mail]>]

The integrity check is not required for Key Wrap.   

At the moment AES128KW and AES256KW  are what is specified in JWA.  
Again if people want to extend the KW algs there is nothing to stop them making proposals.

Oh look it's 5:30 and I have to wash my hair.

I look forward to rejoining the debate tomorrow:)

Regards
John B.

On 2012-06-26, at 5:23 PM, Anthony Nadalin wrote:

> Because it's in most libraries and it works well for key wrap and it's in a lot of products. That's fine to discuss (and did not say it was not discussed) but I don't recall reaching a consensus on that point yet.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard L. Barnes
> Sent: Tuesday, June 26, 2012 2:20 PM
> To: John Bradley
> Cc: Anthony Nadalin; Jim Schaad; [e-mail]
> Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt
> 
> Why would you ever want to use ECB mode?  If you want something fast and parallelizable, CTR mode is a lot better.
> 
> We had discussed Dave McGrew's draft as a mechanism for specifying general AEAD algorithms:
> <http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1>
> 
> --Richard
> 
> 
> 
> 
> On Jun 26, 2012, at 5:07 PM, John Bradley wrote:
> 
>> You should suggest adding that as a supported algorithm.
>> 
>> We wanted to keep the core set down to a reasonable number to encourage interoparability.
>> 
>> AES-ECB + HMAC can be a option if the WG wants it.
>> 
>> John B.
>> On 2012-06-26, at 5:03 PM, Anthony Nadalin wrote:
>> 
>>> 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
>>>>>>>>>>>>> son
>>>>>>>>>>>>> -seri
>>>>>>>>> 
>>>>>>>>>>>>> alization-01 and
>>>>>>>>> 
>>>>>>>>>>>>> http://tools.ietf.org/html/draft-jones-json-web-encryption-
>>>>>>>>>>>>> jso
>>>>>>>>>>>>> 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
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
> 
> 
> 
> 
>