RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE

Weijun Wang weijun.wang at oracle.com
Sat May 25 00:37:51 UTC 2019


The CSR is approved. Are you OK with the schema definition referencing "ECParametersType" but not defining it.

If yes, I'll push the change.

Thanks,
Nax

> On May 14, 2019, at 8:50 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
>> On May 13, 2019, at 10:51 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>> 
>> On 5/10/19 8:07 PM, Weijun Wang wrote:
>>>> On May 11, 2019, at 4:44 AM, Sean Mullan <sean.mullan at 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
> 




More information about the security-dev mailing list