1

RFC5958 defines a set of enhancements to the PKCS#8 key serialization format, bumping the version field up to 1 and additionally permitting serialization of public keys for arbitrary asymmetric cryptographic algorithms.

OneAsymmetricKey ::= SEQUENCE {
  version                   Version,
  privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
  privateKey                PrivateKey,
  attributes            [0] Attributes OPTIONAL,
  ...,
  [[2: publicKey        [1] PublicKey OPTIONAL ]],
  ...
}

PrivateKeyInfo ::= OneAsymmetricKey -- Overwriting the definition in RFC5208 which only supports private keys

However, I'm unclear on the following:

  • What belongs in the third field of the OneAsymmetricKey sequence when one is encoding only a public key?

I'm writing an implementation of some current research/experimental cryptographic algorithms, and I'm currently trying to write the serialization and deserialization capabilities.

1 Answers1

0

You misunderstand RFC5958.

PKCS#8 remains a private key serialization format. There is no exception made for that field in the v2 which may contain a public key, because such is now allowed to be included in addition to the private key, not instead of it.


What you should be producing, instead, when you only intend to serialize a public key for transfer, is merely and exactly a SubjectPublicKeyInfo object as defined in RFC5280:

AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }

SubjectPublicKeyInfo  ::=  SEQUENCE  {
     algorithm            AlgorithmIdentifier,
     subjectPublicKey     BIT STRING -- DEFINED BY algorithm --  }

(with, of course, ASCII armoring when appropriate.)

This is how other standardized public cryptographic keys (with the sole exception of RSA's PKCS#1 encoding) are serialized for transfer, such as Ed25519/X25519 and Ed448/X448 as well as the various NIST ECC curves.

  • PKIX publickey encodings for other algorithms are in 3279 (referenced by 3280/5280) plus 4055 4491 5480 5756. (5758 and 8692 add signatures but not keys.) The PKCS1-labelled-PUBLIC-KEY file in #115862 is NOT standard, as both the bear and I explained, and 7468 (as you linked) specifies. – dave_thompson_085 May 20 '21 at 09:00
  • 1
    @dave_thompson_085 Indeed, that `BEGIN RSA PUBLIC KEY` encoding is more of a _de facto_ "standard" if anything… certainly not to be imitated for future software implementations – JamesTheAwesomeDude May 20 '21 at 10:32