* RFC7518, sec. 6.2.1 requires for public key representation key-value pairs for keys 'crv', 'x', and 'y'.
The 'crv' value is easy. It's the line NIST CURVE: P-256 from the -text for named curve format, not shown above.
The 'x' and the 'y' are not shown. My guess from looking online is that x and y are in the value for openssl -text
value 'pub'. In output above, pub value (abbreviated) is 04:68...b3:c1. I have not been successful in unpacking
the pub value to show anything coherent. I think the colons can be dropped and what's left can be decoded
base64 or base64url. My openssl (Debian linux) has no 'base64' subcommand.
have found nothing online about this. I figure this should be
important. Typically, lack of relevant documentation online means I am
making a very original mistake. I am not subscribed to the [hidden email] mailing list. I can of course check
the archives and see if this went into it.
What am I doing wrong?
I think it's a conceptual thing. I am not a C programmer and don't
exactly want to figure out how to use the C functions. Even so, I am
interested in what's a reasonable approach, even if not so reasonable
for me. I must be doing something unreasonable. Thanks. Happy Holidays
if that applies to you.
Question: Do I or should I worry about seeding for the Pseudorandom
Number Generator (PRNG). It seems to me that it would be nice to get a
pseudo-random number and just mess it up a bit in a text editor and use
that as the seed for making a new key. Just a guess. If you have an
informed thought on that, I'd be interested.
Thanks for openssl and everything! It's indispensible free software.
Re: JSON Web Key (JWK) for public key requires x and y coordinates.
I don't think OpenSSL supports the encoding of keys specified in
RFC7518: you are right in believing that the x and y values can be
retrieved from the 'pub:' field of the `-text` output for the key, but
that field conforms to Sec 2.3.4 of the SEC1 standard (which is
referenced also by RFC7518, although they preferred to use a custom
representation for the curve point).
If I am reading RFC7518 correctly, you would need a piece of software
that would take the affine x and y coordinate for the public EC point
encoded as the base64 encoding of the octet representation of a field
element (zero padded to the byte length of the field order).
It is possible to achieve this writing a C/C++ program using the
OpenSSL API, but as far as I know, no OpenSSL CLI tool currently
supports that format.
With a quick glance at Google results though, it seems that many
modules supporting JOSE for NodeJS/Ruby/Erlang/Elixir/Python also have
methods to parse a public key PEM file and transform into an RFC7518
So depending on what language you are using to develop your
application you should be able to call something like
`JOSE::JWK::from_pem_file('pubkey.pem')` and obtain an object
representing the public key that can be exported to the RFC7518
In Ruby, for example, using the 'jose' gem, you could:
Bonus answer: I am not an expert on the RAND module of OpenSSL, but
the short answer should be that if you are using the latest release of
OpenSSL, most likely you don't need to worry about seeding manually
the PRNG, as the RAND module should be doing everything it can to
gather the required entropy from the facilities provided by your
platform and feeding it through a state-of-the-art cryptographic PRNG
implementation to obtain the cryptographically secure randomness
needed, e.g. for the key generation above.
Of course I cannot say anything about the functionality provided by
whatever framework you are going to use for the rest of your RFC7518
operations, as what they use depends on their cryptographic backend
(which could be OpenSSL or some other software).