JDK 8 does not comply with RFC 5915

[Michael StJohns]

Inline.

On 6/26/2017 2:56 PM, Anders Rundgren wrote:
> On 2017-06-26 17:58, Michael StJohns wrote:
>>
>> Umm... SHOULD is not a MUST - JDK8 does comply with the RFC, it just 
>> doesn't provide the "convenient" field:
>>
>>
>> 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.

And all three of them are compliant with RFC5915 AFAICT.

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

After thinking about it, I'm not sure why you think this is necessary.

Here's why I think it isn't:
1) The whole idea of plugin providers is to be able to provide different 
services and sometimes in different manners.  E.g. it's OK that 
Bouncycastle does it one way and Oracle does it another - I might 
actually want the more compact format due to storage or transmission 
constraints. (Or to fit encrypted into a barcode...)
2) PKCS8 as a standalone object is one of the least useful encodings - 
I'd rather have a PKCS12 most times.  Or the bare private value, or a 
handle to the object on an HSM.  I usually end up having to convert 
anything generated by OpenSSL into one of those forms.
3) I don't think even bouncy castle's KeyFactory implementation of an EC 
factory allows you to generate a public key from a PKCS8 object.
4) I'm pretty sure that the Sun EC key factory implementation doesn't 
choke on a PKCS8 object that contains an Public key.
5) All providers that do EC that I'm aware of (e.g. Bouncycastle, IAIK 
and Sun) expect the input data for a key factory to generate an EC 
public key to be a SubjectPublicKeyInfo blob.
6) It's *really* mostly not a good idea to be using the PKCS8 object 
model - it has no protection at all for the private key.  I've used it 
exactly once and paired it with the PKCS12 SafeBag constructs 
(PKCS8ShroudedKeyBag) to provide protection.
7) the java.security.spec.PKCS8EncodedKeySpec has no way of extracting 
or setting the attributes section of the private key (where the public 
key is stored), so there's really no reason to implement support for the 
public key unless the implementing provider needs it or can use it in 
some way.
8) Java doesn't even provide a way to figure out the type of the PKCS8 
private key  - e.g. no way to grab the OID that describes the underlying 
key material from the PKCS8EncodedKeySpec - so you actually have to know 
its an EC key some other way.

So how would you use the additional Public Key data in Java?

Later, Mike