Propose TAP 11 #74
Propose TAP 11 #74
Conversation
There was a problem hiding this comment.
@heartsucker
We at NYU are reviewing TAP 11 and giving it some thought. I anticipate others sharing their thoughts and chiming in soon.
My initial reaction is hesitation at having the specification mandate a specific key format, however, others here have not quite dismissed the idea of mandating a specific key format. I personally wonder if it's better for adopters to choose the format of keys listed in metadata.
What are your reasons for requiring PKCS#8, apart from it being a preference?
This review contains my comments of TAP 11 while reading it.
\cc @JustinCappos @awwad @lukpueh @SantiagoTorres @trishankkarthik
|
|
||
| All keys have the format: | ||
|
|
||
| { "keytype" : KEYTYPE, |
There was a problem hiding this comment.
This format does not match the one below, which includes an additional field (scheme).
|
|
||
| - Redefine how key IDs are calculated | ||
| - Specify usage of PKCS#8 encoding and OID for ed25519 keys | ||
| - Remote `public` wrapper from `keyval` |
| "keyval" : PUBLIC | ||
| } | ||
|
|
||
| In both the 'ed25519' and 'rsa' cases, the PUBLIC portion of the key is PKCS#8 encoded and in PEM |
There was a problem hiding this comment.
It's good to use examples with RSA and Ed25519 keys, but I was surprised to see highly specific restrictions with respect to Ed25519's OID. Does it make sense for us to place restrictions for only these two key types, and leave all other key type restrictions to the discretion of adopters?
There was a problem hiding this comment.
This again comes back to interop. If we want Ed25519 keys to be parseable by many impls, we have to use the same OID.
| format. ed25519 keys MUST use the algorithm identifier with OID 1.3.101.112 (curveEd25519) and MUST | ||
| NOT use the algorithm identifier with OID 1.2.840.10045.2.1 (ecPublicKey). | ||
|
|
||
| The KEYID of a key is the hex digest of the SHA-256 hash of the DER encoded PUBLIC value. |
There was a problem hiding this comment.
This TAP states that TUF is moving towards supporting any metadata format, and argues that specific formats should be avoided so that Key IDs are calculated independent of the metadata format.
I am confused as to why the TAP now requires DER to calculate Key IDs.
There was a problem hiding this comment.
What other method would be relatively encoding agnostic for hashing to a key ID?
| format. ed25519 keys MUST use the algorithm identifier with OID 1.3.101.112 (curveEd25519) and MUST | ||
| NOT use the algorithm identifier with OID 1.2.840.10045.2.1 (ecPublicKey). | ||
|
|
||
| The KEYID of a key is the hex digest of the SHA-256 hash of the DER encoded PUBLIC value. |
There was a problem hiding this comment.
Should we require SHA-256? What if we left the choice of hashing algorithm to adopters?
There was a problem hiding this comment.
If we don't care about interop, then this whole TAP could get torched. If we do, we have to specify the hash.
There was a problem hiding this comment.
Well this actually would be helpful in being backwards compatible and help libraries figure out the hash algorithm with in-band information.
| "keyval" : PUBLIC | ||
| } | ||
|
|
||
| In both the 'ed25519' and 'rsa' cases, the PUBLIC portion of the key is PKCS#8 encoded and in PEM |
There was a problem hiding this comment.
You made a follow-on comment indicating that PEMs should not be specified in metadata to minimize size. Should the TAP be updated?
We had an internal discussion at work and were using this as a bit of a weather vane to answer the question:
Of the code I've looked at (apart from my person stuff and our work stuff), it seems everything copies the python implementation thus making it a de facto standard. In some other discussion I've had with y'all, it seems that answer to the above question is "no, we're not specifying formats," but the community hasn't taken up on that. If this is the case, I'd say we actually nix this PR and open another one on the main repo that rewrites the spec as something format agnostic. |
|
Let me address the interoperability issue first off. I think that having a
potential format for interoperability of TFUF / Uptane would be desirable,
but we did not make it part of the spec. The reason was that we were told
many automakers / other adopters would want to define their own format or
at least tweak it so we were better making this change-able (i.e.,
intentionally non-interoperable).
Note: There is nothing that stops you or others from advocating a specific
format that would be interoperable. In fact, I don't see a problem with us
mentioning a specific interoperable format in our deployment guidelines for
Uptane or on our website. Is your format compatible with our reference
implementation?
…On Wed, Sep 20, 2017 at 5:56 AM, heartsucker ***@***.***> wrote:
@vladimir-v-diaz <https://github.com/vladimir-v-diaz>
My initial reaction is hesitation at having the specification mandate a
specific key format...
We had an internal discussion at work and were using this as a bit of a
weather vane to answer the question:
Should TUF completely definite key formats, metadata formats, etc. per
encoding (JSON, DER), and should we expect any interoperability between
implementations?
Of the code I've looked at (apart from my person stuff and our work
stuff), it seems everything copies the python implementation thus making it
a de facto standard. In some other discussion I've had with y'all, it seems
that answer to the above question is "no, we're not specifying formats,"
but the community hasn't taken up on that.
If this is the case, I'd say we actually nix this PR and open another one
on the main repo that rewrites the spec as something format agnostic.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#74 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XDwMpax2aJMoDNIBxvqh1hltEm-8rks5skOFlgaJpZM4PX1lZ>
.
|
|
We'd also be interested in hearing from @ecordell @endophage @hannesm. |
|
I'd like to make sure some things are clear: Key format specification
Metadata specification
As a side-note, the question of whether or not someone's metadata is compatible with the TUF or Uptane reference implementations can be split into two questions:
|
|
I don't agree entirely with the motivations, but I do think this is a reasonable and worthwhile effort to increase interoperability. My preference would be for the PKCS#8 in PEM format as proposed, this meets many compliance requirements we see in enterprise. I would ask though why we don't go a step further than proposed. The It would be necessary (and I think reasonable, this would not be the only place we already do similar at docker), to then also specify clients cannot deserialize and reserialize the PEM unless they also intend to perform the necessary signing for the roles in question. FWIW this general principle has helped us maintain a number of integrity guarantees in docker products even when the specification of a particular data format changes. |
|
@endophage We actually don't even need the key IDs. The clients have to calculate them locally anyway then verify they match what's in the metadata. We could just send a list of keys and let the clients calculate the key ID locally. If they do it the same way the server does, then there's no reason to include them in the transport encoding. |
|
@heartsucker I recall you explaining somewhere why a key ID might be unnecessary. Can you provide a link to this explanation so that I can review/think about it again? A key ID can succinctly identify any type of key data. It is included in the "signatures" field of metadata (example), and to bind keys to roles (example). If not a keyID, are you suggesting that we instead place the full key data in these cases? |
|
Here's the discussion: theupdateframework/rust-tuf#118 Key IDs are still used as they are now. Because they are deterministic, both parties will generate the same values from a given key, so they don't need to transport them. |
|
|
||
| # Motivation | ||
|
|
||
| If a TUF respository exsits that serves content in DER format, then all servers and clients must |
| format. ed25519 keys MUST use the algorithm identifier with OID 1.3.101.112 (curveEd25519) and MUST | ||
| NOT use the algorithm identifier with OID 1.2.840.10045.2.1 (ecPublicKey). | ||
|
|
||
| The KEYID of a key is the hex digest of the SHA-256 hash of the DER encoded PUBLIC value. |
|
@erickt Thanks for bumping this in my list of issues. This is definitely something I'd love to see move forward soon! |
|
@heartsucker We're likely moving toward moving the specific format outside of the core TUF spec. ( #106 ) Is it okay, if we close this PR and move this issue to the wireline format instead as a result? |
|
Some people, such as Datadog, are using the TUF reference implementation in production. I just saw that the TAPs for pre-release and release schedules were closed without announcements beforehand. Where would backwards-incompatible TAPs like this be implemented? I think we need to answer this question before moving forward. |
|
TAPs that break backwards compatibility will be implemented in a forthcoming (major version changing) release of TUF. We'll discuss what to do about posting information about release schedules / project roadmaps. I want to expose this information in the most transparent, helpful way possible. Ideally, I'd like to do something uniform for the lab and many projects do not have a TAP / ITE process or similar to manage forthcoming releases... |
|
Closing this due to this being superseded by addition of POUFs in #106 |
Also, as as note, I think using PEM encoding and not just BASE64 is a waste of bytes. That means every key has
-----BEGIN PUBLIC KEY-----and-----END PUBLIC KEY-----as well as a few newlines. In a large repo where thousands of keys might be distributed, this adds up. This also only affects text-based formats like JSON or XML.