You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been working to get cosign to use an externally generated key pair for signing.
Using OpenSSL to generate the P-256 key pair, I then used yubico-piv-tool to import in the keys into slot 9C with ID 2.
When I tried to sign a blob using the command cosign sign-blob --sk test.file --bundle signature.bundle, I would get the following error message:
Error: signing test.file: data object or application not found
main.go:74: error during command execution: signing test.file: data object or application not found
In tracing through the code, I found that the function func (k *Key) SignerVerifier makes a call to k.card.Attest (within the go-piv/piv-go package). This function attests that the key was generated by the YubiKey. In my scenario, that is not true, so it errors out.
This appears limiting because if a private key is generated on a YubiKey, it cannot be exported for back up. Also, this precludes the use case have having keys generated from an external source and distributed onto a YubiKey.
Would it be possible to add a –-no-attest option to the list of –sk parameters to bypass this attestation as an enhancement?
Or is there another command sequence to support by use case?
The text was updated successfully, but these errors were encountered:
Question
I have been working to get cosign to use an externally generated key pair for signing.
Using OpenSSL to generate the P-256 key pair, I then used yubico-piv-tool to import in the keys into slot 9C with ID 2.
When I tried to sign a blob using the command
cosign sign-blob --sk test.file --bundle signature.bundle
, I would get the following error message:In tracing through the code, I found that the function
func (k *Key) SignerVerifier
makes a call tok.card.Attest
(within the go-piv/piv-go package). This function attests that the key was generated by the YubiKey. In my scenario, that is not true, so it errors out.This appears limiting because if a private key is generated on a YubiKey, it cannot be exported for back up. Also, this precludes the use case have having keys generated from an external source and distributed onto a YubiKey.
Would it be possible to add a
–-no-attest
option to the list of–sk
parameters to bypass this attestation as an enhancement?Or is there another command sequence to support by use case?
The text was updated successfully, but these errors were encountered: