Re: [stir] "rcdi" vs MIME Content-Encoding

[Alec Fenichel <[e-mail]>]

It needs to be the decoded data. At the time the rcdi is sent, the content encoding is not necessarily known. A web server may support multiple content encodings and return the best encoding supported by the client (indicated by the Accept-Encoding header). 

Sincerely, 

Alec Fenichel 
Chief Technology Officer 
TransNexus <https://transnexus.com/> 
[e-mail] <mailto:[e-mail]> 
[phone] <tel:[phone]> 



From: stir <[e-mail]> on behalf of Ben Campbell <[e-mail]>
Date: Monday, April 1, 2024 at 16:21
To: IETF STIR Mail List <[e-mail]>
Cc: Peterson, Jon <[e-mail]>, Chris Wendt <[e-mail]>
Subject: [stir] "rcdi" vs MIME Content-Encoding 

Hi, 


In thinking about the “rcdi” hashes and RCD “icn” keys: 



What if the target has Content-Encoding? Would the “rcdi” hash be over the raw or decoded data? 



For example, lets say that I get the following headers when dereferencing the “icn” key: 



Content-Type: image/svg+xml Content-Encoding: gzip 


Should the “rcdi” hash be over the compressed or uncompressed version of the data? I assume since draft-ietf-stir-passport-rcd-26 does not mention content-encoding, that the hash would be over the actual octets we get back on the wire prior to decoding. 



But I see that RFC 9399 (Certificate Logotypes), which seems like a similar-if-not-identical application, says the opposite for this specific example: 



Whether the SVG image is GZIP-compressed or uncompressed, the hash value for the SVG image is calculated over the uncompressed SVG content with canonicalized EOL characters, as specified above. 


Thoughts? 



Thanks! 



Ben.