Subject: [P2PSIP] Enrollment server handling base64 encoded csr parameter

From: "Michael Chen" <[email-masked]>
Date: Fri, 21 Jun 2013 10:08:13 -0700

Hi Marc,
 
A bug in my program sent the following multi-part header followed by the pkcs10 DER binary, but your server ignored the transfer encoding header and processed the csr:
 
--0xD2454C4F
Content-Disposition: form-data; name="csr"
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
 
<CSR DER binary>
 
--0xD2454C4F

RFC2311 (referenced in section 11.3 of p2psip-base) does describe the use of base64 encoded application/pkcs10 content type (3.7.2). The p2psip-base draft should either endorse or explicitly exclude the base64 encoding stated in RFC2311.
 
Thanks
 
--Michael

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 21 Jun 2013 10:51:19 -0700

Hi Michael,

On 06/21/2013 10:08 AM, Michael Chen wrote:
> Hi Marc,
> 
> A bug in my program sent the following multi-part header followed by the
> pkcs10 DER binary, but your server ignored the transfer encoding header and
> processed the csr:
> 
> --0xD2454C4F Content-Disposition: form-data; name="csr" Content-Type:
> application/pkcs10 Content-Transfer-Encoding: base64
> 
> <CSR DER binary>
> 
> --0xD2454C4F
> 
> RFC2311 (referenced in section 11.3 of p2psip-base) does describe the use
> of base64 encoded application/pkcs10 content type (3.7.2). The p2psip-base
> draft should either endorse or explicitly exclude the base64 encoding
> stated in RFC2311.
> 

Hmm, RFC 2616 states in section 19.4.5:

   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
   2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
   remove any non-identity CTE ("quoted-printable" or "base64") encoding
   prior to delivering the response message to an HTTP client.

On the other hand RFC 2388 has an example using CTE:

    --AaB03x
    content-disposition: form-data; name="field1"
    content-type: text/plain;charset=windows-1250
    content-transfer-encoding: quoted-printable

    Joe owes =80100.
    --AaB03x

Perhaps what RFC 2616 meant was that CTE cannot be used as an header, but can
be used as a MIME parameter.  But as HTTP never had any 7bit/8bit issues, I
doubt it.

For the sake of interoperability, I filled a bug to add support for CTE in
form-data my server.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug