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

["Panos Kampanakis (pkampana)" <[e-mail]>]

> 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 <[e-mail]>
Sent: Monday, June 17, 2019 12:20 PM
To: Panos Kampanakis (pkampana) <[e-mail]>
Cc: Eliot Lear <[e-mail]>; Carsten Bormann <[e-mail]>; Julian Reschke <[e-mail]>; [e-mail]; [e-mail]; Anima WG <[e-mail]>
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 <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-




* Unknown Key
* 0xFDFC4290