-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add compact umbilical format #31
Conversation
This is only available for CAs that require umbilical evidence. Instead of storing the certificates directly in the evidence, we store the sha256 fingerprint. In each batch, the CA publishes an extra file called umbilical-certificates. This is just a list of X509 certificates together with an index to look them up by hash. The certificate referred to in the evidence doesn't have to appear in the same batch, but could appear in any batch within the validity window. This deduplicates intermediates, and deduplicates when multiple MTCs are issued using the same umbilical leaf certificate.
// | 32-byte key | uint64 offset | uint24 length | | ||
// +-------------+---------------+---------------+ | ||
// | ||
// key is the SHA-256 hash of the blob (although presently that fact is not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the fact that the key is the SHA-256 hash of the blob used in compressEvidence
to derive the key from the blob?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or do you mean that a cryptographic hash isn't needed? We could add a new function to compute the key from the blob so the caller doesn't need to know that internally it's a SHA-256 hash.
func (h *Handle) Key(blob []byte) []byte {
var [32]byte key
_, _ = h.hasher.Write(blob)
h.hasher.Sum(key[:0])
h.hasher.Reset()
return key[:]
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the fact that the key is the SHA-256 hash of the blob used in
compressEvidence
to derive the key from the blob?
It's not used in the lookup code.
@@ -19,6 +19,7 @@ import ( | |||
|
|||
"github.com/bwesterb/mtc" | |||
"github.com/bwesterb/mtc/umbilical" | |||
"github.com/bwesterb/mtc/umbilical/frozencas" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this package name be frozencerts
instead, since we're also compressing end-entity certs? Or just blobs
or blobstore
since there's really nothing in that package specific to certificates, and it could be re-used for other evidence types in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😆 I meant Frozen Content Addressed Storage, but I see now that that is an ambiguous name.
Co-authored-by: Luke Valenta <[email protected]>
This is only available for CAs that require umbilical evidence.
Instead of storing the certificates directly in the evidence, we store the sha256 fingerprint.
In each batch, the CA publishes an extra file called umbilical-certificates. This is just a list of X509 certificates together with an index to look them up by hash. The certificate referred to in the evidence doesn't have to appear in the same batch, but could appear in any batch within the validity window.
This deduplicates intermediates, and deduplicates when multiple MTCs are issued using the same umbilical leaf certificate.
Closes #25