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) SignerVerifiermakes 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?
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?