Add attestation for sign public key #4
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@ve7jtb Does this look like a sensible way to implement attestation for the signing keys?
I chose to reuse the existing attestation object structure rather than invent yet another attestation statement format to improve the chances for this to be compatible with existing TPM hardware and such. This also keeps the internal structure of the attestation signing procedure parameters since I noticed that not doing that leads to incompatibility issues (see w3c#2075). This way, RPs should be able to reuse existing implementations of the attestation verification procedures and only pass new arguments to them.
One major drawback of this design is that it duplicates a lot of data between the parent attestation and the signing key attestation, most notably the
x5cfield of most attestation statements. I checked and saw that my YubiKey 5 generates an attestation object of ~1080 bytes, so this could double that.We probably could prune the embedded attestation object and have the client and/or RP re-assemble it from other copies of the constituent data, but I didn't want to get into quite that much complexity just yet.