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

["Richard L. Barnes" <[e-mail]>]

> 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