On Thu, 8 May 2025 20:58:41 GMT, Anthony Scarpino <[email protected]> wrote:
>> src/java.base/share/classes/java/security/PEMEncoder.java line 54:
>>
>>> 52: * and footer.
>>> 53: *
>>> 54: * <p> Encoding may be performed on Java Cryptographic Extension (JCE)
>>> objects
>>
>> Is "JCE objects" a formal term? We used to say "JCA and JCE". How do we call
>> them now?
>
> I'd like to keep the JCA/JCE nuance out. I'd rather just leave it as is, or
> use the alternative I've used elsewhere, Java API cryptographic object.
I would probably just say "cryptographic objects that implement `DEREncodable`"
>> src/java.base/share/classes/java/security/PEMEncoder.java line 70:
>>
>>> 68: * {@linkplain PEMRecord#pem()} with a generated the PEM header and
>>> footer
>>> 69: * from {@linkplain PEMRecord#type()}. It will not check the validity
>>> of
>>> 70: * the data.
>>
>> Since you mention `PEMRecord` specifically, I'd see the clarification that
>> the `leadingData` there will not be encoded. Otherwise, you cannot guarantee
>> on the encoding.
>
> I think specifying the fields that are encoded makes it clear what is not in
> the encoding.
I would have expected the leading data to be encoded. Why is the leading data
not encoded?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085594839
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085615501
