The libest server or proxy will generate the CTE header as specified in RFC7030. The libest client will parse it, but it will not reject the response if the header is not there. It expects base64 encoded PKCS#7, not binary though. Note that in https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ we assume all cert payloads are binary.
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. To address the erratum, I would lean towards a recommendation against using the CTE header based on the referenced standards and state that base64 encoding is implied. Rgs, Panos _____________________________________________ From: Michael Richardson <[email protected]<mailto:[email protected]>> Sent: Thursday, June 13, 2019 10:29 AM To: Eliot Lear <[email protected]<mailto:[email protected]>> Cc: Carsten Bormann <[email protected]<mailto:[email protected]>>; Julian Reschke <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Anima WG <[email protected]<mailto:[email protected]>>; Panos Kampanakis (pkampana) <[email protected]<mailto:[email protected]>> Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI * PGP Signed by an unknown key Eliot Lear <[email protected]<mailto:[email protected]>> wrote: > I am looking at libest and it certainly generates the header. How does it react to the absense of the header? (or the header containing "binary") Does it process binary directly in that case? -- Michael Richardson <[email protected]<mailto:[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =- * Unknown Key * 0xDDD0DD65
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
