JDK 8 does not comply with RFC 5915

[Anders Rundgren]

Michael,

You are correct, I just wanted to point out the different interpretations
of SHOULD.

Since you obviously are pretty familiar with Java/JCE, would it be possible
for you spending a few minutes reviewing: https://github.com/cyberphone/java-cfrg-spec ?

I've just removed the note about private key serialization :-)

Anders

On 2017-06-26 23:44, Michael StJohns wrote:
> 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
> 
> 
> 
> 
> 
>