JDK 8 does not comply with RFC 5915

[Anders Rundgren]

On 2017-06-26 17:58, Michael StJohns wrote:
> On 6/25/2017 2:21 AM, Anders Rundgren wrote:
>> During the work with https://github.com/cyberphone/java-cfrg-spec I had to look at the PKCS #8 spec as well.
>> It turns out that JDK 8 does not comply with RFC 5915's SHOULD since EC private keys created by KeyPairGenerator do not contain public key info when getEncoded().
>> I didn't check PKCS #8 de-serialization and serialization but I guess it doesn't work for that either.
>>
>> This is by no means serious, but differs from BouncyCastle as well as OpenSSL.
>>
>> Anders
> 
> Umm... SHOULD is not a MUST - JDK8 does comply with the RFC, it just doesn't provide the "convenient" field:
> 
>>   The publicKey
>>        field can be omitted when the public key has been distributed via
>>        another mechanism, which is beyond the scope of this document.
>>        Given the private key and the parameters, the public key can
>>        always be recomputed; this field exists as a convenience to the
>>        consumer.
> 
> I always thought that RFC5915 should have specified "MAY" there instead.   The main reason is that its trivial to reconstitute the public key from the private key so there is mostly no need to keep the two together and the actual text suggested as much.

Right, for standards developers this is clear. Practitioners OTOH only notice (usually the hard way) that some systems do this and some do that.

In this particular case the SHOULD have been interpreted differently by Oracle than by BouncyCastle and OpenSSL.

BTW, newer standards like JWK declares this feature as a MUST: https://tools.ietf.org/html/rfc7518#section-6.2.2


> 
> Ideally, there should be a way to control what gets included in the encoding - but the "getEncoded()" method doesn't permit an argument for format.

Yes, indeed.  At this late stage we can (at best) hope for "normalization".

thanx,
Anders



> 
> Later, Mike
> 
> 
>