RFR JDK-8006182

[Michael StJohns]

At 11:57 AM 2/15/2013, Chris Hegarty wrote:
>Mike,
>
>I believe that Marks changes are a like for like replacement with what was there before, only using a supported public API. Are you saying otherwise? Or have you identified another potential issue?

I ran into this problem when trying to do my own de-armoring code and dealing with stuff that had been OCR'd - (don't ask -it was painful all around, but it was what I had).  I ended up having to wrap the de-armoring code in regex processing to ensure well-formed base64.

I guess what I'm saying is that you should be able to detect a base64 problem and report it before trying to decode the byte stream.  The fact that the old code didn't do this is occasionally problematic as I have at times spent hours trying to figure out what was wrong with the certificate encoding when it was the base64 that was confused. 

While I'm at it ( :-) ) it would be nice the code that detects the sentinels (e.g. the "-----BEGIN <etc>-----") would accept a number of the more common variations  - "BEGIN X509 CERTIFICATE"  "BEGIN CERTIFICATE REQUEST" (instead of "BEGIN CERTIFICATE and BEGIN NEW CERTIFICATE..."), and not care about white space between the "-----" and the beginning or end of the sentinel string.

To answer the question you didn't quite ask - no, this isn't critical, but since the code is open... just a thought.

Mike



>-Chris.
>
>On 15/02/2013 16:52, Michael StJohns wrote:
>>Is the "mime" variant of Base64 the correct one for this?  I ask because that variant ignores extraneous characters rather than throwing an error on decode.   Also, reading the code for the Base64 implementation, it silently "fixes" the case where there are missing padding "=" characters.  Neither of these seem ideal for security related processing.
>>
>>It may be reasonable to add a PEM variant to the Base64 code that deals with the above.
>>
>>Mike
>>
>>
>>
>>At 08:24 AM 2/14/2013, Mark Sheppard wrote:
>>>Hi,
>>>   as part of a refactoring of the jdk codebase to use the base64 capabilities of java.util.Base64,  the following modifications,
>>>as per the webrev,
>>>
>>>http://cr.openjdk.java.net/~chegar/8006182/webrev.00/
>>>
>>>have been made to complete task JDK-8006182.
>>>
>>>Could you oblige and review these changes, please?
>>>
>>>Description:
>>>jdk8 has java.util.Base64 to define a standard API for base64 encoding/decoding. It would be good to investigate whether this API could be used in the security components, providers and regression tests.
>>>
>>>In the main this work involved replacing the sun.misc.BASE64Encoder and sun.misc.BASE64Decoder with the
>>>corresponding Mime Base64 Encoder/Decoder  (as per rfc2045) from the java.util.Base64 class.
>>>This is a like for like replacement.
>>>As such, sun.misc.BASE64Encoder maps to the encoder returned by java.util.Base64.getMimeEncoder()
>>>sun.misc.BASE64Decoder maps to the decoder returned by java.util.Base64.getMimeDecoder()
>>>
>>>However a couple of items worth noting:
>>>
>>>In the jarsigner  (Main.java) the standard Base64 encoder (rfc 4648), java.util.Base64.getEncoder(), has been used to replace the JarBASE64Encoder, which was a package private extension of BASE64Encoder, which avoids writing newline to the encoded data.
>>>
>>>In the keytool (Main.java), methods such as dumpCert, printCert. printCRL, and so on, write a Base64 encoding to an OutputStream, typically std out.
>>>This is achieved in the BASE64Encoder, by passing the OutputStream to methods such as encodeBuffer().
>>>
>>>A couple of options exist to do this under the new Base64 utilities, which include:
>>>
>>>* using a Mime Encoder encodeToString() and  output to the stream via println()
>>>
>>>* use the wrap capabilities of the Base64.Encoder:
>>>    - define a package private class, which extends FilterOutputStream (e.g. NoCloseWrapperOutputStream) and, overrides close() to do nothing
>>>    - inject the OutputStream,  passed to the keytool method, into the NoCloseWrapperOutputStreamwapper,
>>>    - wrap() the NoCloseWrapperOutputStreamwrapper in the Mime Encoder, which will in turn return an encapsulating OutputStream;
>>>    - write the data buffer to be encoded to the encoder's OutputStream;
>>>    - close the encoder's OutputStream, which completes the base64 encoding;
>>>    - append a newline to the initial OutputStream.
>>>
>>>pragmatics and the simplest thing that works, went for the first option.
>>>
>>>regards
>>>Mark
>>>
>>>
>>>
>>>
>>