Jim Schaad | 13 May 2013 21:46

Interium Minutes

<Chair>

 

Sorry for the delay in getting these out, I have had network issues which prevented me from doing so earlier.

 

The Minutes are now available at http://www.ietf.org/proceedings/interim/2013/04/29/jose/minutes/minutes-interim-2013-jose-1

 

Note that we are looking to hold a next virtual interim sometime during mid-June.  Probably the week of June 17 if memory serves.

 

 

Jim

 

_______________________________________________
jose mailing list
jose <at> ietf.org
https://www.ietf.org/mailman/listinfo/jose
Samuel Erdtman | 12 May 2013 00:10
Picon

Comment on typ and cty

Hi
I have just read through all the JOSE drafts and it has been a pleasure, well done!

I would like to try to contribute with a suggestion. you might already have thought of this, if so please tell me (I have not looked through the mailing list archive in detail).

When I read the drafts I think that it is confusing how to determine that we are looking at a JWT, JWE, JWS or JWK (maybe not so much the last one). I know that I can read about this in section "4. JWE Header" in the JWE specification but that is derived information i.e. interpretation of the values (alg) to get the type. I would like to make more use of the typ header in JWE/JWS and in the JWT move it form the header to the body. Then I would like to make the use of cty header in JWE/JWS mandatory, since they always have content. For the JWT I think we should remove cty, since it does not have any content, the JWT is content. By removing typ and cty from JWT header the JWT would have no header in it self. By doing this it would be easy to detect the type by looking at the typ value and the cty value to get the type of the unpacked content. I think this would simplify the implementations. I also think this would simplify how to look at the JWT if it has no header since it is not really needed, and last but not least {"alg":"none"} could be removed, since it could be done by sending a JWT without a header. This was a quick explanation I will try to flesh it out a bit to make it simpler to follow.

First I think that it is confusing that the JWT has a header. The attributes in the JWT header are typ and cty. Where cty is not recommended to use (in normal cases) and typ would be more suitable in the body. if typ would be moved to the body the head could identify the JWE/JWS instead, now it looks like this for the JWT and the if it is a JWE or a JWS has to be derived form alg:
{"typ":"JWT",
 "alg":"HS256"}
From my perspective it would be clearer if it looked like this:
{"typ":"JWS",
 "cty":"JWT",
 "alg":"HS256"}

For unsigned and unencrypted JWT it seems like the current construct has forced the {"alg":"none"} solution. If the JWT would just be a set of attributes including {"typ":"JWT"} that construct would not be needed. An unsigned and unencrypted JWT could look like this, simply no header:
.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.

Nesting a signed and encrypted JWT could look like this:
Most outer header:
{"typ":"JWE",
 "cty":"JWS",
 "alg":"RSA-OAEP",
 "enc":"A256GCM"}
Next header:
{"cty":"JWT",
 "alg":"HS256"}
