Re: IETF JSON Signature Options

On 2018-06-07 23:46, Adam Roach wrote:
> I haven't been following the conversation about what might need to be
> signed or why, and my observation below shouldn't be read as an
> endorsement of a need to sign anything; however, in case the WG does go
> down the path of signing a JSON object, it should do so with complete
> information.

If payment request data needs to be signed or not is depending on the architecture of the underlying payment system.  For 'basic-card' it wouldn't make much sense, while it in a "pay-with-your-bank" scheme could be crucial since the merchant security context isn't (securely) transferable when the payment request data is handed over to the bank.

Regarding the extreme complexity of JSON canonicalization, nobody claiming this have (AFAICT) performed any kind of analysis, it has just been taken for granted based on previous experiences with XML which is a quite different beast.

https://tools.ietf.org/html/rfc8225#section-9: Except for numerous omissions (for strings and numbers), the only difference to https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-00 is sorting on Unicode code points versus sorting on UTF16/UCS2 code units.

Anders

> 
> 
> On 6/7/18 1:06 AM, Anders Rundgren wrote:
>> Dear List,
>>
>> Several efforts have been initiated in order to create a more
>> JSON-friendly signature scheme where the data to be signed would
>> remain in JSON format rather than being Base64Url-encoded.
>>
>> However, it turns out that there is no real interest within the IETF
>> to pursue such ideas, effectively leaving the payment WG with a single
>> standardized solution:
> 
> My understanding is that the IETF declined to define a generalized
> canonicalization for JSON, due to the extreme complexity of both
> designing and implementing such a scheme that works in all general cases.
> 
> The lack of a generalized canonicalization does not prevent the
> definition of application-specific canonicalization of JSON data that
> takes advantage of the known structure of the JSON objects in question
> to create a simpler (and usually trivial) normalization procedure.
> 
> See RFC 8225, section 7 for an example of how this has been done elsewhere.
> 
> /a
>

Received on Friday, 8 June 2018 08:17:32 UTC