PEM-style serialization malforms the END line

[philpennock]

All BEGIN/END PEM-style base64 wrapping follows a pattern from RFC1421, that for a given label FOO, the encoding is:

-----BEGIN FOO-----
base64_data_here
-----END FOO-----

Note in particular that there are exactly five hyphens at the start and end of both of those lines. This is not variable. This is a de-facto standard, with RFC1421's PEM rules then used by OpenSSL for PEM-encoding DER content, and everything else using the same pattern.

This JWT library is encoding lines such that the END line uses six hyphens at the start and end of the lines; my best guess is this is to make the start and end lines have the same length.

This variation means that various (no citation) tools used to parse PEM objects out of files fail with JWTs from this library. For the tools of mine which are affected, I will update to handle more dashes if applicable, but this doesn't handle the general case.

If we can fix this to use the de-facto standard for newly generated files, while respecting reading the current format, that would ease interop with other tools; nothing will help with current files, but those will be unusable with such tools anyway. We can just try to make things better for newly generated files.

[philpennock]

To confirm: Go's encoding/pem also explicitly expects this format for Decode() and will fail to return objects in this variant format.

(Pedantically: encoding/pem also supports headers, so not precisely what I described above)