- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Thu, 13 Jun 2019 20:33:59 +0000
- To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Eliot Lear <lear@cisco.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "draft-ietf-pkix-est@ietf.org" <draft-ietf-pkix-est@ietf.org>, Carsten Bormann <cabo@tzi.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Anima WG <anima@ietf.org>
On 14-Jun-19 05:18, Panos Kampanakis (pkampana) wrote: > 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. https://tools.ietf.org/html/rfc7231#appendix-A from June 2014 makes it all very plain. However, there is a small problem of running code. There's already an erratum: https://www.rfc-editor.org/errata/eid5107 For whatever reason, it is sitting in state "reported" since 2017. Brian
Received on Thursday, 20 June 2019 16:03:48 UTC