uptane · jhdalek55 · Nov 10, 2020 · Nov 9, 2020 · Nov 10, 2020 · Nov 10, 2020
diff --git 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?**
 
-
+
+Security problems occur due to accidental disclosures, malicious attacks, disgruntled insiders.  It is not
+a matter of whether a successful attack will occur, but when.  One key feature of a security system is the
+ability to securely recover from an attack.  This means that an update system must have a way to securely 
+recover from a key loss or compromise.  
+
+For example, suppose a nation-state actor steals a signing key and wants to use it to distribute software (as has
+happened before) [cite Iran, etc.].  The update system must provide a way to revoke the current trusted
+information even if the adversary is able to be a man-in-the-middle for future communications.  Uptane 
+is designed to provide strong security in cases like these and is designed so that failures are 
+compartmentalized and limited in scope.  
+
+No other automotive update system has been designed to work in such rigorous situations or has 
+received the public scrutiny of Uptane.  We follow best practice in the security community by having
+wide-scale, public review.  This has been proven to be essential time and time again to ensure a 
+design will hold up against attackers, especially those as strong as nation-state actors.  Furthermore,
+Uptane's design is heavily influenced by the design of TUF, a widely used software update system 
+with a strong track record of usability and security across millions of devices.  As a free and open
+standard, with no cost to use or adopt, Uptane stands alone in the automotive update space.
+
-
+
+Security problems occur due to accidental disclosures, malicious attacks, disgruntled insiders.  It is not
+a matter of whether a successful attack will occur, but when.  One key feature of a security system is the
+ability to securely recover from an attack.  This means that an update system must have a way to securely 
+recover from a key loss or compromise.  
+
+For example, suppose a nation-state actor steals a signing key and wants to use it to distribute software (as has
+happened before) [cite Iran, etc.].  The update system must provide a way to revoke the current trusted
+information even if the adversary is able to be a man-in-the-middle for future communications.  Uptane 
+is designed to provide strong security in cases like these and is designed so that failures are 
+compartmentalized and limited in scope.  
+
+No other automotive update system has been designed to work in such rigorous situations or has 
+received the public scrutiny of Uptane.  We follow best practice in the security community by having
+wide-scale, public review.  This has been proven to be essential time and time again to ensure a 
+design will hold up against attackers, especially those as strong as nation-state actors.  Furthermore,
+Uptane's design is heavily influenced by the design of TUF, a widely used software update system 
+with a strong track record of usability and security across millions of devices.  As a free and open
+standard, with no cost to use or adopt, Uptane stands alone in the automotive update space.
+
+
+
+
+
+### **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?
+
+The Uptane Standard allows each implementer to decide whether these keys would be accepted. Take the following example:
+
+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 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 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.