Summary

  • RFC 5208 PrivateKeyInfo and RFC 5958 OneAsymmetricKey carry private-key material in a defined structure. The unencrypted package is representation, not proof of encryption, access control, hardware custody or safe handling.
  • Decryption, validation, public-key correspondence, import, authorization, cryptographic operation and application acceptance are different receipts. A parser's success cannot satisfy them on their behalf.

The parser answered the smallest question

PKCS #8 solved a real interoperability problem. A system needed a common outer structure that could name an asymmetric algorithm, carry the algorithm-specific private-key value and attach attributes without forcing every transport to invent its own wrapper. RFC 5208 called that structure PrivateKeyInfo: version, algorithm identifier, a private-key OCTET STRING and optional attributes.

That is useful precisely because it is narrow. The algorithm registration explains how to interpret the octets. It does not say who copied them, where they rested, which process could read them or whether a hardware boundary ever existed. A successful decode establishes that bytes conform to a grammar. It is not a custody report.

RFC 5958 makes the distinction harder to ignore. Its successor structure, OneAsymmetricKey, can add a public-key field and travel in an asymmetric key package. The specification describes that package as carrying plaintext asymmetric keys and states that the package contents are not protected. Protection may be added through a separate CMS protecting content type. The format is not ashamed of being a format; dashboards should not grant it powers it never claimed.

Two labels, two states

RFC 7468 reserves PRIVATE KEY for the unencrypted PrivateKeyInfo or OneAsymmetricKey form. ENCRYPTED PRIVATE KEY names EncryptedPrivateKeyInfo. The difference is not cosmetic. In RFC 5208, the latter contains an encryption algorithm identifier and encrypted data. First the private-key information is encoded; then those bytes are encrypted.

This sequence creates two auditable events. A decoder can report that the protected wrapper was well formed. A decryption process can report which parameters it used, which secret or credential was presented, whether integrity checks passed and what plaintext emerged. Collapsing both into key imported destroys the point at which protection ended.

Encryption metadata also cannot certify its own strength. RFC 8018 explains why password-derived protection needs care: passwords often come from a small search space, so salts, iteration cost, algorithms and operational limits matter. An OID naming a KDF or cipher is a claim about intended processing. It is not evidence that the password resisted guessing, that parameters met policy or that decrypted bytes were erased.

Custody begins after representation

A private-key package may be generated in memory, written to disk, attached to a ticket, copied through a clipboard, imported into a software keystore or transferred into hardware. The same PKCS #8 object can cross all of those environments without changing its syntax. The representation remains stable while its risk changes radically.

That is why application/pkcs8, a .p8 extension or a valid PEM boundary cannot prove HSM residency. Even an HSM object handle proves only that an object exists inside a named boundary at a time. It does not prove that no plaintext copy survives elsewhere, that the object is non-exportable, that a caller has the right operation policy, or that backups follow the same control.

Custody evidence needs its own chain: source hash, protected transport, importer identity, destination slot, object identifier, exportability flag, policy template, replication target, audit event and deletion receipt for transient copies. None of those fields belongs inside the parser's green check mark.

A valid object may still be the wrong key

RFC 5958 can carry an optional public key, and some algorithm-specific private structures already contain enough material to derive or include public components. That improves packaging; it does not make correspondence self-proving. A system still needs to derive or validate the public key under the correct algorithm and compare it with the certificate, account, key identifier or trust record it intended to use.

RFC 8479 demonstrates another careful distinction. It defines an attribute for storing inputs that can be used to validate how certain RSA or DSA parameters were generated. Carrying the seed and hash identifier preserves possible evidence. It does not mean a validator ran, that its implementation was correct or that the result passed.

Parsing, mathematical validation and identity binding therefore deserve separate statuses. So do authorization and use. A key can be structurally sound, match the expected public key and still be unavailable because policy rejects the caller. It can produce a signature that a relying application rejects because the message, context, algorithm policy, timestamp or certificate chain is wrong.

The migration label is not running code

RFC 5208 was published as Informational in 2008. RFC 5958 replaced it on the Standards Track in 2010, renamed the main structure, added optional public-key material, introduced a CMS content type and defined a version rule. These are concrete specification changes.

An inventory row saying RFC 5958 is not proof that every exporter, importer, backup path and recovery tool implemented them. Compatibility means old v1-shaped material can remain valid. It does not reveal which parser actually ran or whether a public-key field survived a round trip. Migration evidence requires test vectors, observed encodings, negative tests, version handling and recovery rehearsal.

A receipt chain that preserves authority

For each private-key movement, retain independent evidence for the exact source bytes; text or media decoding; ASN.1 version and algorithm parameters; plaintext or protected package type; KDF and encryption settings; decryption and integrity outcome; mathematical validation; public-key correspondence; import destination and export policy; caller authorization; performed operation; verification of its output; application acceptance; and cleanup.

Each receipt answers one question. A PRIVATE KEY label names representation. A successful decryption reports access to plaintext. A matching public key reports correspondence. An HSM audit event reports custody and use inside a boundary. A verified signature reports one operation over one message. The application reports whether that operation had the intended effect.

The leadership rule is simple: never let an earlier receipt approve a later layer automatically. Keep the common format small. Let local systems decide custody and authorization under explicit policy. Treat running operations and verified results as primary evidence, while retaining enough provenance to explain how the key reached them.

Sources

  1. RFC 5208 information
  2. RFC 5208 HTML
  3. RFC 5208 text
  4. IETF Datatracker: RFC 5208
  5. RFC 5208 history
  6. RFC 5208 references
  7. RFC 5208 errata
  8. RFC 5958 information
  9. RFC 5958 HTML
  10. RFC 5958 text
  11. IETF Datatracker: RFC 5958
  12. RFC 5958 history
  13. RFC 5958 references
  14. RFC 5958 errata
  15. RFC 8018 — password-based cryptography
  16. RFC 8351 — EncryptedPrivateKeyInfo media type
  17. RFC 7468 — textual encodings
  18. RFC 8479 — validation parameters in PKCS #8
  19. RFC 5915 — EC private-key structure
  20. Heng Lu — reality layers and symbolic power
  21. Heng Lu — minimum initial specification
  22. Heng Lu — running-code primacy