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>Received on Thursday, 20 June 2019 16:04:00 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:34 UTC