RFR: 8298420: PEM API: Implementation (Preview) [v8]

Michael Osipov duke at openjdk.org
Fri Oct 18 20:40:37 UTC 2024


On Thu, 17 Oct 2024 16:24:02 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi all,
>> 
>> I need a code review of the PEM API.  Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates.  It will be integrated into JDK24 as a Preview Feature.  Preview features does not permanently define the API and it is subject to change in future releases until it is finalized.
>> 
>> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - merge with master & updates
>  - Merge branch 'master' into pem
>  - partial code review update
>  - fix decoding non-encrypted types
>  - comments updates and getPBEID
>  - test fixes
>  - Merge branch 'master' into pem
>  - fix StringBuffer/Builder
>    X509C* changes
>  - test merge with futures
>    docs cleanup
>  - review comments part 2
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/28538524...4b3aae00

This JEP is misnamed. The RFC clearly says


   For reasons that basically boil down to non-coordination or
   inattention, many PKIX, PKCS, and CMS libraries implement a text-
   based encoding that is similar to -- but not identical with -- PEM
   encoding. 
...
Unlike legacy PEM encoding [[RFC1421](https://www.rfc-editor.org/rfc/rfc1421)], OpenPGP ASCII armor, and the
   OpenSSH key file format, textual encoding does *not* define or permit
   headers to be encoded alongside the data.  Empty space can appear
   between the pre-encapsulation boundary and the base64, but generators
   SHOULD NOT emit such any such spacing.  (The provision for this empty
   area is a throwback to PEM, which defined an "encapsulated header
   portion".)


So this RFC is clearly not PEM and this JEP shouldn't be named as such, hence class names neither.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17543#issuecomment-2423196928


More information about the security-dev mailing list