[8u] Request for approval for CR 8215318 - Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions

Sean Mullan sean.mullan at oracle.com
Wed Jan 30 20:34:54 UTC 2019


On 1/30/19 11:00 AM, Andrew Hughes wrote:
> On Mon, 28 Jan 2019 at 20:52, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>>
>> Requesting approval to push to 8u. This is one of the changes proposed
>> for the upcoming Java SE 8 Maintenance Review. This change is a
>> clarification to the Java Security Standard Algorithm Names
>> specification to allow implementations to support names that are defined
>> in later revisions. The change is low risk (docs only). The patch has
>> already been applied to JDK 12 and is the same for 11u and 8u. The CCC
>> and CSR has already been approved for 8, 11 and 12.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8215318
>>
>> The public code review thread for the JDK 12 patch is at:
>> https://mail.openjdk.java.net/pipermail/security-dev/2019-January/019114.html
>>
>> Note that this specification is currently in a closed repository, but we
>> are requesting a public push approval since the changes will be publicly
>> documented in the Java SE 8 Maintenance Review.
>>
>> Thanks,
>> Sean
> 
> Is there a webrev for this? I can't see a link to a changeset on the bug either.

The specification has not yet been open sourced, so there is no 
changeset I can point you to. However, it will be included in the 
upcoming MR, so it is important that there is a public review and 
approval for the changes.

The current JDK 8 version is 
https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html

The changes that are proposed are the following:

Add the following sentence to the first section ("Standard Names") of 
the Java Security Standard Algorithm Names specification:

     Note that an SE implementation may support additional algorithms
     that are not defined in this specification.  As a best practice, if an
     algorithm is defined in a subsequent version of this specification and
     an implementation of an earlier specification supports that algorithm,
     the implementation should use the standard name of the algorithm
     that is defined in the subsequent specification.  Each SE 
implementation
     should also document the algorithms that it supports or adds support
     for in subsequent update releases.  The algorithms may be documented
     in release notes or in a separate document such as the JDK Security
     Providers document.

Also, the words "JDK Security API" in this section will be changed to 
"Java SE Security API" (this change has already been made in later SE 
releases).

With these changes added, the beginning of the first section is now the 
following:

     The Java SE Security API requires and uses a set of standard
     names for algorithms, certificate and keystore types. This
     specification establishes the following names as standard names.

     Note that an SE implementation may support additional algorithms
     that are not defined in this specification.  As a best practice, if an
     algorithm is defined in a subsequent version of this specification and
     an implementation of an earlier specification supports that algorithm,
     the implementation should use the standard name of the algorithm
     that is defined in the subsequent specification.  Each SE 
implementation
     should also document the algorithms that it supports or adds support
     for in subsequent update releases.  The algorithms may be documented
     in release notes or in a separate document such as the JDK Security
     Providers document.

     In some cases naming conventions are given for forming names
     that are not explicitly listed, to facilitate name consistency
     across provider implementations. Items in angle brackets (such as
     <digest> and <encryption>) are placeholders to be replaced by a
     specific message digest, encryption algorithm, or other name.

     Note: Standard names are not case-sensitive.

Thanks,
Sean



More information about the jdk8u-dev mailing list