[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]

On 1/31/19 1:26 AM, Andrew Hughes wrote:
> On Wed, 30 Jan 2019 at 20:35, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 1/30/19 11:00 AM, Andrew Hughes wrote:
 >>
>> 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
>>
> 
> The changes seem relatively uncontroversial (though I fail to see
> the difference between "JDK Security API" and "Java SE Security API").

JDK APIs are often used to describe public or exported APIs that are 
part of the JDK, but not standard SE APIs. For example, the CSR process 
uses this term for the Scope field [1]. The APIs referenced in this 
specification are all standard SE APIs.

> However, I don't see how I can approve something which is not
> even part of OpenJDK and thus, can't even see.

It is not part of the OpenJDK source code, but this specification is 
referenced as a standard document from various Java SE Security APIs. 
For an example, see [2].

Thanks,
Sean

[1] https://wiki.openjdk.java.net/display/csr/Fields+of+a+CSR+Request
[2] 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/b6dcf8ae496c/src/share/classes/java/security/MessageDigest.java#l150