Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI

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.

  Brian

> 
> I am not sure I can speak about all implementations out there, but that is what I saw in my interop testing.
> 
>> One has to assume base64 encoded values for the RFC7030 end-points.
> 
> In all tests I did yes.
> 
> 
> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Monday, June 17, 2019 12:20 PM
> To: Panos Kampanakis (pkampana) <pkampana@cisco.com>
> Cc: Eliot Lear <lear@cisco.com>; Carsten Bormann <cabo@tzi.org>; Julian Reschke <julian.reschke@gmx.de>; draft-ietf-pkix-est@ietf.org; ietf-http-wg@w3.org; Anima WG <anima@ietf.org>
> Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI
> 
> * PGP Signed by an unknown key
> 
> 
>> Now, I don’t know how other EST clients would act. There are many out
>> there by now that we can’t safely tell if they would act up.
>> The commercial and enterprise CAs I tested with interoped fine with
>> the libest client and they were not all sending the CTE field. They
>> payload was base64 though.
> 
> I didn't read this well enough before.
> 
> 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.
> One has to assume base64 encoded values for the RFC7030 end-points.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> * Unknown Key
> * 0xFDFC4290
> _______________________________________________
> Anima mailing list
> Anima@ietf.org <mailto:Anima@ietf.org>
> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>