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.

Thanks.  I remembered the "AEAD-only" agreement, but didn't know the "sender verification" term.  

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

That's exactly my point.  You can have something like JWT specify a body format that has the protected parameters, so why does JWS/JWE need integrity-protected attributes?

--Richard

> 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>>>>> Richard L. Barnes
>>>>> Sent: Monday, June 25, 2012 2:35 PM
>>>>> To: Nat Sakimura
>>>>> Cc: Mike Jones; jose@ietf.org
>>>>> 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
>>>>> <Michael.Jones@microsoft.com> 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>>>>> John Bradley
>>>>>> Sent: Wednesday, June 20, 2012 3:57 PM
>>>>>> To: Richard L.Barnes
>>>>>> Cc: jose@ietf.org
>>>>>> 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:rbarnes@bbn.com]
>>>>>> 
>>>>>>>>>> Sent: Friday, June 15, 2012 3:00 PM
>>>>>> 
>>>>>>>>>> To: Mike Jones
>>>>>> 
>>>>>>>>>> Cc: jose@ietf.org
>>>>>> 
>>>>>>>>>> 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On
>>>>>> 
>>>>>>>>>>> Behalf Of Richard L. Barnes
>>>>>> 
>>>>>>>>>>> Sent: Friday, June 15, 2012 2:08 PM
>>>>>> 
>>>>>>>>>>> To: jose@ietf.org
>>>>>> 
>>>>>>>>>>> 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: internet-drafts@ietf.org
>>>>>> 
>>>>>>>>>>>> Subject: New Version Notification for
>>>>>> 
>>>>>>>>>>>> draft-barnes-jose-jsms-00.txt
>>>>>> 
>>>>>>>>>>>> Date: June 15, 2012 4:56:09 PM EDT
>>>>>> 
>>>>>>>>>>>> To: rbarnes@bbn.com
>>>>>> 
>>>>>>>>>>>> 
>>>>>> 
>>>>>>>>>>>> 
>>>>>> 
>>>>>>>>>>>> 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
>>>>>> 
>>>>>>>>>>> jose@ietf.org
>>>>>> 
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>>>>>>>> 
>>>>>> 
>>>>>>>>>>> 
>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>> 
>>>>>>>>>>> jose mailing list
>>>>>> 
>>>>>>>>>>> jose@ietf.org
>>>>>> 
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>>>>>>> 
>>>>>> 
>>>>>>>>>> 
>>>>>> 
>>>>>>>>>> 
>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>> 
>>>>>>>>>> jose mailing list
>>>>>> 
>>>>>>>>>> jose@ietf.org
>>>>>> 
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>>>>>> 
>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>> 
>>>>>>>>> jose mailing list
>>>>>> 
>>>>>>>>> jose@ietf.org
>>>>>> 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> jose@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Nat Sakimura (=nat)
>>>>>> Chairman, OpenID Foundation
>>>>>> http://nat.sakimura.org/
>>>>>> @_nat_en
>>>>>> 
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> jose@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>> 
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>> 
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
> 