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:[email protected]]
Sent: Wednesday, May 27, 2015 7:59 PM
To: Mike Jones; [email protected]
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:[email protected]] On Behalf Of Mike Jones
Sent: Thursday, 28 May 2015 9:57 AM
To: [email protected]<mailto:[email protected]>
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.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
