-
Notifications
You must be signed in to change notification settings - Fork 49
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
support PIV attestation #623
Comments
The deivce does not contain Yubico's root cert, that has to be fetched OOB via their webpage: https://developers.yubico.com/yubico-piv-tool/Attestation.html |
This sounds a bit like the mistake of conflating two independent PKIs that we made with gpg keys, where we included expiration date, master/sub key delegation info, etc. although similar information is also provided by the in-toto/tuf context. This only made verification more complex without a security benefit. IMO it's the same here. It's a good idea to verify the certificate, when the key is included in the in-toto/tuf context (e.g. on |
Yeah I kind of agree... Yet I can see how a repository would like to enforce that keys are hw generated, which it can't since signer import happens at signer device. It's valid to say that thats a signing system implementation problem and not a securesystemslib problem -- implementing a Key/Signer pair that handles this outside of securesystemslib is actually probably not too hard 🤔 |
Hm, okay, I didn't think of the signer -> repository trust bootstrapping. I guess, if we add support to for this (extract sig, fetch root certificate, verify) to I just want to make sure that the use case is clear. A tuf/in-toto client should definitely see the key in metadata as single authority and not require an additional certificate. |
I think the canonical example of this is Sigstore's root of trust. In the repsitory, all key attestations are stored. Today there is custom tooling that can verify that a given key is a proper Yubikey. What I see is that we are looking at two different trust levels.
If a user is convinced to trust the keyholders the user can then use the TUF repo. The client tooling would thus as @lukpueh mentions simply trust the signature of the metadata as the user provided a What I think is the topic here is that if the new key type (with PIV attestation) would simplify the process of convincing the comminity to trust the TUF repo (and keyholders) in the first place, as it's guaranteed that secure Yubikeys are used. |
I will try to resist getting nerd sniped further but I'll document the design that yesterdays chat crystallized:
|
This all sounds good. I'm not a big fan of hardcoding a root certificate into securesystemslib, but we could ask |
This came up in a discussion with @kommendorkapten:
I haven't thought this through very well and it may be complicated enough to implement that it does not make sense in securesystemslib:
The text was updated successfully, but these errors were encountered: