Viktor Dukhovni wrote in <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@xxxxxxxxxxxx>:
|That particular parser tries to parse an arbitrary single
|PEM-encoded object, rather than a first object of a particular
|type (as with "pkey", "req", "x509", ...). The code for that
|is more specialized, and does support leading free-form text.
|
|While it could skip to the first boundary, and a well written
|pull request would be welcome, it is not critical for asn1parse
|to be able to ignore free-form text above the PEM object.
|
|In the meantime:
|
| $ perl -ne 'print if (/^-----BEGIN/../^-----END/);' foo.pem |
| openssl asn1parse
The RFC 7468 term "parsers SHOULD ignore whitespace and other non-
base64 characters" makes me wonder. I know (or used to know) that
the OpenSSL base64 decoder is (or was) pretty bad in doing so.
But this RFC is about PKIX specifics, of course, yet i (as a MUA
maintainer) struggled with how to deal with embedded data in
base64 encodings, and this RFC seems to explicitly allow them.
And i struggled because i have seen mail messages with data
embedded in base64; the rewrite of the MIME encoder (MUA commit
[d91a4bd0]), necessary to deal with those sequences. says a. o.:
In both cases: except that we, due to lack of a context, cannot
give an error message, say, once per handled message. I.e., we
cannot provide any error logging in order to avoid a possibly
infinite amount of such messages.
Regarding the garbage in base64 parts that we now simply skip.
I mean, it is possible to embed abuse porn or similar shit in
between the valid data, and now we _also_ simply skip over the
"garbage", silently extraditing our users to automatic parsers
which may gobble that s..t!
Also because the mutt(1) MUA is pretty good in skipping over
things.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
