- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 18 Jun 2019 06:45:53 +0200
- To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>
- Cc: Eliot Lear <lear@cisco.com>, "draft-ietf-pkix-est@ietf.org" <draft-ietf-pkix-est@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Carsten Bormann <cabo@tzi.org>, Anima WG <anima@ietf.org>
On 17.06.2019 22:44, Brian E Carpenter wrote: > On 18-Jun-19 05:18, Panos Kampanakis (pkampana) wrote: >>> So effectively, the CTE header has effectively been dropped, but the payload is now assumed to be base64, regardless. >>> This suggests that we can not use the CTE header as a signal. > > I went and looked at RFC4648 for my own education, and then spent a few minutes > trying to design a Turing machine that can distinguish a binary bit string from > a base64 bit string. Fail. You can determine that a bit string is definitely > not base64 if it contains at least one character outside the base64 alphabet, > but not the converse. So it needs a signal. Not having a signal would be wide > open to malicious misuse, IMHO. Indicating the length of the payload would be > enough, I think. I agree that using heuristics should be avoided. But how does Content-Length help here? Best regards, Julian
Received on Tuesday, 18 June 2019 04:46:38 UTC