I don't know that having the element names is required.

They do however need to be sorted into a canonical order with separators, and 
kty is required.

We should probably give James a chance to respond from his TZ.

I don't personally care all that much what the separator character is as long 
as it cant appear in the values.

I think Richard mentioned some issues with spaces in using an array. 
Are there any other issues?

John B.


> On Jan 23, 2015, at 6:50 PM, ⌘ Matt Miller <[email protected]> wrote:
> 
> -----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-----

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to