Subject: [jose] draft-manger-jose-jwsec

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Jun 2012 01:04:17 +1000

I have proposed various changes to JWS/JWE/JWT recently, but not always with specific text changes to the existing documents. So I have had a go putting the changes together as a vaguely complete draft spec. The result is:

  JSON Web Security Message Format (JWsec)
  http://tools.ietf.org/html/draft-manger-jose-jwsec-00

  Abstract:
   This document describes a cryptographic message format based on
   JavaScript Object Notation (JSON) and base-64 encodings to be easy
   for web applications to generate and process.  Signed, encrypted,
   signed-then-encrypted, and unprotected messages are supported using
   symmetric and/or asymmetric keys.

Changes from JWS/JWE/JWA/JWT:

1. The nickname JWsec is used for a message that can be signed, encrypted, or unprotected. All three modes are covered by one ABNF syntax. All three are included in the one spec.

2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot-separated base64url-encoded components, including a JSON object header.

3. Each mode can compress the input data.

4. Only uses authenticated encryption with additional data (AEAD).

5. Unrecognized header elements MUST be ignored to allow new elements to be deployed without breaking interoperability. If new elements that MUST NOT be ignored are required, then a new mode can easily be defined.

6. The initialization vector (IV) and authentication tag associated with an AEAD algorithm are prepended, and appended to the ciphertext respectively (instead of using a header element and another dot-separated component). I think this form is a slightly nicer. It encourages the IV and authentication tag lengths to be fixed for an algorithm (a slightly lazy recipient will not accept whatever length the last dot-separated mac field has). One side-effect is that the header will often remain the same for messages between two parties (no varying-per-message elements), which might aid performance in some situations.

7. The output of a key agreement algorithm is used to encrypt a random per-message AEAD key. It is not used as the AEAD key directly.

8. Defines one media type "application/jwsec", not separate ones for signed and encrypted messages.

9. Has two header elements for key identifiers: "kid", and "okid". "okid" is used to identify the originators key. You need both when using a key agreement algorithm.

10. No "typ" header element. There is a separate indicator for when one JWsec message envelopes another (eg signed-then-encrypted message).

