> 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 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 <[email protected]> Sent: Monday, June 17, 2019 12:20 PM To: Panos Kampanakis (pkampana) <[email protected]> Cc: Eliot Lear <[email protected]>; Carsten Bormann <[email protected]>; Julian Reschke <[email protected]>; [email protected]; [email protected]; Anima WG <[email protected]> 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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- * Unknown Key * 0xFDFC4290 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
