Re: [jose] Tightened Key Managed JWS Spec

[Mike Jones <[e-mail]>]

Hi James,

The means of distinguishing between KMJWS objects and JWS and JWE objects is described in http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-01#section-7.

As I'd written in response to an inquiry on the same subject by Jim Schaad earlier:
It's backwards-compatible in the sense that if an implementation supports JWSs and JWEs but not KMJWSs (I'm still looking for a better name than KMJWS, BTW), the current rules all continue to do the right thing.  If an implementation supports all three, yes, a little bit of additional logic would be needed, just like a little bit of additional code would be needed, but no breaking changes result.  A KMJWS is neither a legal JWS nor a legal JWE, so even if the existing discrimination rules were applied to a KMJWS and it was mis-categorized as one or the other, upon parsing, it would still be rejected, since it would be missing required properties.

"crit" isn't required, because a graceful failure will already occur upon receipt if the KMJWS object is not understood.  (But on thinking of it, you're right that "crit":["mac"] could be used by KMJWS producers if it is useful in the application context.)

                                                            -- Mike

From: Manger, James [mailto:[e-mail]]
Sent: Wednesday, May 27, 2015 7:59 PM
To: Mike Jones; [e-mail]
Subject: RE: Tightened Key Managed JWS Spec

How is code supposed to distinguish KMJWS from JWS and JWE? Or how is code that understands JWS and JWE supposed to notice that a KMJWS message is something it cannot handle?
JWE section 9 "Distinguishing between JWS and JWE Objects" allows code to use any of 4 methods: counting dot-separated segments; payload/ciphertext member presence; alg value; enc member presence.
I think KMJWS breaks all 4.
Should 'crit' be used to indicate that something beyond JWS/JWE is going on?

--
James Manger

From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Thursday, 28 May 2015 9:57 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [jose] Tightened Key Managed JWS Spec

The -01 version of draft-jones-jose-key-managed-json-web-signature tightened the semantics by prohibiting use of "dir" as the "alg" header parameter value so a second equivalent representation for content integrity-protected with a MAC with no key management isn't introduced.  (A normal JWS will do just fine in this case.)  Thanks to Jim Schaad for pointing this out.  This version also adds acknowledgements and references the now-final JOSE RFCs<http://self-issued.info/?p=1387>.

This specification is available at:

*        https://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-01

An HTML formatted version is also available at:

*        http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-01.html

                                                                -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1396 and as @selfissued.