[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec makes it difficult to distinguish signed and unsigned parameters #434

Open
sleevi opened this issue May 15, 2019 · 0 comments
Open

Comments

@sleevi
Copy link
sleevi commented May 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant