An array-based serialization assumes that JWKs will never have structured values - JSON objects or arrays - that, or that when that case arises for future JWKs we'll have to invent an extension to the serialization instructions at that time. It's not inconceivable that a future key format might include tuples of values, for instance. The beauty of the current algorithm, being JSON-based, is that it's fairly future-proof.
-----Original Message----- From: ⌘ Matt Miller [mailto:[email protected]] Sent: Friday, January 23, 2015 1:50 PM To: John Bradley; Mike Jones Cc: Richard Barnes; Jim Schaad; [email protected] Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 1/23/15 2:26 PM, John Bradley wrote: > Yes, it allows for new key types to work with this spec in the future > without needing to redo the spec and worry about downgrade attacks. > > It seemed obvious at the time to use the JWK format. It is > interesting that some people specifically don’t want that. > This document is calling for handcrafting JSON. It's eschewing whatever existing support in order to have a canonical format[1]. My original proposal still included the kty, which (I assume) disambiguates heterogeneous keys today. I think it exceedingly unlikely that two different keys of different types will have parameter names and values that will collide with others, but I accept that some find it worthy of concern. What if the serialization were a JSON array consisting of an array of pairs -- the member name followed by the member value? For instance: [["crv","P-256"],["kty","EC"],["x","Ze2loSV3wrroKUN_4zhwGhCqo3Xhu1td4QjeQ5wIVR0"],["y","HlLtdXARY_f55A3fnzQbPcm6hgr34Mp8p-nuzQCE0Zw"]] Or in a flattened format, which is probably about the same amount of coding work: ["crv","P-256","kty","EC","x","Ze2loSV3wrroKUN_4zhwGhCqo3Xhu1td4QjeQ5wIVR0","y","HlLtdXARY_f55A3fnzQbPcm6hgr34Mp8p-nuzQCE0Zw"] Or maybe we seriously consider SPKI. - -- - - m&m Matt Miller < [email protected] > Cisco Systems, Inc. [1] And yes, I fully appreciate how little weight this argument carries if a certain working group did something about canonicalization. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUwsIjAAoJEDWi+S0W7cO10roH/jvyu4X/nTBW/sYw94l2xa6L kDd4ZuQwQOPoSI0IawcZ8PQOk/php3eumS1EqTR/kxMGNbfDrc72Si3Kb6s4dRot ZPn9ol8fu9HjaQUlT5J/f1tjLjClISVYZ/fAdu+GbxM/4C2tsgnyzWLPfLVE6l5k MSGyV5j0MTmY3rBX5oQEcLRZc48EibL+R+gka0Mi/zSFdOkrVPG5i8E/qV1HwO2O pIXHpvj/vuyrbFSjWml1Y9yiC4bMTK5HePgVzZ3+Jj1dBibg+TDH9gQMoInEIIIS yKbt74TmZ5DLPobfPcmvBSofdMCPGgNIQWiF1OBJZpzj14d/APgAj+ICv0C4Ycc= =+KOE -----END PGP SIGNATURE----- _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
