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
