From bfdda2c5033051932c9ff0fefc09af09f6e2b596 Mon Sep 17 00:00:00 2001 From: Lois Anne DeLong Date: Mon, 9 Nov 2020 18:25:51 -0500 Subject: [PATCH 1/6] Responding to Issue #48 I wrote a response to Issue #48 for this page. @JustinCappos offered to do a write-up on the other two questions on the page. The text above is basically taken from the text @JustinCappos and @tkfu already had shared on the discussion thread. I blended those comments and then @patrickvacek looked over my draft and made some suggestions. --- faq.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/faq.md b/faq.md index fad7da5..8f3e5ec 100644 --- a/faq.md +++ b/faq.md @@ -5,4 +5,30 @@ css_id: faq # Frequently asked questions +### **What makes Uptane different from other SOTA security mechanisms?** + + + + +### **How does Uptane work with other systems and protocols?** + + + + +### **Must all signatures be valid for a threshold of signatures to be valid?** +The threshold requirement of Uptane, mentioned in [Section 5.4.4.3](https://uptane.github.io/uptane-standard/uptane-standard.html#check_root) and in descriptions of other roles, stipulates that a set number of keys are required to sign a metadata file. This is designed to prevent attacks by requiring would-be hackers to compromise multiple keys in order to install malware. However, what happens if this threshold is met, but one or more of the keys is not valid? + +As currently configured, the Uptane Standard allows each implementer to decide whether these keys would be accepted. Take the following example: + +Root metadata says valid top-level targets keyids are A, B, C, and D, with a threshold of 2. Should the following two metadata files be considered valid? + +* Signed by A, B, and X, where X is not present at all in root metadata + +* Signed by A, B, and C, but B's signature doesn't actually match the signed content + +The first case can happen when you include X in a newer version of root metadata (for example the next iteration), so this has to be handled correctly or it will complicate the process of adding and rotating keys. The second case could happen when you are changing or adding signing algorithms. This case can occur if B is using a new signing scheme and the client does not notice, but will know how to parse it after the update. + +Both the Uptane Standard and the Reference Implementation consider both of these cases valid, and the implementation also includes unit tests to verify this behavior. + +We would welcome input from the community as to whether a case can be made for specifying one option over another. From fe867c51a21f745e3b98302c4964dbe9a67e21e7 Mon Sep 17 00:00:00 2001 From: Lois Anne DeLong Date: Tue, 10 Nov 2020 09:05:07 -0500 Subject: [PATCH 2/6] Update faq.md --- faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq.md b/faq.md index 8f3e5ec..571c303 100644 --- a/faq.md +++ b/faq.md @@ -19,7 +19,7 @@ css_id: faq ### **Must all signatures be valid for a threshold of signatures to be valid?** The threshold requirement of Uptane, mentioned in [Section 5.4.4.3](https://uptane.github.io/uptane-standard/uptane-standard.html#check_root) and in descriptions of other roles, stipulates that a set number of keys are required to sign a metadata file. This is designed to prevent attacks by requiring would-be hackers to compromise multiple keys in order to install malware. However, what happens if this threshold is met, but one or more of the keys is not valid? -As currently configured, the Uptane Standard allows each implementer to decide whether these keys would be accepted. Take the following example: +The Uptane Standard allows each implementer to decide whether these keys would be accepted. Take the following example: Root metadata says valid top-level targets keyids are A, B, C, and D, with a threshold of 2. Should the following two metadata files be considered valid? From 98c9fec1d96704a9f94d154180b68c36523c23bc Mon Sep 17 00:00:00 2001 From: Lois Anne DeLong Date: Tue, 10 Nov 2020 09:05:33 -0500 Subject: [PATCH 3/6] Update faq.md Co-authored-by: Patrick Vacek --- faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq.md b/faq.md index 571c303..851e414 100644 --- a/faq.md +++ b/faq.md @@ -21,7 +21,7 @@ The threshold requirement of Uptane, mentioned in [Section 5.4.4.3](https://upta The Uptane Standard allows each implementer to decide whether these keys would be accepted. Take the following example: -Root metadata says valid top-level targets keyids are A, B, C, and D, with a threshold of 2. Should the following two metadata files be considered valid? +Root metadata lists valid top-level Targets key identifiers are A, B, C, and D, with a threshold of 2. Should the following two metadata files be considered valid? * Signed by A, B, and X, where X is not present at all in root metadata From 1cc7d965764daae5face20860e244af6865a26aa Mon Sep 17 00:00:00 2001 From: Lois Anne DeLong Date: Tue, 10 Nov 2020 09:05:53 -0500 Subject: [PATCH 4/6] Update faq.md Co-authored-by: Patrick Vacek --- faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq.md b/faq.md index 851e414..fdf1058 100644 --- a/faq.md +++ b/faq.md @@ -23,7 +23,7 @@ The Uptane Standard allows each implementer to decide whether these keys would b Root metadata lists valid top-level Targets key identifiers are A, B, C, and D, with a threshold of 2. Should the following two metadata files be considered valid? -* Signed by A, B, and X, where X is not present at all in root metadata +* Signed by A, B, and X, where X is not present at all in Root metadata * Signed by A, B, and C, but B's signature doesn't actually match the signed content From 4a53416eda50c89b87bb2e4425a20ad9ec6e7891 Mon Sep 17 00:00:00 2001 From: Lois Anne DeLong Date: Tue, 10 Nov 2020 09:06:54 -0500 Subject: [PATCH 5/6] Update faq.md Co-authored-by: Patrick Vacek --- faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq.md b/faq.md index fdf1058..ce3b60b 100644 --- a/faq.md +++ b/faq.md @@ -27,7 +27,7 @@ Root metadata lists valid top-level Targets key identifiers are A, B, C, and D, * Signed by A, B, and C, but B's signature doesn't actually match the signed content -The first case can happen when you include X in a newer version of root metadata (for example the next iteration), so this has to be handled correctly or it will complicate the process of adding and rotating keys. The second case could happen when you are changing or adding signing algorithms. This case can occur if B is using a new signing scheme and the client does not notice, but will know how to parse it after the update. +The first case can happen when you include X in a newer version of Root metadata (for example the next iteration), so this has to be handled correctly or it will complicate the process of adding and rotating keys. The second case could happen when you are changing or adding signing algorithms. This case can occur if B is using a new signing scheme that the client currently does not understand, but will know how to parse it after the update. Both the Uptane Standard and the Reference Implementation consider both of these cases valid, and the implementation also includes unit tests to verify this behavior. From b3322b366b414b923b77306fde77d77e8562c574 Mon Sep 17 00:00:00 2001 From: Lois Anne DeLong Date: Tue, 10 Nov 2020 09:15:58 -0500 Subject: [PATCH 6/6] Update faq.md Co-authored-by: Patrick Vacek --- faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq.md b/faq.md index ce3b60b..dd9efe8 100644 --- a/faq.md +++ b/faq.md @@ -27,7 +27,7 @@ Root metadata lists valid top-level Targets key identifiers are A, B, C, and D, * Signed by A, B, and C, but B's signature doesn't actually match the signed content -The first case can happen when you include X in a newer version of Root metadata (for example the next iteration), so this has to be handled correctly or it will complicate the process of adding and rotating keys. The second case could happen when you are changing or adding signing algorithms. This case can occur if B is using a new signing scheme that the client currently does not understand, but will know how to parse it after the update. +The first case can happen when you include X in a newer version of Root metadata (for example the next iteration), so this has to be handled correctly or it will complicate the process of adding and rotating keys. The second case could happen when you are changing or adding signing algorithms. This case can occur if B is using a new signing scheme that the client currently does not understand, but will know how to parse after the update. Both the Uptane Standard and the Reference Implementation consider both of these cases valid, and the implementation also includes unit tests to verify this behavior.