renamed with correct date

1 files changed, 533 insertions, 0 deletions

diff --git a/archive/2022-03-15-notes-on-sigsum-and-rekor.md b/archive/2022-03-15-notes-on-sigsum-and-rekor.md
new file mode 100644
index 0000000..d19e696
--- /dev/null
+++ b/archive/2022-03-15-notes-on-sigsum-and-rekor.md
@@ -0,0 +1,533 @@
+# A frequently asked question
+We are frequently asked how Sigsum compares to Sigstore.  This document
+highlights some technical similarities and differences as of March, 2022.
+
+Sigstore's sub-project Rekor and Sigsum are both transparency log designs that
+aim to make a signer's key-usage transparent.  By enabling end-users to verify
+that signatures they trust are public, they are protected from accepting
+malicious signatures that were created in secret (e.g., due to key compromise).
+
+The following transparency log concepts are explored side-by-side:
+
+  - Purpose of logging
+  - What is logged
+  - Auditing
+  - Gossip
+  - Anti-poison
+  - Anti-spam
+  - Privacy
+  - API
+  - Promises of future logging (SCTs)
+  - Sharding
+
+There is also an Appendix at the end with relevant code snippets.
+
+## Purpose of logging
+
+**Sigsum**
+
+No signature that an end-user accepts as valid should go unnoticed by anyone who
+inspects the log.
+
+Sigsum is designed to be secure even if an attacker controls:
+
+  - The signer's infrastructure and signing key
+  - The log's infrastructure and signing key
+  - A threshold of independent witnesses that cosign the log
+
+The log operator is not trusted beyond being available at the time of logging.
+
+**Sigstore/Rekor**
+
+[Rekor's README][] says that the goal is to "[e]nable software maintainers and
+build systems to record signed metadata to an immutable record", and that it
+"fulfils the signature transparency role of sigstore's software signing
+infrastructure".  [No threat model][] is available at the time of writing.
+
+[Rekor's README]: https://github.com/sigstore/rekor/tree/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5#readme
+[No threat model]: https://web.archive.org/web/20220312143825/https://docs.sigstore.dev/security/
+
+## What is logged
+
+**Sigsum**
+
+A shard hint, a SHA256 checksum, an Ed25519 signature, and a SHA256-hashed
+public key.  The signed blob is based on the [SSH format][].  The logged
+signatures are verifiable by anyone who knows the corresponding public keys.
+
+[SSH format]: https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig
+
+**Sigstore/Rekor**
+
+Signed manifests called [pluggable types][].  The rekord type allows signatures
+based on Signify, Minisign, SSH, and PGP, as well as PKIX/X.509.  For example,
+you could log a signature for a PGP email that was received in 2002.  There are
+several other pluggable types with more to come.  Rekor is overall permissive.
+
+Some pluggable type signatures are not verifiable in isolation for a monitor
+that observes the log because to verify a signature data is needed that is not
+included in the log and might be known only to the creator of the signature, see
+"Example 1: unverifiable signatures" in the Appendix at the end.  This means
+that it is impossible to distinguish between unverifiable log entries fabricated
+by the log and log entries maliciously created with a signer's private key.
+
+[pluggable types]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/pkg/types/README.md
+
+## Auditing
+How will end-users verify that public logging took place?
+
+**Sigsum**
+
+End-users receive inclusion proofs and cosigned tree heads that can be verified
+offline in the same way that data and signatures are currently delivered (a
+website, a git repository, etc).  No other network communication is required.
+
+This means that a sigsum log does not have to be available to the end-user after
+logging succeeded to verify that public logging took place.
+
+**Sigstore/Rekor**
+
+End-users [query the log][] to check that a signature is included.  This means
+the log needs to stay available to end-users at all times, also see "Privacy".
+
+Alternatively, an end-user may trust a signed promise (SCT) from Rekor to
+include a signature in the future, see "Promises of future log inclusion".
+
+[query the log]: https://web.archive.org/web/20220312144545/https://www.sigstore.dev/how-it-works
+
+## Gossip
+A mechanism that ensures everyone observes the same append-only log.  A
+transparency log without gossip requires trusting the log operator and the
+integrity of the log's signing key.
+
+**Sigsum**
+
+Gossip is handled proactively using a simplified version of witness cosigning
+([S&P 2016][]).  It can be thought of as a policy-based consensus mechanism:
+m-of-n witnesses audit the log's consistency from their respective vantage
+points.  The log distributes the witnesses' signatures, which end-users and
+monitors make use of.  This ensures that a malicious sigsum log operator is
+unable to fool even an offline verifier.
+
+[S&P 2016]: https://arxiv.org/pdf/1503.08768.pdf
+
+**Sigstore/Rekor**
+
+Does not have gossip.  Sigstore proposes to instead use multiple independent
+[full-fledged logs][].  Logs have more freedom to fool a verifier than cosigning
+witnesses and are harder and more expensive to run.
+
+Signers would have to take great care to submit the same entries to all the logs
+and would have to monitor all of them.  End-users would have to contact and/or
+trust multiple logs when verifying.
+
+[full-fledged logs]: https://web.archive.org/web/20220312144801/http://web.archive.org/screenshot/https://docs.sigstore.dev/faq
+
+## Anti-poison
+A transparency log design must take caution to not include large amounts of
+arbitrary data, as someone could submit information that is illegal to possess
+or distribute. Because the log operator cannot selectively erase information
+from the log without invalidating it, the operator may be compelled to shut down
+the log, or simply choose to not operate a log in the first place.
+
+**Sigsum**
+
+Include as little arbitrary information as possible.  A log entry contains a
+time value (a shard hint, in the interval `[shard_start, now()]`) of which the
+least significant few bytes are arbitrary. The remaining content can only be
+specified by brute forcing signatures or hashes so that parts of them contain
+certain patterns.  This quickly becomes expensive.
+
+**Sigstore/Rekor**
+
+The pluggable type system allows logging of a wide variety of information.  The
+rekord type for instance allows encoding an image, see "Example 2: logging JPG
+images" in the Appendix at the end.  Other current and future pluggable types
+might permit similar things but we have not looked into that further.
+
+## Anti-spam
+An approach to limit abusive logging requests that consume the log's capacity.
+
+**Sigsum**
+
+A logging request is only accepted if the involved public key is hashed into a
+DNS TXT record.  So, rate limits can be based on DNS names.  This is similar to
+the anti-spam mechanisms that CT relies on, where a certificate is not accepted
+unless it chains up to a trusted CA.  Let's Encrypt [rate-limits via DNS][].
+
+[rate-limits via DNS]: https://web.archive.org/web/20220312145502/https://letsencrypt.org/docs/rate-limits/
+
+**Sigstore/Rekor**
+
+Recently opened an issue about [needing rate-limits][].  It has since been added
+to Sigstore's infrastructure setup based on IP addresses via Nginx.
+
+[needing rate-limits]: https://github.com/sigstore/rekor/issues/637
+
+## Privacy
+
+**Sigsum**
+
+For end-users, nothing changes with regard to privacy compared to signature
+verification that does not make use of a transparency log.
+
+A signer has to expose to the log operator a public key and a 32-byte preimage
+([which should be a hash][]).
+
+The signer's hashed public key is exposed in DNS, see "Anti spam".  Logs can be
+be instructed to fetch such TXT resource records if they match `_sigsum_v0.*`.
+
+Log entries consisting of a shard hint, hashes and signatures become public, see
+"What is logged".
+
+[which should be a hash]: https://git.sigsum.org/sigsum/tree/doc/design.md?id=741a65ab1894b35c9cc132d9b8401776c04fe1ce#n351
+
+**Sigstore/Rekor**
+
+End-users that query the log for entries they are interested in expose this
+information to the log.
+
+A signer's public key and data is exposed to the log operator.  The data may be
+a hash if [using X.509/PKIX][] signatures and the "hashed rekord type".
+
+Logs can be instructed to download arbitrary data from [specified URLs][].
+
+The content of pluggable types become public, notably including public keys and
+other data that may be encoded (which depends on the exact pluggable type).
+
+[using X.509/PKIX]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/types.md#hashed-rekord
+[specified URLs]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/openapi.yaml#L143
+
+## API
+
+**Sigsum**
+
+Simple ASCII parsers are used to add input and get output from the log.  Binary
+data is hex-encoded.  Data that is signed and/or logged can be (de)serialized
+using Tor's easy wire-format, [Trunnel][].  The overall take of the API is to
+keep it as simple as possible, and to nudge towards correct usage by design.
+
+[Trunnel]: https://gitweb.torproject.org/trunnel.git/tree/doc/trunnel.md
+
+**Sigstore/Rekor**
+
+REST API with JSON, both for input and output as well as canonicalization of
+data.  Some parts of the API are easily misused due to returning redundant
+and/or unauthenticated data.  This happened [once][] and [twice][] already.
+
+Other types of mis-usage are likely to be expected.  For example, the
+availability of public keys makes it tempting to inappropriately use Rekor for
+key discovery even though it is not designed to be a trustworthy source of keys.
+
+The implementation complexity of Rekor's API is also relatively large.  Imports
+contain much hidden complexity, in part due to pluggable types that involve PGP,
+ASN.1, and such.  This has already lead to issues like Rekor starting to return
+[YAML instead of JSON][]; JSON marshalling of tree leaves [not being canonical
+enough][]; the [need of another PGP library][]; etc.  It will likely be hard to
+understand, implement, and maintain Rekor compliant software in the long run.
+
+[once]: https://github.com/sigstore/rekor/issues/200
+[twice]: https://github.com/sigstore/rekor/pull/469
+[YAML instead of JSON]: https://github.com/sigstore/rekor/issues/593
+[not being canonical enough]: https://github.com/sigstore/rekor/pull/445
+[need of another PGP library]: https://github.com/sigstore/rekor/issues/286
+
+## Promises of future log inclusion (SCTs)
+A construct that enables low-latency logging.  Certificate Transparency
+introduced this to work with the existing TLS PKI during a gradual roll-out
+scenario.  Nine years later such roll-outs are still in the earlier stages.
+
+**Sigsum**
+
+Does not support SCTs. Unlike the TLS case there is no existing system to be
+compatible with and use-cases that cannot tolerate a few minutes of logging
+latency are out-of-scope.  This is a trade-off that keeps the design simple.
+
+**Sigstore/Rekor**
+
+[Supports SCTs][]. If an entry (promised to be logged by an SCT) is not included
+in the log in time the operator should not be trusted in the future.  This
+places high requirements on uptime and availability, and on not losing the log
+request between the time of issuing an SCT and inclusion in the log.  Rekor
+avoids this by simply including the signature in the log [before issuing][] the
+SCT. That however provides no latency reduction, making SCTs pointless.
+
+The mere existence of SCTs also encourages their use, making users who rely on
+them not receive the full benefits of using a transparency log.  We are not
+aware of any clear plans specifying how Sigstore will solve SCT verification.
+Without such plans, the log may deceive end-users by changing its history.
+
+[Supports SCTs]: https://twitter.com/lorenc_dan/status/1388109774579982340
+[before issuing]: https://github.com/sigstore/rekor/blob/a61d5f63843cbae4e5bf1f97d06628fa914a4435/openapi.yaml#L493
+
+## Sharding
+The practise of dividing a log into smaller independent partitions.  One of
+Certificate Transparency's successes is [temporal sharding][] based on expiry
+date to allow log rotation (helpful to make log life cycles more manageable).
+
+[temporal sharding]: https://web.archive.org/web/20220312150931/https://googlechrome.github.io/CertificateTransparency/log_policy.html
+
+**Sigsum**
+
+Establishes shards based on shard hints in the interval `[shard_start, now()]`.
+Shard hints are part of the signer's signing context and cannot be forged,
+preventing past entries from being re-logged in a newer shard.  A log can also
+cease its operations safely due to Sigsum's take on offline auditing.  This
+gives a complete story for log life cycles without any expiration dates.
+
+**Sigstore/Rekor**
+
+Creates [virtual shards][], see also related [GitHub issues][].  The latest
+virtual shard is active.  All other virtual shards are kept around but in
+read-only mode.  If a virtual shard was to be deleted those entries can be
+logged again.  As old virtual shards have to be saved, this gives a complicated
+log configuration but does not provide any of the benefits of sharding.
+
+[virtual shards]: https://docs.google.com/document/d/1QBTyK-wquplNdeUB5_aqztQHigJOepCvd-4FL4H-zl8/edit?resourcekey=0-grdVbSltkTvpNvhj03laCQ#
+[GitHub issues]: https://github.com/sigstore/rekor/issues/353
+
+# Appendix
+## Example 1: Unverifiable signatures
+The input to a signature verification is a public key, a message, and a
+signature.  Rekor incorrectly assumes that the signed message ("artifact")
+is always a hash.
+
+First we demonstrate the issue using `signify`.
+
+**Step 1 - Generate a key-pair**
+
+    $ signify-openbsd -G -c "demo" -p example.pub -s example.sec
+    passphrase:
+    confirm passphrase:
+    $ ls
+    example.pub  example.sec
+
+**Step 2 - Create something to sign**
+
+    $ echo 'print("hello")' > hello.py
+    $ sha256sum hello.py
+    b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180  hello.py
+    $ ls
+    example.pub  example.sec  hello.py
+
+**Step 3 - Sign**
+
+    $ signify-openbsd -Ss example.sec -m hello.py
+    passphrase:
+    $ ls
+    example.pub  example.sec  hello.py  hello.py.sig
+
+**Step 4 - Log**
+
+The below uses Rekor on commit 6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5.
+
+    $ rekor-cli upload \
+          --artifact hello.py\
+          --signature hello.py.sig\
+          --pki-format=minisign\
+          --public-key=example.pub\
+          --rekor_server http://localhost:3000
+    Created entry at index 99, available at: http://localhost:3000/api/v1/log/entries/bf5f87c83bfffc3b0d3d0151a6cfef836594dcd90ac286541b25856b7d6fd6b1
+    $ rekor-cli get --log-index 99 --rekor_server http://localhost:3000
+    LogID: e0f8a8ff472431bda298489c292f33f5d30363949df58d2e35c5195f915c7069
+    Index: 99
+    IntegratedTime: 2022-03-12T11:59:28Z
+    UUID: bf5f87c83bfffc3b0d3d0151a6cfef836594dcd90ac286541b25856b7d6fd6b1
+    Body: {
+      "RekordObj": {
+        "data": {
+          "hash": {
+            "algorithm": "sha256",
+            "value": "b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180"
+          }
+        },
+        "signature": {
+          "content": "dW50cnVzdGVkIGNvbW1lbnQ6ClJXVE9PWDNrMjE0L3VDR0VuQWtHaC9wOGxCK2o4ZlU0bzN2aFpzc3dud2RFeDE2M2REUHpReE1BVXdUcUFjK1ovaGdycGdISU5VNHlFbnhPOXNwSnkydmZmcHdWSUJIV3lnWT0=",
+          "format": "minisign",
+          "publicKey": {
+            "content": "UldUT09YM2syMTQvdUg1RVhHbUFwdDZWSnhxVUlJZzIrWnMrajlFRDNTM1ZGOXBHSzZoWDRLSmM="
+          }
+        }
+      }
+    }
+
+Let's understand the above in more detail.  Our public key and signature is in
+the above output, but without the untrusted comment which is irrelevant.
+
+    cat example.pub
+    untrusted comment: demo public key
+    RWTOOX3k214/uH5EXGmApt6VJxqUIIg2+Zs+j9ED3S3VF9pGK6hX4KJc
+    $ echo UldUT09YM2syMTQvdUg1RVhHbUFwdDZWSnhxVUlJZzIrWnMrajlFRDNTM1ZGOXBHSzZoWDRLSmM= | base64 -d
+    RWTOOX3k214/uH5EXGmApt6VJxqUIIg2+Zs+j9ED3S3VF9pGK6hX4KJc
+    $
+    $ cat hello.py.sig
+    untrusted comment: verify with example.pub
+    RWTOOX3k214/uCGEnAkGh/p8lB+j8fU4o3vhZsswnwdEx163dDPzQxMAUwTqAc+Z/hgrpgHINU4yEnxO9spJy2vffpwVIBHWygY=
+    $ echo "dW50cnVzdGVkIGNvbW1lbnQ6ClJXVE9PWDNrMjE0L3VDR0VuQWtHaC9wOGxCK2o4ZlU0bzN2aFpzc3dud2RFeDE2M2REUHpReE1BVXdUcUFjK1ovaGdycGdISU5VNHlFbnhPOXNwSnkydmZmcHdWSUJIV3lnWT0=" | base64 -d
+    untrusted comment:
+    RWTOOX3k214/uCGEnAkGh/p8lB+j8fU4o3vhZsswnwdEx163dDPzQxMAUwTqAc+Z/hgrpgHINU4yEnxO9spJy2vffpwVIBHWygY=
+
+Rekor also stored a SHA256 hash: 
+
+    "RekordObj": {
+      "data": {
+        "hash": {
+          "algorithm": "sha256",
+          "value": "b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180"
+        }
+      },
+
+You might recognize it from step 2.  It is the output of `sha256sum hello.py`.
+What is needed to do verification with the logged signature and public key is
+the output of `cat hello.py`.  This is because signify signs those exact bytes
+without doing any hashing (unlike other schemes that actually do sign a hash).
+
+The impact is that you cannot know by observing the log if a real signature
+operation happened (there is nothing to verify), or if the Rekor operator
+fabricated an entry.  The signature would be verifiable if the data can be
+located.  In the case of a malicious signature this might not be the case.
+
+**The same issue in other places**
+
+Minisign has the same issue, even with its pre-hashed mode because Minisign
+[does not use SHA256][] which is what Rekor still stores.  The exact same issue
+is also there for SSH signatures.  We did not dig into any other types.
+
+[does not use SHA256]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/pkg/pki/minisign/minisign.go#L109
+
+## Example 2: Logging JPG images
+As shown above Rekor scrubs some information that was submitted for logging.
+Most likely to not accept arbitrary bytes, such as signify's untrusted comments.
+To protect Rekor against logging of illegal content, each pluggable type needs
+to be considered in more detail.  Below is an example that encodes a JPG image.
+
+**Step 1 - Create an image**
+
+    $ convert -size 16x16 xc:red red.jpg
+    $ ls
+    red.jpg
+
+This also works with larger images, e.g., `-size 4096x4096`.
+
+**Step 2 - Encode image in an X.509 configuration**
+
+    $ echo "[ req ]" > crt.cnf
+    $ echo "distinguished_name = dn" >> crt.cnf
+    $ echo "x509_extensions = extensions" >> crt.cnf
+    $ echo "prompt = no" >> crt.cnf
+    $ echo "" >> crt.cnf
+    $ echo "[ extensions ]" >> crt.cnf
+    $ echo "1.2.3.4 = ASN1:UTF8String:$(base64 -w0 red.jpg)" >> crt.cnf
+    $ echo "" >> crt.cnf
+    $ echo "[ dn ]" >> crt.cnf
+    $ echo "0.DC = com" >> crt.cnf
+    $ echo "1.DC = example" >> crt.cnf
+    $ echo "commonName = example.com" >> crt.cnf
+    $ ls
+    crt.cnf  red.jpg
+
+Credit: [this post][] outlines how an X.509v3 extension can be prepared.
+
+[this post]: https://serverfault.com/questions/1005029/error-when-trying-to-add-custom-extensions-to-x509-certificates-using-openssl
+
+**Step 3 - Create X.509 certificate**
+
+    $ openssl req -x509 -nodes\
+            -newkey ec:<(openssl ecparam -name prime256v1)\
+            -config crt.cnf\
+            -keyout priv.pem\
+            -out cert.pem
+    Generating an EC private key
+    writing new private key to 'priv.pem'
+    -----
+    $ ls
+    cert.pem  crt.cnf  priv.pem  red.jpg
+
+Note that we now have an X.509 certificate that encodes our image:
+
+    $ openssl x509 -in cert.pem -text -noout
+    Certificate:
+        Data:
+            Version: 3 (0x2)
+            Serial Number:
+                27:a5:0e:37:9c:3e:e1:0d:d7:a4:8f:10:ce:2d:09:35:40:9c:a8:1e
+            Signature Algorithm: ecdsa-with-SHA256
+            Issuer: DC = com, DC = example, CN = example.com
+            Validity
+                Not Before: Mar 12 13:46:06 2022 GMT
+                Not After : Apr 11 13:46:06 2022 GMT
+            Subject: DC = com, DC = example, CN = example.com
+            Subject Public Key Info:
+                Public Key Algorithm: id-ecPublicKey
+                    Public-Key: (256 bit)
+                    pub:
+                        04:9d:2a:5d:4c:df:d4:fa:9a:76:32:59:96:3b:44:
+                        12:00:03:3c:c0:d9:42:58:c1:fb:2a:ed:fb:0d:95:
+                        d0:ce:7d:62:e6:f8:ae:be:76:6b:3b:0c:44:aa:ca:
+                        43:57:cf:19:a3:c9:b1:cd:05:21:a2:b8:0c:50:13:
+                        0c:d9:9f:8f:ea
+                    ASN1 OID: prime256v1
+                    NIST CURVE: P-256
+            X509v3 extensions:
+                1.2.3.4:
+                    ..../9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAQABADAREAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAj/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFgEBAQEAAAAAAAAAAAAAAAAAAAcJ/8QAFBEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AnRDGqYAAD//Z
+        Signature Algorithm: ecdsa-with-SHA256
+             30:46:02:21:00:ee:ee:81:d6:1c:e8:a7:ca:dd:54:b5:82:fe:
+             22:1d:94:1d:b1:31:91:d6:3e:68:99:f5:d5:da:c9:f4:bc:53:
+             53:02:21:00:cd:08:98:c5:73:e8:a1:8f:8c:95:06:cc:5c:70:
+             65:aa:dd:94:f0:38:59:ec:f7:c7:35:98:eb:75:5f:23:eb:c5
+
+Compare the X.509v3 extensions to this:
+
+    $ base64 red.jpg
+    /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAQABADAREAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAj/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFgEBAQEAAAAAAAAAAAAAAAAAAAcJ/8QAFBEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AnRDGqYAAD//Z
+
+Now we need to get this X.509 certificate into Rekor.
+
+**Step 4 - Sign something**
+
+    $ openssl dgst -sha256 -sign priv.pem -out red.jpg.sig red.jpg
+    $ ls
+    cert.pem  crt.cnf  priv.pem  red.jpg  red.jpg.sig
+
+**Step 5 - Log**
+
+    $ rekor-cli upload \
+            --artifact red.jpg\
+            --signature red.jpg.sig\
+            --pki-format=x509\
+            --public-key=cert.pem\
+            --rekor_server http://localhost:3000
+    Created entry at index 102, available at: http://localhost:3000/api/v1/log/entries/688f817bb1e7cb1b28eadf173b0095724cce86ab0116b0df5a0c8e06c00e880c
+    $
+    $ rekor-cli get --log-index 102 --rekor_server http://localhost:3000
+    LogID: e0f8a8ff472431bda298489c292f33f5d30363949df58d2e35c5195f915c7069
+    Index: 102
+    IntegratedTime: 2022-03-12T13:51:30Z
+    UUID: 688f817bb1e7cb1b28eadf173b0095724cce86ab0116b0df5a0c8e06c00e880c
+    Body: {
+      "RekordObj": {
+        "data": {
+          "hash": {
+            "algorithm": "sha256",
+            "value": "4a837db6d6a21a9bdfccff6ca21f72d1d4a671b59a5df76158629ff5f6b22ddf"
+          }
+        },
+        "signature": {
+          "content": "MEYCIQD4HWtXfSDGpWUUmk1tWUP/V5MRUPgwrUMiiJB7miKZcQIhAJDYUO+lyGYKShCtt3AZZilZkoLEm9WAaXhlzGVwZMu6",
+          "format": "x509",
+          "publicKey": {
+            "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURKakNDQXN1Z0F3SUJBZ0lVSjZVT041dys0UTNYcEk4UXppMEpOVUNjcUI0d0NnWUlLb1pJemowRUF3SXcKUkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjRZVzF3YkdVeApGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUI0WERUSXlNRE14TWpFek5EWXdObG9YRFRJeU1EUXhNVEV6Ck5EWXdObG93UkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjQKWVcxd2JHVXhGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowRApBUWNEUWdBRW5TcGRUTi9VK3BwMk1sbVdPMFFTQUFNOHdObENXTUg3S3UzN0RaWFF6bjFpNXZpdXZuWnJPd3hFCnFzcERWODhabzhteHpRVWhvcmdNVUJNTTJaK1A2cU9DQVprd2dnR1ZNSUlCa1FZREtnTUVCSUlCaUF5Q0FZUXYKT1dvdk5FRkJVVk5yV2twU1owRkNRVkZCUVVGUlFVSkJRVVF2TW5kQ1JFRkJUVU5CWjBsRFFXZE5RMEZuU1VSQgpkMDFFUWtGWlJVSkJVVVZDUVdkSFFtZFZSME5SWjB0RFoydEpRMUZyUzBSQk9FMURaM05QUTNkclNrUlNSVTVFClp6aFJSVUpGVVVObmQxTkZlRWxSUlhjNFVVVkNSQzh5ZDBKRVFWRk5SRUYzVVVSQ1FXZEZRa0ZuVVVOM2EweEYKUWtGUlJVSkJVVVZDUVZGRlFrRlJSVUpCVVVWQ1FWRkZRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkJVVVZDUVZGRgpRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkVMM2RCUVZKRFFVRlJRVUpCUkVGU1JVRkJhRVZDUVhoRlFpODRVVUZHClVVRkNRVkZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdvdmVFRkJWVVZCUlVGQlFVRkJRVUZCUVVGQlFVRkIKUVVGQlFVRkJRUzg0VVVGR1owVkNRVkZGUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdOS0x6aFJRVVpDUlVKQgpRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZRTDJGQlFYZEVRVkZCUTBWUlRWSkJSRGhCYmxKRVIzRlpRVUZFCkx5OWFNQW9HQ0NxR1NNNDlCQU1DQTBrQU1FWUNJUUR1N29IV0hPaW55dDFVdFlMK0loMlVIYkV4a2RZK2FKbjEKMWRySjlMeFRVd0loQU0wSW1NVno2S0dQakpVR3pGeHdaYXJkbFBBNFdlejN4eldZNjNWZkkrdkYKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
+          }
+        }
+      }
+    }
+
+Of interest here is the public key:
+
+    $ echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURKakNDQXN1Z0F3SUJBZ0lVSjZVT041dys0UTNYcEk4UXppMEpOVUNjcUI0d0NnWUlLb1pJemowRUF3SXcKUkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjRZVzF3YkdVeApGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUI0WERUSXlNRE14TWpFek5EWXdObG9YRFRJeU1EUXhNVEV6Ck5EWXdObG93UkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjQKWVcxd2JHVXhGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowRApBUWNEUWdBRW5TcGRUTi9VK3BwMk1sbVdPMFFTQUFNOHdObENXTUg3S3UzN0RaWFF6bjFpNXZpdXZuWnJPd3hFCnFzcERWODhabzhteHpRVWhvcmdNVUJNTTJaK1A2cU9DQVprd2dnR1ZNSUlCa1FZREtnTUVCSUlCaUF5Q0FZUXYKT1dvdk5FRkJVVk5yV2twU1owRkNRVkZCUVVGUlFVSkJRVVF2TW5kQ1JFRkJUVU5CWjBsRFFXZE5RMEZuU1VSQgpkMDFFUWtGWlJVSkJVVVZDUVdkSFFtZFZSME5SWjB0RFoydEpRMUZyUzBSQk9FMURaM05QUTNkclNrUlNSVTVFClp6aFJSVUpGVVVObmQxTkZlRWxSUlhjNFVVVkNSQzh5ZDBKRVFWRk5SRUYzVVVSQ1FXZEZRa0ZuVVVOM2EweEYKUWtGUlJVSkJVVVZDUVZGRlFrRlJSVUpCVVVWQ1FWRkZRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkJVVVZDUVZGRgpRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkVMM2RCUVZKRFFVRlJRVUpCUkVGU1JVRkJhRVZDUVhoRlFpODRVVUZHClVVRkNRVkZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdvdmVFRkJWVVZCUlVGQlFVRkJRVUZCUVVGQlFVRkIKUVVGQlFVRkJRUzg0VVVGR1owVkNRVkZGUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdOS0x6aFJRVVpDUlVKQgpRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZRTDJGQlFYZEVRVkZCUTBWUlRWSkJSRGhCYmxKRVIzRlpRVUZFCkx5OWFNQW9HQ0NxR1NNNDlCQU1DQTBrQU1FWUNJUUR1N29IV0hPaW55dDFVdFlMK0loMlVIYkV4a2RZK2FKbjEKMWRySjlMeFRVd0loQU0wSW1NVno2S0dQakpVR3pGeHdaYXJkbFBBNFdlejN4eldZNjNWZkkrdkYKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" | base64 -d > logged-cert.pem
+    $ diff cert.pem logged-cert.pem
+    $
+
+As you can see, it is the same certificate that contains our JPG image.  Any
+other data could be encoded as well using the above trick.