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

[Anthony Scarpino]

On Wed, 12 Mar 2025 20:44:30 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
>> 
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - Merge in PEMRecord as part of the API.
>>  - Merge branch 'pem-record' into pem-merge
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/security/PEMDecoder.java
>>    #	src/java.base/share/classes/java/security/PEMRecord.java
>>    #	src/java.base/share/classes/sun/security/util/Pem.java
>>    #	test/jdk/java/security/PEM/PEMData.java
>>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>>  - Merge branch 'master' into pem-record
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>>  - test fixes & cleanup
>>  - Implement stream decoding
>>    fix StringBuffer/Builder
>>    X509C* changes
>>  - Reorg tests data
>>    minor fixes
>>  - merge from pem branch
>>  - Merge branch 'pem' into pem-record
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/security/PEMEncoder.java
>>    #	src/java.base/share/classes/sun/security/provider/X509Factory.java
>>    #	src/java.base/share/classes/sun/security/util/Pem.java
>>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>>  - ... and 48 more: https://git.openjdk.org/jdk/compare/22845a77...cc952c0b
>
> src/java.base/share/classes/java/security/PEMRecord.java line 53:
> 
>> 51:  * instantiation of this record.
>> 52:  *
>> 53:  * @param type The type identifier in the PEM header.  For a public key,
> 
> Since there are specific strings that will be needed in the `type` field, is there a pointer we could add so folks looking at this could see what values might be acceptable for this field.  I don't know if right here is the right place for it, but maybe a see-also or something?  Or is this left open-ended to support whatever could exist in a PEM header?

As `PEMRecord` is a generic object containing PEM formatted data, the `type` field (aka header/footer) does not have any checking.   PEM data that have cryptographic objects in the Java API will by default decoded to those.  Any other header will returned as a `PEMRecord`.   A PEM header type not in the specification could be use with a `PEMRecord` for encoding or decoding, but I don't see that as a problem.  Putting in restrictions doesn't make the API any better or usable given it is a generic "catch-all" object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2010963419