|
From: Oliver W. <ma...@ol...> - 2024-06-12 15:14:18
|
Hi Stefan, thanks for digging - turns out it is as I expected =) I did some more tests and openssl fails at 1024 chars line length so I assume its just some sort of "buffer too small" issue and we came up with the same conclusion. I think we will add a switch to control if lines should be wrapped or not as I am pretty sure we will stumble over a client sooner or later that fails the same way. Internally we use the perl MIME::Base64 module which does a stream decoding and does not care on any lenght limits, so that should be pretty safe. best regards Oliver On 12.06.24 14:02, Stefan Goeman wrote: > Hi Oliver > > We looked into this further. It seems that RFC 7030 is updated by RFC > 8951. RFC 8951 refers to RFC 4648. We believe that OpenXPKI is > probalby doing it correctly. > > *In section 3.1, RFC 8951 says:* > /Note that "base64" as used in the HTTP [//RFC2616 > <https://www.rfc-editor.org/rfc/rfc8951.html#RFC2616>//] does not > permit CRLF, while the "base64" used in MIME [//RFC2045 > <https://www.rfc-editor.org/rfc/rfc8951.html#RFC2045>//] does. This > specification clarifies that despite what [//RFC2616 > <https://www.rfc-editor.org/rfc/rfc8951.html#RFC2616>//] says, white > space including CR, LF, spaces (ASCII 32), and tabs (ASCII 9) > /*/SHOULD/*/ be tolerated by receivers. Senders are not required to > insert any kind of white space./ > > *In section 3.1 RFC 4648 says:* > /MIME [4 <https://www.rfc-editor.org/rfc/rfc4648#ref-4>] is often used > as a reference for base 64 encoding. However, MIME does not define > "base 64" per se, but rather a "base 64 Content- Transfer-Encoding" > for use within MIME. As such, MIME enforces a limit on line length > of base 64-encoded data to 76 characters. MIME inherits the > encoding from Privacy Enhanced Mail (PEM) [3 > <https://www.rfc-editor.org/rfc/rfc4648#ref-3>], stating that it is > "virtually identical"; however, PEM uses a line length of 64 > characters. The MIME and PEM limits are both due to limits within > SMTP. Implementations MUST NOT add line feeds to base-encoded data > unless the specification referring to this document explicitly > directs base encoders to add line feeds after a specific number of > characters./ > > On the web site there are some examples that use the "base64" tool. > Lukily this tool handles both base64 content with and without line feeds. > > Refering back to RFC 8951, as OpenXPKI can also be a receiver of > base64 content (in case of an enroll or re-enroll request), it should > be checked if PKCS#10 with and without line feeds can be handled. If > base64 is used to decode this, then I believe it will be OK. > > Greetings, > Stefan. > ------------------------------------------------------------------------ > *Van:* Oliver Welter <ma...@ol...> > *Verzonden:* woensdag 12 juni 2024 13:16 > *Aan:* ope...@li... > <ope...@li...> > *Onderwerp:* Re: [OpenXPKI-users] format of the > .../.well-known/est/cacerts response > > Hi Stefan, > > > OpenXPKI sends the payload in base64 without wrapping it into line > blocks while the EST test server does and it looks like the openssl > base64 is not able to handle this encoding. I have looked around a bit > and did not really find a normative reference if OpenXPKI is doing it > wrong or if this is just a glitch in OpenSSL but I will add this as an > RFE so we will implement line wrapping with the next release. > > > best regards > > > Oliver > > > On 12.06.24 09:48, Stefan Goeman wrote: >> Hello >> >> I want to use the following commands to get my ca files in a nicely >> fomated pem-file: >> >> * >> curl -k --connect-timeout 10 -s >> https://my_est_server/.well-known/est/cacerts >> <https://my_est_server/.well-known/est/cacerts> -o cacerts.p7 >> * >> openssl base64 -d -in cacerts.p7 | openssl pkcs7 -inform DER >> -outform PEM -print_certs -out cacerts.pem >> >> Now, when I use the testest server at https://testrfc7030.com:8443/ >> <https://testrfc7030.com:8443/> these commands work and I get a >> nicely looking pem file. >> >> When I use these commands with my own openxpki server, the second >> command does not work. I get the error (on debian 12) "unable to load >> PKCS7 object". >> >> One difference that I notice is that when I run the curl command >> against the testrfc7030 server I already have a nicely formated >> looking file, like you expect in a pem-file. >> When I do the curl command against my own server, there is only one >> line in the file, and when I open this file in vi I see the message >> "incomplete last line". I have no idea what this means? >> >> BTW, If I use "base64 -d cacerts.p7 | openssl pkcs7 -inform DER >> -outform PEM -print_certs -out cacerts.pem" on my system, this works. >> So, there is obviously a difference between "openssl base64" and >> "base64". >> >> Much thanks in advance for your help. >> >> Greetings, >> Stefan. >> >> >> _______________________________________________ >> OpenXPKI-users mailing list >> Ope...@li... <mailto:Ope...@li...> >> https://lists.sourceforge.net/lists/listinfo/openxpki-users <https://lists.sourceforge.net/lists/listinfo/openxpki-users> > -- > Protect your environment - close windows and adopt a penguin! > > > _______________________________________________ > OpenXPKI-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxpki-users -- Protect your environment - close windows and adopt a penguin! |