Improve "STEP 1: Authorization" in metadata update cli

[lukpueh]

What do you want to share with us?

The alternative metadata update cli proposal (#490) does not include "STEP 1: Authorization" of the current cli. It seemed wrong to ask for signing keys before it is clear, what signing keys are needed. (Note that the main goal of the cli is to change what keys are needed for signing.)

I understand now that the intention is to restrict usage to key holders (before the update) only, and require their signature to finalize the update. So for UX reasons it makes sense to ask for the key and fail early, if the user doesn't have it.

I'm happy to implement this on the atlernative metadata update cli, but I have some important suggestions:

1. Let's not call it "Authorization"

   In TUF a root Key holder is authorized by adding their public key to root metadata. This is actually the goal of this cli, but not in step 1. A more suitable term would be "Authentication". Because the user authenticates themselves by proofing that they have the private key for a public key.

   But even "Authentication" does not seem quite right, at least for what you are currently doing (see below). And it could be confused with unrelated API authentication.

   Maybe we can just call this something like "Key Holder Check" and explain that only key holders are allowed to update metadata.

2. Indeed, authenticate the key (holder).

   Currently, the tool asks the user to load an arbitary private key and then checks if it matches the public key in metadata by keyid. This makes the tool very dependent of how the keyid is computed, and does not necessarily work with arbitrary private keys. It would be more reliable to do actual cryptographic public key authentication.

3. Tell the user for which public keys they need to load one private key.

4. Consider separating signing from "Key Holder Check".

   Currently, the tool automatically signs the resulting metadata with the signing keys provided in step 1. This means that we can't sign the metadata with any newly added keys.

   It's okay to transparently use the initally loaded private key to provide one signature. But then the user could be prompted for more signing keys.

References

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[MVrachev]

What do you want to share with us?

The alternative metadata update cli proposal (#490) does not include "STEP 1: Authorization" of the current cli. It seemed wrong to ask for signing keys before it is clear, what signing keys are needed. (Note that the main goal of the cli is to change what keys are needed for signing.)

I understand now that the intention is to restrict usage to key holders (before the update) only, and require their signature to finalize the update. So for UX reasons it makes sense to ask for the key and fail early, if the user doesn't have it.

I'm happy to implement this on the atlernative metadata update cli, but I have some important suggestions:

1. Let's not call it "Authorization"
   In TUF a root Key holder is authorized by adding their public key to root metadata. This is actually the goal of this cli, but not in step 1. A more suitable term would be "Authentication". Because the user authenticates themselves by proofing that they have the private key for a public key.
   But even "Authentication" does not seem quite right, at least for what you are currently doing (see below). And it could be confused with unrelated API authentication.
   Maybe we can just call this something like "Key Holder Check" and explain that only key holders are allowed to update metadata.

I am okay with this.

2. Indeed, authenticate the key (holder).
   Currently, the tool asks the user to load an arbitary private key and then checks if it matches the public key in metadata by keyid. This makes the tool very dependent of how the keyid is computed, and does not necessarily work with arbitrary private keys. It would be more reliable to do actual cryptographic public key authentication.

Okay, good idea.
Curious what exactly do you plan on doing for that.
Do you plan on utilizing unrecognized fields to write a signature for a known phrase?
I think I am in favor of resigning the signed portion of TUF metadata and comparing it to the signature existing in signatures.
The limitation here is that only keys that have already signed this root can do that.

3. Tell the user for which public keys they need to load one private key.
   Good idea.

4. Consider separating signing from "Key Holder Check".
   Currently, the tool automatically signs the resulting metadata with the signing keys provided in step 1. This means that we can't sign the metadata with any newly added keys.
   It's okay to transparently use the initally loaded private key to provide one signature. But then the user could be prompted for more signing keys.

I see two possibilities:

1. automatically used the load key for signing, but notify the user
2. ask the user if he wants to reuse the key loaded during the Key holder check.

I think 1 is okay. If you load a key I don't see why you wouldn't want to sign with that key.

References

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[lukpueh]

I am okay with this.

👍

Okay, good idea. Curious what exactly do you plan on doing for that. Do you plan on utilizing unrecognized fields to write a signature for a known phrase? I think I am in favor of resigning the signed portion of TUF metadata and comparing it to the signature existing in signatures. The limitation here is that only keys that have already signed this root can do that.

Not sure I understand your comment. I'm thinking of something like the SSH Public Key Authentication Method (rfc4252). But we can sign anything we want.

I see two possibilities:

1. automatically used the load key for signing, but notify the user
2. ask the user if he wants to reuse the key loaded during the Key holder check.

I think 1 is okay. If you load a key I don't see why you wouldn't want to sign with that key.

Agreed. Given that the signature is required to finish the update, it doesn't make much sense to ask if they want to provide it.

[lukpueh]

I'm thinking of something like the SSH Public Key Authentication Method (rfc4252). But we can sign anything we want.

Depending on the chosen signing mechanism this authorization/authentication might not be transparent for the user. Typically we want to use an HSM here, which might prompt the user to physically tap the token, which in turn might make the user wonder why they need to do that.

I see several options:

1. Explain to the user, why they need to sign something before signing the metadata.
2. Not cryptographically authenticate, but just ask the user to load the key. In that case, the user might still realise that they don't have the right key after having done all the update work.
3. Not load the key, plus optionally tell the user that they will need a key eventually.

Since this feature is not security relevant but "only" to improve ux, I lean towards option 3 for now and improve ux later.

[MVrachev]

Am I right to assume we have decided we wouldn't use authorization for metadata update CLI?
At least that's what we decided for the new CLI pr: #523