To be noted, there's more in section 2: Most extant parsers ignore blanks at the ends of lines; blanks at the beginnings of lines or in the middle of the base64-encoded data are far less compatible. These observations are codified in Figure 1. The most lax parser implementations are not line-oriented at all and will accept any mixture of whitespace outside of the encapsulation boundaries (see Figure 2). Such lax parsing may run the risk of accepting text that was not intended to be accepted in the first place (e.g., because the text was a snippet or sample).
I haven't looked enough in our code recently to remember if we're doing "standard" (figure 1) or "strict" (figure 3) parsing... what I hear is a request for us to move to "lax" (figure 2) parsing. Cheers, Richard On Wed Oct 05 12:02:54 2016, l...@acm.org wrote: > On 05-Oct-16 07:52, Salz, Rich via RT wrote: > > > Well, it is a SHOULD not a MUST. But point taken it could be (much) > > better :) > > > > > It's an important SHOULD. Whitespace introduction happens in the > wild. > > This is the quote from the OpenXPKI folks: > > I just saw this today at a customer install that a user uploaded a > > PCSK10 request with extra newlines, anything based on Crypt::PKCS10 > > is > > happy with it but openssl crashes when it tries to sign. > > See https://github.com/openxpki/openxpki/issues/437 -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