Then there is just the JWT within the JWS, e.g.:
{"iss":"joe",
 "exp":1300819380,
By doing it this way it is simple to look at the first layer and see that it is a JWE (on the typ), decrypt it and do all the verifications. When starting to process the second layer we know it is a JWS that we will process (possible a JWS-JS) since it was mentioned in the outer layer by cty. Finally when we have verified the JWS we know that the content is a JWT so we know how to parse it before we start. As you can see typ is only needed for the most outer layer then the cty will describe the next layer.

To summarise the changes
* Add typ to JWT body to be used when there is a unsigned and unencrypted JWT
* Make cty REQUIRED in JWS and JWE since they will always have content
* Make typ REQUIRED for the outer most JWE or JWS, If it is just a JWT make it mandatory for it.
* Remove header from JWT, the typ has been moved to the body and the cty is not needed.
* Remove {"alg":"none"}

If you think this would be a good change I could create diff with the changes.

Best Regards
Samuel Erdtman
_______________________________________________
jose mailing list
jose <at> ietf.org
https://www.ietf.org/mailman/listinfo/jose
Gravatar

Re: Draft -10 of the JOSE Specifications

I just released a new version of the Nimbus JOSE+JWT library that
complies with the latest -09/-10 drafts and I'm quite pleased with the
results. Thanks for the good work in breaking down the authenticated
AES/CBC encryption into clear steps and supplying useful test vectors
for that. That helped coding and verification a lot.

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir <at> nimbusds.com

-------- Original Message --------
Subject: [jose] Draft -10 of the JOSE Specifications
From: Mike Jones <Michael.Jones <at> microsoft.com>
Date: Fri, April 26, 2013 9:24 am
To: "jose <at> ietf.org" <jose <at> ietf.org>

  Based upon working group feedback on the -09 drafts, I’ve released
an update to the JSON Object Signing and Encryption (JOSE)
specifications that changes the processing rules for JWEs encrypted to
multiple recipients.  The new processing rules enable using AES GCM for
multiple-recipient JWE objects.  This update makes no changes to the
single-recipient case.

 The updated specification versions are:
  ·       
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-10
  ·       
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-10
  ·        http://tools.ietf.org/html/draft-ietf-jose-json-web-key-10
  ·       
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10

 HTML formatted versions are also available at:
  ·       
http://self-issued.info/docs/draft-ietf-jose-json-web-signature-10.html
  ·       
http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-10.html
  ·       
http://self-issued.info/docs/draft-ietf-jose-json-web-key-10.html
  ·       
http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-10.html

                                                             -- Mike

 P.S.  Also posted at http://self-issued.info/?p=1012.

 
_______________________________________________
jose mailing list
jose <at> ietf.org
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose <at> ietf.org
https://www.ietf.org/mailman/listinfo/jose
Mike Jones | 8 May 2013 00:25
Picon
Favicon

FW: Draft write-up of discussion on JSON Serialization with some non-protected fields

FYI, this note had previously been sent to the JOSE interim working group meeting participants.  It discusses the correspondences between the agreed-upon JSON Serialization and Compact Serialization formats and how to transform one into the other.

 

                                                            -- Mike

 

From: Mike Jones
Sent: Wednesday, May 01, 2013 12:37 PM
To: Jim Schaad; John Bradley; Richard Barnes
Cc: Pete Resnick; Sean Turner; Matt Miller; Joe Hildebrand; Peter Saint-Andre; Brian Campbell; Karen O'Donoghue; Eric Rescorla; Hannes Tschofenig
Subject: RE: Draft write-up of discussion on JSON Serialization with some non-protected fields

 

A transformation from JWS and JWE objects using the compact serializations to ones using the JSON Serialization is always possible as simple syntactic transformation.  The transformation from the compact JWS “hdr.msg.sig” into a JSON-serialized JWS is:

 

  {"protected":"hdr",

   "signatures":[{"signature":"sig"}],

   "payload":"msg"

  }

 

The transformation from the compact JWE “hdr.ekey.iv.ct.tag” into a JSON-serialized JWE is:

 

  {"protected":"hdr",

   "recipients":[{"encrypted_key":"ekey"}],

   "initialization_vector":"iv",

   "ciphertext":"ct",

   "authentication_tag":"tag"

  }

 

Transformations from JSON Serializations for single recipients into the Compact Serializations are always possible.  When the “header” fields (containing unprotected header parameter values) aren’t used, the transformation is purely syntactic – being the inverse of those above.

 

When “header” fields are used, the contents of their JSON objects are merged into the “protected” header object contents, with the resulting merged header contents being used as the header for the compact serializations.  For instance, this JWE:

 

  {"protected":"base64url(“{"enc":"A128GCM"}”)",

   "header":{"kid":"3"},

   "recipients":[

    {"header":{"alg":"A128KW"},

     "encrypted_key":"ekey"}],

   "initialization_vector":"iv",

   "ciphertext":"ct",

   "authentication_tag":"tag"

  }

 

Would use this header value in the compact serialization:

 

  base64url(“{"enc":"A128GCM","kid":"3","alg":"A128KW"}”)

 

The rest of the JSON serialization -> compact serialization is purely syntactic, and as above.

 

By design, a transformation from a multi-recipient JWE or multi-signature JWS to the compact serializations is not possible.

 

                                                            -- Mike

 

From: Mike Jones
Sent: Wednesday, May 01, 2013 10:54 AM
To: John Bradley; Richard Barnes
Cc: Jim Schaad; Pete Resnick; Sean Turner; Matt Miller; Joe Hildebrand; Peter Saint-Andre; Brian Campbell; Karen O'Donoghue; Eric Rescorla; Hannes Tschofenig
Subject: RE: Draft write-up of discussion on JSON Serialization with some non-protected fields

 

Yes, that was the agreement.  I can write up the transformation rules once my flight finished de-icing and is under way.

-- Mike

From: John Bradley
Sent: 5/1/2013 11:50 AM
To: Richard Barnes
Cc: Jim Schaad; Mike Jones; Pete Resnick; Sean Turner; Matt Miller; Joe Hildebrand; Peter Saint-Andre; Brian Campbell; Karen O'Donoghue; Eric Rescorla; Hannes Tschofenig
Subject: Re: Draft write-up of discussion on JSON Serialization with some non-protected fields

For compact, I thought we agreed to put all the headers in the authenticated header segment and only send that. 

 

Are you referring to having to merge the protected and unprotected headers?

 

John

Sent from my iPhone


On 2013-05-01, at 9:14 AM, Richard Barnes <rlb <at> ipv.sx> wrote:

I started working on this last night.  It's not completely trivial, but it can be done.  I'll try to write it up on the plane on the way home.

 

On Wed, May 1, 2013 at 10:42 AM, Jim Schaad <ietf <at> augustcellars.com> wrote:

If you have a single recipient with protected data, I would like to see an example of this combined with the transformation logic to the compact case.

 

Can either of you provide this?

 

Jim

[SNIP]

 

_______________________________________________
jose mailing list
jose <at> ietf.org
https://www.ietf.org/mailman/listinfo/jose
Richard Barnes | 7 May 2013 19:24

Fwd: New Version Notification for draft-barnes-jose-key-wrapping-01.txt

Revised proposal on key wrapping, incorporating feedback from the interim.
Comments welcome!
Thanks,
--Richard

---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Mon, May 6, 2013 at 2:15 AM
Subject: New Version Notification for draft-barnes-jose-key-wrapping-01.txt
To: Richard Barnes <rlb <at> ipv.sx>



A new version of I-D, draft-barnes-jose-key-wrapping-01.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Filename:        draft-barnes-jose-key-wrapping
Revision:        01
Title:           Proposed Refactoring of JOSE to Align Encryption and Key Wrapping
Creation date:   2013-05-06
Group:           Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-barnes-jose-key-wrapping-01.txt
Status:          http://datatracker.ietf.org/doc/draft-barnes-jose-key-wrapping
Htmlized:        http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-barnes-jose-key-wrapping-01

Abstract:
   The discussions around key wrapping in the JOSE working group have
   raised new requirements for wrapped keys, namely: (1) Wrapping keys
   other than symmetric keys, (2) cryptographically binding attributes
   to keys, and (3) allowing the use of AEAD cryptographic algorithms
   for key wrapping (other than AES-KW).  This document proposes a
   refactoring of the JOSE document set that provides a cleaner
   conceptual structure for JWS / JWE and transparent support for
   wrapped keys, all with a relatively minor impact on the compact form
   of JWS and JWE objects.




The IETF Secretariat


_______________________________________________
jose mailing list
jose <at> ietf.org
https://www.ietf.org/mailman/listinfo/jose
Gravatar

Bad JWE header example in spec version 10

Hi guys,

Just noticed that the example JWE header in section 3.2 uses the old
"A128CBC+HS256" identifier:

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-10#section-3.2

Cheers,

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir <at> nimbusds.com
Richard Barnes | 7 May 2013 11:08

Selective header protection

Dear JOSE WG,

[This will be better covered by the chair's minutes from the interim, but I wanted to go ahead and post a summary so that related key wrapping discussion can happen.]

One of the topics discussed at the JOSE interim was how to deal with header integrity for multiple recipients.  There was agreement in the room to proceed with a strategy of removing some header parameters from integrity protection -- especially per-recipient parameters.

At a high-level, the change to the syntax is as follows:
-- For JWE, header parameters may be included at the top level of a JWE-JS or within the "recipients" objects
-- Unprotected parameters are expressed as a JSON dictionary under the "header" parameter
-- Protected parameters are base64-encoded and included under the "protected" parameter

Thus, for example, a JWE might have the following form:
{
    "protected": "eyJlbmMiOiJBMTI4R0NNIn0K",
    "recipients": [{
        "header": { "alg": "A128KW", "kid": "42" },
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}

A complete set of examples is included below.  Comments welcome!

One area where comments would be especially helpful is the compact serialization.  In the examples below, there are two proposed compact serializations based on the new format.  Variant 1 maps "global" parameters and "recipient" parameters to separate base64url-encoded parts.  Variant 2 combines them into a single dictionary.  On the one hand, Variant 1 maps more simply to the JSON format; on the other hand, Variant 2 keeps the same number of components as the current compact serialization.

Thanks,
--Richard


// Examples:
// 1. Current JWE-JS format
// 2. Proposed JWE-JS format
// 3. Simple example of proposed JWE-JS format
// 4. Current JWS-JS format
// 5. Proposed JWS-JS format
// 6. Proposed JWE-compact format (variant 1)
// 7. Proposed JWE-compact format (variant 2)


// JWE-CURRENT
// header = base64({"alg":"A128KW","enc":"A128GCM","kid":"42"})
{
    "recipients": [{
        "header": "eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiNDIifQo",
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"    
}


// JWE-PROPOSED
// protected = base64({"enc":"A128GCM"})
{
    "header": { "typ": "JWE" },
    "protected": "eyJlbmMiOiJBMTI4R0NNIn0K",
    "recipients": [{
        "header": { "alg": "A128KW", "kid": "42" },
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}

// JWE-PROPOSED-SUPER-SIMPLE
// Single recipient, no protected parameters
{
    "header": { 
        "typ": "JWE",
        "alg": "A128KW",
        "enc": "A128GCM",
        "kid": "42"
    },
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}


// JWS-CURRENT
// header = base64({"alg":"RS256","kid": "42"})
{
    "payload": "4_0ZISMX1I8xmdPTeBi6eg",
    "signatures": [{
        "header": "eyJhbGciOiJSUzI1NiIsImtpZCI6ICI0MiJ9Cg",
        "signature": "3Hu6Av79mEzu6...NcF16ls8gJDe2OmSY"
    }]
}


// JWS-PROPOSED
// protected = base64({"alg":"RS256"})
{
    "payload": "4_0ZISMX1I8xmdPTeBi6eg",
    "signatures": [{
        "header": { "kid": "42" },
        "protected": "eyJhbGciOiJSUzI1NiJ9Cg",
        "signature": "3Hu6Av79mEzu6...NcF16ls8gJDe2OmSY"
    }]
}

// JWE-PROPOSED-COMPACT-1
// protected = base64({"typ":"JWE","enc":"A128GCM"})
{
    "protected": "eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIn0K",
    "recipients": [{
        "header": {"alg":"A128KW","kid":"42"},
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}
=====COMPACT====
 eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIn0K
.eyJhbGciOiJBMTI4S1ciLCJraWQiOiI0MiJ9Cg
.w_6lbR8WRO0-pxm3MyEXmg
.vKjNIAhMfYW3zq-TikHfXQ
.PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03
.Zurj775FrQgnI-EPZmbUCg

// JWE-PROPOSED-COMPACT-2
// Header parameters from single recipient header folded into base header
// protected = base64({"typ":"JWE","enc":"A128GCM","alg":"A128KW","kid":"42"})
{
    "protected": "eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiQTEyOEtXIiwia2lkIjoiNDIifQo",
    "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}
=====COMPACT====
 eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiQTEyOEtXIiwia2lkIjoiNDIifQo
.w_6lbR8WRO0-pxm3MyEXmg
.vKjNIAhMfYW3zq-TikHfXQ
.PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03
.Zurj775FrQgnI-EPZmbUCg

_______________________________________________
jose mailing list
jose <at> ietf.org
https://www.ietf.org/mailman/listinfo/jose
Sean Turner | 7 May 2013 10:26

jose wg recharter redux

We had two more blocks on our recharter efforts.  A revised charter has 
been posted.  If you use the datatracker and the history tab you can 
compare the versions of the charter:

http://datatracker.ietf.org/doc/charter-ietf-jose/history/

The were also some questions about the dates in the milestones.  Here 
are the updated dates.  You'll note that I would like to wglc the use 
cases and requirements document in July.  The point being that this wglc 
will flush out folks who said they can't use jose.

Goals and Milestones

Done Submit JSON object integrity document as a WG item.
Done Submit JSON object encryption document as a WG item.
Done Submit JSON key format document as a WG item.
Done Submit JSON algorithm document as a WG item.
Done Submit JSON use cases and requirements document as a WG item.
Jun 2013 Submit JSON private and symmetric key document as a WG item.
Jun 2013 Submit JSON private and symmetric key protection document as a 
WG item.
Jul 2013 WGLC JSON use cases and requirements document.
Oct 2013 WGLC JSON object integrity document.
Oct 2013 WGLC JSON object encryption document.
Oct 2013 WGLC JSON key format document.
Oct 2013 WGLC JSON algorithm document.
Oct 2013 WGLC JSON private and symmetric key document.
Oct 2013 WGLC JSON private and symmetric key protection document.
Oct 2013 Submit JSON "cookbook" as a WG document.
Dec 2013 IETF LC JSON use cases and requirements document.
Dec 2013 IETF LC JSON object integrity document.
Dec 2013 IETF LC JSON object encryption document.
Dec 2013 IETF LC JSON key format document.
Dec 2013 IETF LC JSON algorithm document.
Dec 2013 IETF LC JSON private and symmetric key document.
Dec 2013 IETF LC JSON private and symmetric key protection document.
Dec 2013 WGLC JSON "cookbook".
Jan 2013 IETF LC JSON "cookbook".

Any comments on both the charter and milestones?

spt
jose issue tracker | 6 May 2013 14:29
Picon

#20: Shorter names for JSON serialization

#20: Shorter names for JSON serialization

 I noticed as I was doing some programming with the JSON syntax for JWE/JWS
 that the current field names in the JSON format are unnecessarily
 cumbersome.  Nobody in the real world names a variable
 "initialization_vector", it's "iv".   Proposed changes:

 || OLD                     || NEW  ||
 || signatures              || sigs ||
 || signature               || sig  ||
 || payload                 || data ||
 || recipients              || keys ||
 || ciphertext              || data ||
 || initialization_vector   || iv   ||
 || authentication_tag      || mac  ||

--

-- 
-------------------------+-------------------------------------------------
 Reporter:  rlb <at> ipv.sx   |      Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  encryption <at> tools.ietf.org
 Priority:  minor        |     Status:  new
Component:  json-web-    |  Milestone:
  encryption             |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/20>
jose <http://tools.ietf.org/jose/>
Jim Schaad | 2 May 2013 23:09

Comments on draft-ietf-jose-json-web-encryption-10

Here are a set of comments on the latest draft.

1.  Introduction - The first paragraph should not focus so much on the
compact serialization given that both serializations are merged into this
document.  I would suggest a paragraph on the encryption portion of the
problem followed by a paragraph on the two serialization formats used with
their purposes

2.  After the movement on the CBC_HMAC algorithm, I am not sure that section
3.2 is providing sufficient value for it to be present.  Given that the full
details on it are in an appendix you should consider its removal from here.
You might move a comment on looking in appendix a for completed examples
into section 3 from here

3.  In section 4.1.3 - I would suggest changing the text to "This parameter
MUST be omitted unless required by the algorithm in the "alg" member.  This
header parameter MUST be understood if an algorithm is supported that
requires it."

I have skipped over a number of sections that I knew would be affected by
the outcomes of the interim meeting.

Jim
Manger, James H | 28 Apr 2013 17:03

JWA replicating mcgrew-aead-aes-cbc-hmac-sha2

JOSE is at last using draft-mcgrew-aead-aes-cbc-hmac-sha2, but why is so much duplicated in JWA instead
of referenced? JOSE should have 1 sentence saying:

  The JOSE "alg" strings "A128CBC-HS256" and "A256CBC-HS512" correspond to the
AEAD_AES_128_CBC_HMAC_SHA_256 and AEAD_AES_256_CBC_HMAC_SHA_512 algorithms defined in [I-D.mcgrew-aead-aes-cbc-hmac-sha2].

That should be enough. Drop the other 4 pages of JWA on this.

If we really insist on breaking the RFC 5116 AEAD model, add 1 more paragraph.

  In [I-D.mcgrew-aead-aes-cbc-hmac-sha2] the ciphertext includes the CBC initialization vector as a
prefix and the truncated HMAC as a suffix. In a JOSE these two fields are separated from the ciphertext and
treated as the JWE Nonce and JWE Authentication Tag respectively. The JWE Ciphertext is the remaining
ciphertext (ie minus the prefix and suffix).

Why does JWA duplicate test cases for AES_CBC_HMAC_SHA2 (Appendix C) that will be in
draft-mcgrew-aead-aes-cbc-hmac-sha2? The test cases are not even JOSE messages. I hope this is a
temporary addition pending the publication of draft-mcgrew-aead-aes-cbc-hmac-sha2-02 (with the
test cases).

--
James Manger

Gmane