I hope this is a useful contribution to making a great JOSE suite of specs.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 Jun 2012 12:36:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Manger, James H
> Sent: Monday, June 11, 2012 8:04 AM
> To: [email-masked]
> Subject: [jose] draft-manger-jose-jwsec
> 
> I have proposed various changes to JWS/JWE/JWT recently, but not always
> with specific text changes to the existing documents. So I have had a go
> putting the changes together as a vaguely complete draft spec. The result
is:
> 1. The nickname JWsec is used for a message that can be signed, encrypted,
> or unprotected. All three modes are covered by one ABNF syntax. All three
> are included in the one spec.
> 
> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected
(c.f.
> "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot-
> separated base64url-encoded components, including a JSON object header.
> 
> 5. Unrecognized header elements MUST be ignored to allow new elements
> to be deployed without breaking interoperability. If new elements that
> MUST NOT be ignored are required, then a new mode can easily be defined.
> 
> 6. The initialization vector (IV) and authentication tag associated with
an
> AEAD algorithm are prepended, and appended to the ciphertext respectively
> (instead of using a header element and another dot-separated component).
> I think this form is a slightly nicer. It encourages the IV and
authentication tag
> lengths to be fixed for an algorithm (a slightly lazy recipient will not
accept
> whatever length the last dot-separated mac field has). One side-effect is
that
> the header will often remain the same for messages between two parties
> (no varying-per-message elements), which might aid performance in some
> situations.

I am not sure that there will be a side-effect of a constant header as it
would still need to identify the key that is needed to decrypt the message.
If you encrypt for multiple people with a single CEK then the IV is normally
fixed for all of them anyway.

> 
> 7. The output of a key agreement algorithm is used to encrypt a random
per-
> message AEAD key. It is not used as the AEAD key directly.

(YEAH)

> 
> 8. Defines one media type "application/jwsec", not separate ones for
signed
> and encrypted messages.
> 
> 9. Has two header elements for key identifiers: "kid", and "okid". "okid"
is
> used to identify the originators key. You need both when using a key
> agreement algorithm.
> 
> 10. No "typ" header element. There is a separate indicator for when one
> JWsec message envelopes another (eg signed-then-encrypted message).

But what about using the typ header for identifying the content -- i.e. a
web token vs an XMPP or ALTO message?

Jim

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Jun 2012 20:51:51 +0100

I am against adding the prefix that winds up outside the integrity protection.

It is an un necessary and breaking change to many existing JWS deployments.

Taking the IV out of the header removes the integrity check over it and complicates parsing by JSON.

It is not using Authenticated encryption,  AEAD only adds integrity not sender authentication.

I agree that for simplicity the output of key agreement should be used to encrypt a CMK,  that adds some  more processing for key agreement,  but is overall more consistent.

We didn't do a okid because the WG was against my proposal to add static static key agreement in Paris.   If feelings have changed then it should be in.

Sorry for the short response I am traveling.

John B.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Jun 2012 12:58:40 -0700

> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. "alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot-separated base64url-encoded components, including…

yuck -- I don't see the advantage of this over it being in the header -- I have to parse the header anyway.

> 3. Each mode can compress the input data.

good

> 4. Only uses authenticated encryption with additional data (AEAD).

I'll defer to crypto heads on this one.

> 5. Unrecognized header elements MUST be ignored to allow new elements to be deployed without breaking interoperability. If new elements that MUST NOT be ignored are required, then a new mode can ea…

good

> 6. The initialization vector (IV) and authentication tag associated with an AEAD algorithm are prepended, and appended to the ciphertext respectively (instead of using a header element and another…

yuck -- I prefer having each item being dot separated. Simple to get all items parsed with one line of code. I don't like different parsing rules. We currently have dot parsing, base64URL parsing and JSON parsing.

> 8. Defines one media type "application/jwsec", not separate ones for signed and encrypted messages.

I'm indifferent -- but if one type, then "application/jwt"

> 9. Has two header elements for key identifiers: "kid", and "okid". "okid" is used to identify the originators key. You need both when using a key agreement algorithm.

I'll defer to crypto heads on this one.

-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 Jun 2012 13:13:49 -0700

> John Bradley
> Sent: Monday, June 11, 2012 12:52 PM
> To: Manger, James H
> Cc: [email-masked]
> Subject: Re: [jose] draft-manger-jose-jwsec
> 

It does not necessarily remove it from the integrity check.  This depends on
how the AEAD algorithm is defined.  The stream authenticated could be the
header || the iv || the message body so that it is still authenticated.

> 
> It is not using Authenticated encryption,  AEAD only adds integrity not
sender
> authentication.

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

> 
> I agree that for simplicity the output of key agreement should be used to
> encrypt a CMK,  that adds some  more processing for key agreement,  but is
> overall more consistent.
> 
> We didn't do a okid because the WG was against my proposal to add static
> static key agreement in Paris.   If feelings have changed then it should
be in.
is:
> > 1. The nickname JWsec is used for a message that can be signed,
> encrypted, or unprotected. All three modes are covered by one ABNF
> syntax. All three are included in the one spec.
> >
(c.f.
an
authentication tag
accept
that
> per-message AEAD key. It is not used as the AEAD key directly.
> >
> signed and encrypted messages.
> >
> > 9. Has two header elements for key identifiers: "kid", and "okid".
"okid" is

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Jun 2012 21:34:46 +0100

inline

> header || the iv || the message body so that it is still authenticated.

Yes if the iv is prepended or appended to the cyphertext that would happen however the additional parsing and potential for interop problems is not worth it.  

> is a debate if you get sender origination even with static-static key
OK if it is used as a term of art, rather than implying sender verification. 

I expect that some people are going to object to being forced to do integrity if they intend to do signing in some other way.   I personally don't see it as the end of the world. 

John B.

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 11 Jun 2012 15:48:39 -0700

+1 

- would be concerned if this was outside the integrity check
- in abstract the proposal looks fine, but I'm not sure there is enough incremental value vs cost of breaking existing deployments

-cmort

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Jun 2012 17:04:20 -0600

I'd like to avoid introducing breaking changes unless there's a very
good reason to do so. And I don't think the potential value in the
prefixing, for example, is sufficient to warrant a breaking change
(which it would be).

---

From: Edmund Jay <[email-masked]>
Date: Mon, 11 Jun 2012 17:32:36 -0700 (PDT)

+1 to avoid breaking changes to the parsing.
Whether parameters are in the header or outside, they still need to be parsed.
I prefer them packaged in the JSON header so that one call to the JSON library 
will return the JSON key/value pairs without some more processing on  non-JSON 
elements.

-- Edmund

________________________________
From: Brian Campbell <[email-masked]>
To: Chuck Mortimore <[email-masked]>
Cc: John Bradley <[email-masked]>; "Manger, James H" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Mon, June 11, 2012 4:04:57 PM
Subject: Re: [jose] draft-manger-jose-jwsec

On Mon, Jun 11, 2012 at 4:48 PM, Chuck Mortimore
<[email-masked]> wrote:
> - in abstract the proposal looks fine, but I'm not sure there is enough 
>incremental value vs cost of breaking existing deployments
>
> -cmort
>
>> We didn't do a okid because the WG was against my proposal to add static static 
>>key agreement in Paris.   If feelings have changed then it should be in.
>>
>>> I have proposed various changes to JWS/JWE/JWT recently, but not always with 
>>>specific text changes to the existing documents. So I have had a go putting the 
>>>changes together as a vaguely complete draft spec. The result is:
>>>
>>> 1. The nickname JWsec is used for a message that can be signed, encrypted, or 
>>>unprotected. All three modes are covered by one ABNF syntax. All three are 
>>>included in the one spec.
>>>
>>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is unprotected (c.f. 
>>>"alg":"none"), signed, or encrypted. The rest (as in JWS/JWE) is dot-separated 
>>>base64url-encoded components, including a JSON object header.
>>>
>>> 5. Unrecognized header elements MUST be ignored to allow new elements to be 
>>>deployed without breaking interoperability. If new elements that MUST NOT be 
>>>ignored are required, then a new mode can easily be defined.
>>>
>>> 6. The initialization vector (IV) and authentication tag associated with an 
>>>(instead of using a header element and another dot-separated component). I think 
>>>this form is a slightly nicer. It encourages the IV and authentication tag 
>>>lengths to be fixed for an algorithm (a slightly lazy recipient will not accept 
>>>whatever length the last dot-separated mac field has). One side-effect is that 
>>>the header will often remain the same for messages between two parties (no 
>>>varying-per-message elements), which might aid performance in some situations.
>>>
>>> 9. Has two header elements for key identifiers: "kid", and "okid". "okid" is 
>>>used to identify the originators key. You need both when using a key agreement 
>>>algorithm.
>>>
>>> 10. No "typ" header element. There is a separate indicator for when one JWsec 
>>>message envelopes another (eg signed-then-encrypted message).
>>>
>>>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Jun 2012 10:56:37 +1000

Responding to some comments from Dick, John, Jim and Edmund together:

>> 2. A prefix ("U.", "S.", or "E.") indicates if a message is
>> unprotected (c.f. "alg":"none"), signed, or encrypted.
 
> - I have to parse the header anyway.

With JWE/JWS there is no explicit indication of the mode (unprotected/signed/encrypted/...?) in the header. You only know the mode if you recognize an algorithm identifier value. Looking for the presence/absence of an "enc" field almost works as a hack -- but only while there are only two modes (signed & encrypted). An explicit "mode":"encrypted" header element could do the job, by a single letter visible in the outer message is nicer.
Some advantages of a explicit mode indication:
a) Top-level code that switches to decryption or signature verification module doesn't need to know alg id values.
b) Can do some input validation on data without knowing any signature algorithms. Recognizing the "S" or "U" prefix is sufficient to know the 3rd dot-separated component is the content.
c) Avoids a hack like "alg":"none" that causes a "fake" signing algorithm to be implement, which is potentially dangerous if recipients look at a resulting "signed" flag without checking the alg value.
d) Can define new modes without having to worry about how existing code might misinterpret messages, particularly if the new mode uses some of the same primitives so the same alg ids are used.
e) Developers can see at a glance if a message is signed, encrypted, or unprotected.

> I prefer them packaged in the JSON header so that one call
> to the JSON library will return the JSON key/value pairs without
> some more processing on  non-JSON elements.

Other items are already outside the JSON header: the encrypted key, the signature, the content.

> I am against adding the prefix that winds up outside the integrity

The prefix is WITHIN the integrity protection. The data that is signed, MACed, or treated as "additional data" is the prefix of the JWsec message including the initial letter indicating the mode.

>> 6. The initialization vector (IV) and authentication tag associated
>> with an AEAD algorithm are prepended, and appended to the ciphertext
>> respectively (instead of using a header element and another dot-
>> separated component). I think this form is a slightly nicer. It
>> encourages the IV and authentication tag lengths to be fixed for an
>> algorithm (a slightly lazy recipient will not accept whatever length
>> the last dot-separated mac field has). One side-effect is that the
>> header will often remain the same for messages between two parties (no

> yuck -- I prefer having each item being dot separated. Simple to get
> all items parsed with one line of code. I don't like different parsing
> rules. We currently have dot parsing, base64URL parsing and JSON
> parsing.

And UTF-8 parsing.
Splitting a byte array at a specific length is not onerous. It probably needs to be done for specific algorithms anyway (eg using a prefix of a byte array as an authentication tag; splitting a secret key block into bytes for an AES key and HMAC key).

My trigger for appending the auth tag to the ciphertext was how the Java 7 API added support for AEAD algorithms. The javax.crypot.Cipher class <http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html> added an updateAAD() method to provide the additional data, but didn't add a getAuthTag() method. Instead, the authentication tag is appended to the ciphertext. A nice feature is that apps doing encryption, but not using additional data, can switch from a "normal" encryption algorithm to an AEAD algorithm without changing the methods they call.

> I'm indifferent -- but if one type, then "application/jwt"

But "JWT" means a message whose contents in a JSON object holding claims.

> But what about using the typ header for identifying the content
> -- i.e. a web token vs an XMPP or ALTO message?

This is metadata about the data, as opposed to info about the security applied. I am not opposed to supporting this sort of metadata, and the rule that unrecognized header elements MUST be ignored makes it easy to added this or any other metadata.
I did want to split the indication of nested modes of protection (eg signed-then-encrypted) from metadata. The former is an important part of the processing for a JWsec module; the latter is only meaningful to a higher layer.
The JWT spec already repeats the "typ" element in the content (the JSON object holding claims) making duplication in the JWsec header somewhat redundant.

--
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Jun 2012 18:39:57 -0700

On Jun 11, 2012, at 5:56 PM, Manger, James H wrote:

> With JWE/JWS there is no explicit indication of the mode (unprotected/signed/encrypted/...?) in the header.

Sure there is. 
Per 5.1, the 'typ' property is RECOMMENDED to be JWT if unprotected and REQUIRED to be JWS if signed and JWE if encrypted.  

I agree "alg"="none" is funky and would suggest that "typ"="JWT" be REQUIRED in the header.

> e) Developers can see at a glance if a message is signed, encrypted, or unprotected.

This may be a useful feature, but I don't think it justifies the extra parsing. The header needs to be fully parsed to really know what is going on.

> Splitting a byte array at a specific length is not onerous. It probably needs to be done for specific algorithms anyway (eg using a prefix of a byte array as an authentication tag; splitting a secr…

I'm writing in JavaScript. The UTF-8 parsing is a non-issue for me. :) 
Splitting a byte array can be done, but is not as straightforward. :(

> My trigger for appending the auth tag to the ciphertext was how the Java 7 API added support for AEAD algorithms. The javax.crypot.Cipher class <http://docs.oracle.com/javase/7/docs/api/javax/crypt…

People still use Java? ;)

You can easily concatenate the data together for your implementation. I looked at a few JS crypto libraries and they had different parameter passing mechanisms.

> But "JWT" means a message whose contents in a JSON object holding claims.

I meant if we were going to have just one MIME type. 

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Jun 2012 11:58:16 +1000

> Per 5.1, the 'typ' property is RECOMMENDED to be JWT if unprotected and REQUIRED to be JWS if signed and JWE if encrypted.  

I don't think "typ" as per JWT 5.1 helps much [http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-00#section-5.1].

It says "in the normal case ... use of this header parameter is OPTIONAL". It tells you if the inner content is another JWE or JWS message. It doesn't tell you what the outer message  is.

--
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Jun 2012 19:33:27 -0700

> It says "in the normal case ... use of this header parameter is OPTIONAL". It tells you if the inner content is another JWE or JWS message. It doesn't tell you what the outer message  is.

Ha ha!

Now that I read it carefully, I see that you are correct and understand why you would want to signal the type of token. I think it should actually work as I described (typ is set to the type of token) and have another parameter that indicates if a JWT is embedded (emb ?). That JWT's header will then indicate if it is a JWS or JWT.

Meta data about the payload should go in the header, not a meta header.

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Jun 2012 13:05:36 +1000

> Ha ha!
> 
> Now that I read it carefully, I see that you are correct and understand
> why you would want to signal the type of token. I think it should
> actually work as I described (typ is set to the type of token) and have
> another parameter that indicates if a JWT is embedded (emb ?). That
> JWT's header will then indicate if it is a JWS or JWT.
> 

So Dick, would you prefer a signed-then-encrypted collection of claims to look something like this (ignoring the base64url encoding):

{ "typ":"JWE", "emb":true, ..alg id, key id, alg params} + enckey + ciphertext

On decrypting, the plaintext looks like:

  { "typ":"JWS", "emb":false, ..alg id, key id, alg params} + content + sig

The content itself is a JSON object:

    { "iss"..., "exp":..., "typ":"JWT" ... }
?

This provides the same info as I was after with my "[UuSsEe]." prefix.
Using header elements is perhaps slightly more consistent, but it does add about 30 bytes, removes the visual clue for developers, and makes high-level input validation (with say a regex in a Web App Firewall) harder.

If we do go with header elements (not my preference) we should ditch "typ". Its semantics have already been confused too much. Perhaps "t"?

--
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Jun 2012 20:35:33 -0700

>  { "typ":"JWS", "emb":false, ..alg id, key id, alg params} + content + sig

"emb":false could be dropped, default would be false

>    { "iss"..., "exp":..., "typ":"JWT" … }

not sure why "typ":"JWT" is in the object itself. I have been using it to indicate what the token is used for 

> Using header elements is perhaps slightly more consistent, but it does add about 30 bytes,

agree it is longer - I would rather it was longer and parsed correctly than shorter and incorrect. :)

If small size was the highest priority, we would be encoding bytes and bits. :)

> removes the visual clue for developers,

wearing my developer hat, I probably care more about the other headers when looking at a token and envision a editor tool that would decode it for me. :)

> and makes high-level input validation (with say a regex in a Web App Firewall) harder.

can you provide a use case / story where the hint that the token is U|S|E would be useful in and of itself?

> If we do go with header elements (not my preference) we should ditch "typ". Its semantics have already been confused too much. Perhaps "t"?

I think the 3 letter convention for reserved words is useful as a visual clue of what is reserved. I don't care what it is called as long as it is obvious what it does. :)

btw: thanks for the dialog!

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Jun 2012 14:05:31 +1000

> You can easily concatenate the data together for your implementation. I looked at a few JS > crypto libraries and they had different parameter passing mechanisms.

Could you share a few links to JavaScript Crypto APIs.

A quick search found sjcl <http://crypto.stanford.edu/sjcl/>.
This API seems to append the auth tag to the ciphertext, but have a separate parameter for the IV. It also makes it easy to split or join a byte array -- but perhaps it had to define its own bitArray object to do this.

What I liked most about concatenating IV, ciphertext, and tag is that the recipient needs to know the lengths of the IV and tag from the alg id. Consider Galois/Counter Mode (GCM) for instance. The NIST GCM spec allows tag lengths from 128-bits down to 32-bits. A generic crypto library implementing GCM will probably support all these lengths. It would be very easy for a JWE library to simply pass the last dot-separated field as the 'tag' parameter of a GCM decrypt() function -- without explicitly checking that it is 128-bits long as JWA requires. Concatenating the tag to the ciphertext avoids that risk.

Concatenating the IV to the ciphertext might also remove an easy implementation mistake of not checking the IV length. I am less certain of the crypto implications, though IV uniqueness seems crucial to GCM security. An IV is generally treated as an input parameter to the encryption. My gut feeling (not great to rely on for security ;-) is that it would generally be better for the "top-level" of an app to be configured with an alg id and key, while leaving it to the crypto layer to pick a random IV of the right length. That doesn't mean the IV cannot be put in the header, but it might be easier to return as part of the ciphertext.

Dick (and other implementers),
It sounds like you have written a JavaScript JOSE library. Does it implement AES GCM? Does it check the IV and authentication tag lengths? (and no cheating by adding the checks before answering ;-)

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Jun 2012 14:50:58 +1000

> U|S|E would be useful in and of itself?

It is primarily a design choice. We have a handful of top-level "types" of message (signed, encrypted, unprotected). The number of dot-separated components can vary between "type". The semantics of the nth component varies between "type". Future types may have other numbers of components and component semantics. I think the right design is to indicate the "type" at the same top-level where you see the number and size of the per-type components.

Compare to CMS (Crypto Message Syntax, RFC5652): the top level has a contentType field to distinguish Data, SignedData, EnvelopedData, EncryptedData... The actual alg ids, key ids, and metadata is held separately "lower down" in the structures.

If some point between an originator and recipient (even if just earlier in the recipient's stack) has a policy of "data must be encrypted for confidentiality" or "data must NOT be encrypted so it can be inspected" or "data must be digitally-signed" or "only signed-then-encrypted data is expected" or "confidential data is processed over there" then you have a chance of enforcing the policy by looking at the initial letter -- with barely any JOSE-specific knowledge. You can probably implement these policies with an Apache mod_alias rule. But this is a bit speculative.

--
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Jun 2012 21:53:26 -0700

> Could you share a few links to JavaScript Crypto APIs.

These are battle tested libraries:

http://code.google.com/p/crypto-js/
http://nodejs.org/api/crypto.html

> It sounds like you have written a JavaScript JOSE library. Does it implement AES GCM? Does it check the IV and authentication tag lengths? (and no cheating by adding the checks before answering ;-)

I have not yet had to implement JWE, only JWS so far. I am currently specifying JWE for a major project (and hope the spec settles!)

FYI: I recall seeing a few implementations in JS on GitHub. I know the Mozilla guys built a JS library for node.js for their BrowserID project.

-- Dick

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 12 Jun 2012 09:24:16 -0400

> Yes if the iv is prepended or appended to the cyphertext that would happen however the additional parsing and potential for interop problems is not worth it.  

What's the attack you're worried about if the IV is not integrity-protected?

--Richard

---

From: Naveen Agarwal <[email-masked]>
Date: Tue, 12 Jun 2012 14:51:39 -0700

> 2. A prefix ("U.", "S.", or "E.") indicates if a message is
unprotected (c.f.
> separated base64url-encoded components, including a JSON object header.

I don't see much value in adding a prefix as there will be two places for
similar information (will cause confusion) and people will do premature
optimization while parsing the token. A visual indicator may have been
useful if the token was for human consumption, but it is not.
Also we have this working and being used in multiple places and we would
like to avoid breaking changes unless there is a very compelling reason.

Thanks

Naveen

On Tue, Jun 12, 2012 at 6:24 AM, Richard L. Barnes <[email-masked]> wrote:

> > Yes if the iv is prepended or appended to the cyphertext that would
> happen however the additional parsing and potential for interop problems is
> not worth it.
>
>
> > I expect that some people are going to object to being forced to do
> integrity if they intend to do signing in some other way.   I personally
> don't see it as the end of the world.
> >
> > John B.
> >
> >
> >>>
> unprotected
> with

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 12 Jun 2012 15:04:00 -0700

I also don't see any value in this indication. Information such as 'S'
without the algorithm value present in the header is not actionable
information. So parsers will ignore this information and use the
header instead.

On the other hand, if the information is _not_ to be ignored, then we
introduce a whole new layer of validation. If a token is signed and
encrypted, should it be type 'S', or type 'E'? This adds no value and
creates more opportunities for interoperability issues.

On Tue, Jun 12, 2012 at 2:51 PM, Naveen Agarwal <[email-masked]> wrote:
>> >>> Taking the IV out of the header removes the integrity check over it
>> >>> and
>> >>> complicates parsing by JSON.
>> >>

-- 
--Breno

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 13 Jun 2012 10:21:18 +1000

> I don't see much value in adding a prefix as there will be two places for similar information (will cause confusion) and people will do premature optimization while parsing the token. A visual indicator may have been useful if the token was for human consumption, but it is not.

Naveen,

There will be no confusion. The prefix tells you whether you have head.data.sig or head.enckey.ciphertext or head.data or a mode your code doesn't support yet. When you get to your signature verification code you use the "alg" (or "sig") header value to instantiate the right Signature crypto class.

At the moment we already have "two places for similar information (will cause confusion)". We have two heuristics for distinguishing signed/encrypted/unprotected/other: either look at the "alg" value, or look for the presence of an "enc" element. The first heuristic fails if you don't recognize the "alg" value (at that point in your code). The second heuristic fails if we ever come up with another mode (those messages will be misinterpreted as encrypted or signed based on the presence or absence of "enc"). The first sign of failure is that the addition of "unprotected" mode required a fake signature algorithm ("alg":"none") to be defined. What do we do for the next mode?

For example, it is easy to imagine encryption that identifies a key but not an algorithm. The algorithm is implied by the key, to enforce good crypto practice of only using any given key with one algorithm. Implementing that would need hacks to avoid breaking the "alg" and "enc" heuristics.

My understanding is that Dick Hardt would now like the info provided by the prefix, but wants it in dedicated header elements. Do you not even want that, Naveen?

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 13 Jun 2012 10:44:29 +1000

> If a token is signed and encrypted, should it be
> type 'S', or type 'E'? This adds no value and

If it is signed-then-encrypted the outer structure is head.enckey.ciphertext so the prefix is "e." ("e" for encrypted message; lowercase because the plaintext is another JOSE message, which has a "S." prefix).

If it is encrypted-then-signed the outer structure is head.data.signature so the prefix is "s." ("s" for signed message; lowercase because the data is another JOSE message, which has an "E." prefix).

If we come up with a combined signed (with public/private key pair) and encrypted mode (that isn't one of the above two) then a new type/prefix would be really helpful.

--
James Manger

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 13 Jun 2012 08:57:56 +0000

I would have to agree here, still don't see a compelling reason for the change

From: [email-masked] [mailto:[email-masked]] On Behalf Of Naveen Agarwal
Sent: Tuesday, June 12, 2012 2:52 PM
To: Manger, James H
Cc: John Bradley; Jim Schaad; [email-masked]
Subject: Re: [jose] draft-manger-jose-jwsec

I don't see much value in adding a prefix as there will be two places for similar information (will cause confusion) and people will do premature optimization while parsing the token. A visual indicator may have been useful if the token was for human consumption, but it is not.
Also we have this working and being used in multiple places and we would like to avoid breaking changes unless there is a very compelling reason.

Thanks

Naveen

On Tue, Jun 12, 2012 at 6:24 AM, Richard L. Barnes <[email-masked]<mailto:[email-masked]>> wrote:
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>>> John Bradley
>>> Cc: [email-masked]<mailto:[email-masked]>

--Richard

>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Wed, 13 Jun 2012 18:46:35 +0900

+1

I'm not sure this I-D has enough advantages to adopt at this time,
especially when thinking about current deployments.
(Besides, changing syntax will be painful as an implementer.)

Tatsuya

-- 
HAYASHI, Tatsuya
Lepidum Co. Ltd.

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Sun, 17 Jun 2012 03:11:28 +0900

FYI:

W3C (and IETF?) are doing relevant work now.
  http://www.w3.org/2012/webcrypto/
  (based on Mozilla DOMCrypt)

(sorry if wrong.)

-- 
Tatsuya

On Tue, Jun 12, 2012 at 1:53 PM, Dick Hardt <[email-masked]> wrote:
> You can easily concatenate the data together for your implementation. I
> looked at a few JS > crypto libraries and they had different parameter
> passing mechanisms.
>
>
> It sounds like you have written a JavaScript JOSE library. Does it implement
> AES GCM? Does it check the IV and authentication tag lengths? (and no
> cheating by adding the checks before answering ;-)
>
>
> I have not yet had to implement JWE, only JWS so far. I am currently
> specifying JWE for a major project (and hope the spec settles!)
>
> FYI: I recall seeing a few implementations in JS on GitHub. I know the
> Mozilla guys built a JS library for node.js for their BrowserID project.
>
> -- Dick
>
>

-- 
HAYASHI, Tatsuya
Lepidum Co. Ltd.