search

w3c / wot-ejs

Repository to store the content on Enveloped JSON Signatures spun off from the discussion on WoT Security, e.g., https://github.com/w3c/wot-thing-description/pull/1151
2 stars 2 forks source link

Resolve TD dependencies #4

Open mmccool opened 2 years ago

mmccool commented 2 years ago

There are certain things in the current document that depend on TDs, e.g. expansion of named references in security objects, that need to be resolved (e.g. added to TD canonical form).

mmccool commented 2 years ago

See discussion under https://github.com/w3c/wot-thing-description/issues/300. One key dependency is the expansion of names into the object they reference, but this is not currently possible with "security" in TD 1.1 if we want to keep 1.0 backward compatibility. So it's hard to add this to TD canonicalization. However, we need to sort out versioning to deal with some existing compatibility problems, so...

mmccool commented 2 years ago

Options include:

  1. Making Canonical TDs not 1.1 TDs; this makes them suitable only for signing.
  2. Ignoring the compatibility problem, and allowing use of objects in "security" for 1.1 TDs. This would make some 1.1 TDs, and Canonical TDs in particular, not validate as 1.0 TDs.
  3. Not dereferencing security objects in Canonical TDs. This opens the risk that some signatures may not include the security definitions, allowing an attacker to change them without breaking the signature. This could be mitigated by checking that any signature that includes a "security" clause also includes "securityDefinitions", but this complicates signature computation and specializes them to TDs (and also, if signatures are not normative, how could we require this?). A consumer could always reject signature that did not sign securityDefinitions, however.
  4. Supporting dereferenced security objects only in 2.0 TDs, and defining canonical form there.

Right now I'm leaning towards 4. Options 1 and 2 are too problematic. We could combine 3 and 4, although this would mean slightly different canonical forms for 1.x and 2.0 TDs and a security hazard (which could be mitigated by consumers) in 1.x TDs.