On 5/24/19 8:37 PM, Weijun Wang wrote:
The CSR is approved. Are you OK with the schema definition referencing
"ECParametersType" but not defining it.
Yes, but could you add something like: "See section 4.5.2.3.1 of the W3C
Recommendation for XML-Signature Syntax and Processing for the
definition of ECParametersType." (This is a docs-only change, so you
don't need to re-submit the CSR).
Also, in the Release Note, can you mention that the JDK implementation
does not support ECParametersType.
Thanks,
Sean
If yes, I'll push the change.
Thanks,
Nax
On May 14, 2019, at 8:50 AM, Weijun Wang <weijun.w...@oracle.com> wrote:
On May 13, 2019, at 10:51 PM, Sean Mullan <sean.mul...@oracle.com> wrote:
On 5/10/19 8:07 PM, Weijun Wang wrote:
On May 11, 2019, at 4:44 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
On 5/10/19 5:04 AM, Weijun Wang wrote:
Please take a review at the CSR at
https://bugs.openjdk.java.net/browse/JDK-8223682
Updated with @since 13 and no more @implNote.
Thanks,
Max
Add an "@since 13" to the new constant.
The text is copied from 4.5.2 and 4.5.2.3 of
https://www.w3.org/TR/xmldsig-core/.
One thing I am not sure is that I haven't include the definition of
ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote
saying ECParameters is not supported in this implementation, I understand
@implNote is not really a part of the spec and it's not the reason I omit the
definition of ECParameters. If you believe it should be included, I'll add it,
or add a link.
I would leave out the implNote completely. It doesn't seem the right place to
put it, since this is an interface. What is the reason ECParameters is not
supported?
Maybe a little complicated?
https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171
Yes, perhaps, or more likely because it is optional to support ECParameters.
Section 4.5.2.3 of the XML Signature Recommendation says:
"Conformant applications must support the dsig11:NamedCurve element and the 256-bit
prime field curve as identified by the OID 1.2.840.10045.3.1.7."
--Sean
--Max
--Sean
The code change is exactly the same as the specification, so no webrev.
Thanks,
Max