Skip to content
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

Implement TAP 12 #1084

Open
1 of 3 tasks
mnm678 opened this issue Jul 17, 2020 · 6 comments
Open
1 of 3 tasks

Implement TAP 12 #1084

mnm678 opened this issue Jul 17, 2020 · 6 comments
Assignees

Comments

@mnm678
Copy link
Contributor

mnm678 commented Jul 17, 2020

Add tap12 to the reference implementation. This TAP allows for greater flexibility in how keyids are generated. This will require the following changes to the client:

  • Remove all use of keyid_hash_algorithms and instead use the keyid defined by the repository. This step is well documented in Documenting or creating a TAP to describe keyid_hash_algorithms #848.
  • Check that all keys applied to a signature are unique using a standardized representation (ex modulus and exponent for rsa) so that the same key with multiple keyids cannot be applied to a threshold.
  • Make a local keydb for each delegating targets role so that keys can be locally scoped to their delegating instance (ie where the keys are defined in the delegating role and used in the delegated role)

The repository code should not need to change as sha256 may still be used to generate keyids.

@mnm678 mnm678 self-assigned this Jul 17, 2020
@mnm678
Copy link
Contributor Author

mnm678 commented Jul 17, 2020

I have started on step 1 in #1014.

@lukpueh
Copy link
Member

lukpueh commented Sep 28, 2020

Two quick questions:

  1. Is there a plan to completely remove keyid_hash_algorithms in the course of the TAP 12 implementation? If not, we need to create a separate issue to do so.
  2. Do others think the removal of the field deserves a decision record (Keep track of procedural and architectural decision #1141)?
    Documenting or creating a TAP to describe keyid_hash_algorithms #848 has become quite a focal point for related discussions (see the many mentions from other GH issues/prs). Is it worth to retain a summary of these discussions?

@mnm678
Copy link
Contributor Author

mnm678 commented Sep 28, 2020

1. Is there a plan to completely remove `keyid_hash_algorithms` in the course of the TAP 12 implementation? If not, we need to create a separate issue to do so.

Removing keyid_hash_algorithms would be part of a TAP 12 implementation, but it might be worth adding a separate issue as we decided in #1095 that most of the TAP 12 implementation should wait on the refactor work.

2. Do others think the removal of the field deserves a _decision record_ (#1141)?
   #848 has become quite a focal point for related discussions (see the many mentions from other GH issues/prs). Is it worth to retain a summary of these discussions?

As this is already discussed in a TAP, I don't know if a decision record is needed. However, I'd rather over-document than under-document, so if others disagree we can add one.

@joshuagl
Copy link
Member

1. Is there a plan to completely remove `keyid_hash_algorithms` in the course of the TAP 12 implementation? If not, we need to create a separate issue to do so.

Removing keyid_hash_algorithms would be part of a TAP 12 implementation, but it might be worth adding a separate issue as we decided in #1095 that most of the TAP 12 implementation should wait on the refactor work.

I think it would be good to document the removal of keyid_hash_algorithms explicitly in a separate issue, it's related to TAP 12 but not blocked by it.

2. Do others think the removal of the field deserves a _decision record_ (#1141)?
   #848 has become quite a focal point for related discussions (see the many mentions from other GH issues/prs). Is it worth to retain a summary of these discussions?

As this is already discussed in a TAP, I don't know if a decision record is needed. However, I'd rather over-document than under-document, so if others disagree we can add one.

I think it could be good to add a decision record. The field is unique(?) to the reference implementation and hasn't been documented in the specification, therefore I think it a) doesn't make sense to look for documentation on this field's removal in the specification documentation (taps) and b) regardless, it should be explicitly documented in the implementation's repository.

@jku
Copy link
Member

jku commented Feb 22, 2022

This does not require much, if any, work in current python-tuf: we don't assume anything about keyids currently (most importantly, there's no expectation that keys are unique globally: same name can be used in different keys in different delegating metadata). Using keyids like "keyA" or "offline root key #1" should just work.

@mnm678
Copy link
Contributor Author

mnm678 commented Mar 4, 2022

I think we can even call ngclient the reference implementation for the TAP. We haven't solved the standard representation for keys, but I think that can be safely left to the discretion of delegators (as they are already trusted to delegate to arbitrary keys).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants