Title: The Representation of Cryptographic Key Material Author: David Huseby Email: dhuseby@linuxfoundation.org # The Representation of Cryptographic Key Material ## Introduction The purpose of this document is to gather into one place the current state of the art of storing cryptographic key material and to analyze the pros and cons of the existing systems and to conclude with a recommendation for the approach to be used for the emerging W3C Decentralized Identifiers Specification [^did-spec] (DID spec). This document is broken up into roughly three sections. The first section focuses on the ancient key representations (e.g. X.509 [^x509], Public Key Cryptography Standards [^pkcs], GNU Privacy Guard [^gnupg]) followed by a section focused on the modern key representations (e.g. JSON Web Key [^jwk], Secure Scuttlebutt [^ssb]). The last section focuses on synthesizing a recomendation for a unified approach to be used in the new DID spec. ### General Attributes of All Key Representations For all key representations there are four main things that must be accounted for to make them interoperable and extensible: context, provenance, authenticity, and application. #### Context The context of a key representation signals to any implementor the additional data needed to properly decode and interpret the representation. The context is divided up into the file encoding format, the expected fields and the key encoding format. Context can be defined externally in a specification or internally using some self-describing format. Without the context not only is there no common agreement on the interpretation of the representation but there is also no orderly mechanism for governance of the agreed upon standard. #### Provenance The provenance of a key representation defines for any consumer of a certificate the necessary data used to verify the authenticity and the "freshness" of the key. The provenance system is key to creating transitive trust in any system based on public key cryptography whether they are top-down in nature such as the Certificate Authority [^ca] (CA) system, bottom-up in nature such as the web of trust [^wot] (WoT) system, or a hybrid of the two such as the self-sovereign identity [^ssi] (SSI) system. Different representations have different ways of providing provenance with some being stronger than others. #### Authenticity The authenticity of the key representation is anything used to ensure that the data as received by the consumer is authentic, has not been modified, and it comes from the source that the recipient intends to receive it from. Like provenance, different systems have different ways of establishing authenticity of a representation with some being stronger than others. #### Application The application data in a representation includes data specifying the cryptographic algorithms a key is intended to be used with along with any modifiers/limitations on the usage of the key (e.g. signing, encrypting, etc). The application also includes any data specifying the proper procedure for revocation, rotation, and recovery of the key. Early representations only concerned themselves with the modifiers and limitations on usage but in the more modern, decentralized systems with public provenance and authenticity systems, the key management data plays a much more important part. ## The Ancient Representations What follows is a discussion of the ancient key material representations. After each system is describe there is a brief discusssion about how it accommodates the four aspects described above. ### X.509 and Certificate-Based Key Management The original digital certificate specification is described in RFC 1422 [^rfc1422] and is explicitly defined as a "compliant subset of that envisioned in X.509". RFC 1422 was written as part of the overall "private enhanced mail", or PEM, initiative meant to upgrade email systems to support stronger identity and privacy through the use of public key cryptography. RFC 1422 defines version 1, and subsequent updates by the ITU-T (version 2) and the IETF (version 3) refined it to the version we used today described in RFC 5280 [^rfc5280]. The X.509 representation is relevant to this discussion because it was the first major attempt to decide exactly what constitutes a public key and how it should be represented. The RFCs state their intent was to provide a verifiable record (i.e. digitally signed by an issuer) of a public key that can be stored in, and transmitted through, insecure environments. The parallels to the DID spec are obvious so it makes sense to consider this design as we execute a new standard. The contents of a version 3 digital certificate has two layers, an outer envelope containing the inner certificate followed by the digital signature over the certificate and the digital signature algorithm identifier. The inner certificate contains a number of other fields including the public key itself. The full listing of fields in a v3 digital certificate are listed below. ``` 1) certificate 1.1) format version 1.2) certificate serial number 1.3) digital signature algorithm identifier 1.4) issuer identifier 1.5) validity period 1.6) subject name 1.7) public key with algorithm identifier 1.8) unique identifiers (v2 and v3 only) 1.9) certificate extensions (v3 only) 2) digital signature algorithm identifier 3) digital signature value ``` **Listing 1** -- Fields of a version 3 digital certificate. #### Context The X.509 digital certificate system relies on and external context set by the standard described in RFC 5280 and updates added in RFC 6818 [^rfc6818] (updates to interpretation), RFC 8398 [^rfc8398] (internationalized email addresses), and RFC 8399 [^rfc8399] (internationalization updates). The standard specifies that all digital certificates are to be encoded using ASN.1 representation. #### Provenance #### Authenticity * digital signature over the ASN.1 encoded certificate. * #### Application ### Public Key Cryptography Standards (PKCS) #### Context #### Provenance #### Authenticity #### Application ### GNU Privacy Guard #### Context #### Provenance #### Authenticity #### Application ## The Modern Representations ### JSON Web Key #### Context #### Provenance #### Authenticity #### Application ### Secure Scuttlebutt #### Context #### Provenance #### Authenticity #### Application ## The DID Represenation #### Context #### Provenance #### Authenticity #### Application [^did-spec]: https://w3c.github.io/did-core/ [^x509]: https://en.wikipedia.org/wiki/X.509 [^pkcs]: https://en.wikipedia.org/wiki/PKCS [^gnupg]: https://en.wikipedia.org/wiki/GNU_Privacy_Guard [^jwk]: https://tools.ietf.org/html/rfc7517 [^ssb]: https://ssbc.github.io/scuttlebutt-protocol-guide/ [^ca]: https://en.wikipedia.org/wiki/Certificate_authority [^wot]: https://en.wikipedia.org/wiki/Web_of_trust [^ssi]: https://wiki.p2pfoundation.net/Self-Sovereign_Identity [^rfc1422]: https://tools.ietf.org/html/rfc1422 [^rfc5280]: https://tools.ietf.org/html/rfc5280 [^rfc6818]: https://tools.ietf.org/html/rfc6818 [^rfc8398]: https://tools.ietf.org/html/rfc8398 [^rfc8399]: https://tools.ietf.org/html/rfc8399