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

[Alec Fenichel <[e-mail]>]

Ben, 

I had not thought about this until you sent this email and this is an important point, so I think it should be clarified. 

Sincerely, 

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


[phone] <tel:[phone]> 

From: Ben Campbell <[e-mail]>
Date: Monday, April 1, 2024 at 17:09
To: Alec Fenichel <[e-mail]>
Cc: IETF STIR Mail List <[e-mail]>, Peterson, Jon <[e-mail]>, Chris Wendt <[e-mail]>
Subject: Re: [stir] "rcdi" vs MIME Content-Encoding 

Yeah, I was just thinking that after sending the question. 


Does draft-ietf-stir-passport-rcd need to say something about Content-Encoding? Or is that sufficiently understood by everyone (other than myself)? 




On Apr 1, 2024, at 3:29 PM, Alec Fenichel <[e-mail]> wrote: 


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] <mailto:[e-mail]>> on behalf of Ben Campbell <[e-mail] <mailto:[e-mail]>>
Date: Monday, April 1, 2024 at 16:21
To: IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
Cc: Peterson, Jon <[e-mail] <mailto:[e-mail]>>, Chris Wendt <[e-mail] <mailto:[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.