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

[Andrew Hughes]

On Wed, 6 Feb 2019 at 16:08, Sean Mullan <sean.mullan at oracle.com> wrote:
>
> 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

Yes, I get that.

Well, you have my approval for what it's worth for something that's
not an OpenJDK change :)
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222