Candidate TAP for POUFs #106
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JustinCappos
requested changes
Nov 9, 2018
|
TAP makes sense to me! |
|
@JustinCappos I added detail about creation, storage and security audits. |
Closed
|
I like where this is going, but I'm curious to know a little bit more about the specifics:
It'd be wise to mention that profile interoperability is not what a desireable goal. On the topic of storing and creating profiles. I'd think it'd be useful to mention what the process is to put it here (i.e., do we want to specify an acceptance process?). I know there's a security review process by the community, so I assume it'd be useful to mention how to report security issues with a profile. Further, we may want to consider if there's a "under review" or "proposal" state for profiles, so as to note them as candidates for a specific usage. I really would like to make profiles rare we should strive to avoid cases in which we have many profiles that are slightly different (e.g., ASN1-AUTOMOTIVE and ASN1-IOT profiles, that only vary in maximum string length or so). Thanks for taking a first stab at this, @mnm678 ! |
|
@SantiagoTorres I added some clarification and put the canonical json into an example profile. |
|
Does the profile that is used get mentioned somewhere in the metadata? Do implementations signal this? Is it part of saying you implement TUF 1.0.2p2? How do versions of profiles evolve with versions of the spec? Is there a separate profile for TUF 2.0.0 since the format has changed from 1.0.0? |
|
@JustinCappos I added a requirement that the TUF version be included in the profile and a proposed way to update them for new spec versions. I also state that the profile should be listed in the documentation of an implementation, but including it in root metadata might be a good option as well. |
JustinCappos
requested changes
Feb 6, 2019
Profiles/profile2.md
Outdated
| } | ||
| } | ||
|
|
||
| ### mirrors.json |
There was a problem hiding this comment.
I think this is obsolete. @awwad , can you confirm?
|
I have a small request
Could we have an ASN1. profile that we could point the Uptane standard to?
Like the following: https://github.com/uptane/asn1
I'm worried some are going to misimplement the standard by reading
ambiguous English
…On Wed, Feb 6, 2019 at 10:31 AM Justin Cappos ***@***.***> wrote:
***@***.**** requested changes on this pull request.
very minor changes requested. Let's post publicly after these are resolved
and get the broader community to comment, etc.
------------------------------
In Profiles/profile2.md
<#106 (comment)>
:
> +
+ The "path_hash_prefixes" list is used to succinctly describe a set of target
+ paths. Specifically, each HEX_DIGEST in "path_hash_prefixes" describes a set
+ of target paths; therefore, "path_hash_prefixes" is the union over each
+ prefix of its set of target paths. The target paths must meet this
+ condition: each target path, when hashed with the SHA-256 hash function to
+ produce a 64-byte hexadecimal digest (HEX_DIGEST), must share the same
+ prefix as one of the prefixes in "path_hash_prefixes". This is useful to
+ split a large number of targets into separate bins identified by consistent
+ hashing.
+
+ The "paths" list describes paths that the role is trusted to provide.
+ Clients MUST check that a target is in one of the trusted paths of all roles
+ in a delegation chain, not just in a trusted path of the role that describes
+ the target file. PATHPATTERN can include shell-style wildcards and supports
+ the Unix filename pattern matching convention. Its format may either
Should be more specific about the matching convention. Can you do regexes,
etc.? Matching is done by the shell and different shells support different
characters and functionality.
------------------------------
In Profiles/profile2.md
<#106 (comment)>
:
> + "spec_version": "1",
+ "expires": "2030-01-01T00:00:00Z",
+ "meta": {
+ "snapshot.json": {
+ "hashes": {
+ "sha256": "c14aeb4ac9f4a8fc0d83d12482b9197452f6adf3eb710e3b1e2b79e8d14cb681"
+ },
+ "length": 1007,
+ "version": 1
+ }
+ },
+ "version": 1
+ }
+ }
+
+### mirrors.json
I think this is obsolete. @awwad <https://github.com/awwad> , can you
confirm?
------------------------------
In tap11.md
<#106 (comment)>
:
> +
+# Abstract
+
+This TAP describes a mechanism called a profile that can be used to standardize wireline formats for systems using TUF. If clients and servers implement the same profile, they will have the same wireline format and thus be able to interoperate.
+
+# Motivation
+
+The designers of TUF made a conscious choice not to specify a wireline format. This was done to accommodate adopters who needed to maintain their existing wireline format due to interactions with other technologies, the requirements of legacy systems, or other unique design parameters. For example, it is possible to implement TUF with all of the data stored in JSON files, XML files, or a binary format. The choice of file type or wireline format does not impact the ability to correctly respond to key compromise, so long as the TUF spec is followed. However, without a shared wireline format, differing TUF implementations will not be able to interoperate.
+
+This TAP clarifies the point that, even though different wireline formats are expressly permitted, a mechanism is needed to allow different implementations of TUF to work together. This is done by creating publicly implementable, compatible wireline formats, which are called profiles. These defined wireline formats allow TUF implementations with the same profile to use the same file and/or wireline formats in a way that will make them interoperate.
+
+# Rationale
+
+A profile is needed if a TUF implementation must communicate with other implementations. This profile will include all definitions necessary to create a compatible implementation, including all of the data types and metadata files.
+
+Once created, these profiles should be added to the TAP repository to be used by others. This makes the profile available to the TUF community. All profiles should receive a security audit (described below) by a third party before it is used to ensure flaws are not propagated.
Not sure about the audit part here. It's slightly odd to audit the file
formats. What are you auditing for?
------------------------------
In tap11.md
<#106 (comment)>
:
> +
+## Managing profiles
+
+Profiles should be shared with other developers to allow for the creation of compatible implementations. These profiles are to be securely stored online and accessed only when needed during the development of TUF compliant applications.
+
+An organization may also choose to store these documents in a central place. Yet it is recommended that profiles still be made available on the TAP repository to allow for community review.
+
+Profiles are not generic. While a given profile will allow all implementations that adopt it to work together, other profiles on the repository may not support interoperability. It is important that implementations list in their documentation the profile or profiles that are supported as well as the version numbers for these profile(s).
+
+## Security Audit
+
+The security audit will ensure that the profile is a valid implementation of TUF and check for security flaws and vulnerabilities. For most profiles, this audit will consist of ensuring that all fields correspond to those in the TUF specification. For more complex profiles, any libraries or additional data structures should also be audited to be sure they do not add security flaws.
+
+The security audit will be written up and posted with the profile and will certify that the profile is compliant to the current version of the TUF specification. Any relevant security concerns will also be noted.
+
+If security issues are found after the security audit, they should be promptly reported to both the profile author and a TUF contributor. By initially reporting the issue privately, it can be addressed without leaving existing implementations vulnerable to a publicly posted attack. Once resolved, the issue should be added to the security audit for the profile.
What is an example of a security issue with a profile? I'm having a hard
time picturing this from the text here.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#106 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfmSEbRAIUMtrpMJluG9PXHv_JXpvtYqks5vKvVqgaJpZM4YXUff>
.
|
JustinCappos
requested changes
Aug 28, 2019
|
@JustinCappos I edited to address your review. |
…and added some clarification
mnm678
force-pushed
the
wireline-format
branch
from
78e1b3f
to
8f8a8a6
Compare
|
@JustinCappos I added line breaks and addressed your comments. |
JustinCappos
approved these changes
Sep 4, 2019
|
This supersedes #74. |
|
Thanks @mnm678 ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This TAP outlines the creation of a wireline format for TUF. This format will allow the creation of 'POUFs' that specify a wireline format and can be used to allow interoperability.
POUFs are not required for implementing TUF.