The Signature header makes use of Structured Headers to encapsulate a number of parameters.

However, the structural layout of the specification makes it difficult to easily determine what parameters are signed and unsigned. Through a careful reading, it would appear that only cert-url is unsigned.

This came up when trying to evaluate the proposal in #397 to understand the assurance level of different fields, at different points within the algorithm. For example, the current algorithm for validating a signature would appear to be making use of a signed field before the signature has actually been verified.

A few thoughts come to mind to help simplify this:

• In the discussion of the parameters that participate in the signature, clearly indicate whether each parameter is covered by the 'sig' or not.
• In the discussion of validation algorithms, either
  1. Ensure that signature validation is consistently performed before any accesses to unvalidated data
  2. Use descriptive labels to indicate the level of assurance that each field as. For example, unverified-validityUrl becomes signed-validityUrl after the signature has been checked, while integrity becomes unverified-integrity, transitions to signed-integrity after signature validation, and becomes verified-integrity after the (certificate and revocation) checks.

The idea here is to try to encapsulate, in the spec, the state machine that each of these variables goes through, so that it's clear whether we're operating on 'untrusted' (not yet signature checked / certificate checked) data or after. While an implementation may simply use the same variable throughout the implementation, the annotations help highlight the assurance. This also helps for future spec changes, because any reordering of sequences would cascade into re-evaluating the labels for any variables.

Or this might all be a terrible idea, but it was definitely hard to read and reason about the algorithm without knowing clearly whether the variables were signed and when/if they'd been validated.