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

Integrity Signature Header is Under-Specified #2

Closed
otherdaniel opened this issue Aug 22, 2017 · 4 comments
Closed

Integrity Signature Header is Under-Specified #2

otherdaniel opened this issue Aug 22, 2017 · 4 comments

Comments

@otherdaniel
Copy link

The Integrity: header is only introduced as:

Integrity: ed25519-[base64-encoded result of Ed25519(console.log("Hello, world!");)]

  1. It doesn't say anything about whether there can only be one or multiple values per header, or how multiple headers would be treated,
    1a. it would likely be easiest if this were to have the same general format as the integrity attribute with multiple allowed valued, and multiple headers being treated the same as their concatenated values,
    1b. not sure if comma separation of tokens should also be allowed, or whether that's a Chromium specific thing.
    2, The prefix "ed25519-" is used to specify the key in the main resource, but used to specify the signature in the header. These should probably be different prefixes, as these are different things with different lengths.
@mnot
Copy link
Contributor

mnot commented Oct 2, 2017

+1.

Also, Integrity is a bad name for this; it doesn't describe what the header is. Something like Signature is more appropriate.

The tricky part of this is describing what is being signed; the body is a given, but headers need careful consideration. Content-Type is an obvious one here, but since so much policy is being put into headers these days, some amount of flexibility is probably going to be necessary.

@jyasskin
Copy link
Member

jyasskin commented Oct 4, 2017

@mnot I think it may be a mistake to allow signers to choose what subset of headers is signed. e.g. http://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html#breaking shows how to break DKIM in practice because people made bad choices about what to sign and what unsigned content to trust.

We may need to have the Signature: header say what order to concatenate headers, but then we also need to say that any header not included is simply dropped.

Also see #5 for an argument to include the URL and maybe other request headers.

@mnot
Copy link
Contributor

mnot commented Oct 4, 2017

Canonicalisation is the big concern. Sometimes people don't have access to the exact bytes of their headers, sometimes implementations try to be "helpful", and sometimes middle boxes do things.

Also, the set of significant headers for signing can change both over use cases and time.

There probably needs to be a minimal set of headers, and the ability to add to it. C

@mikewest
Copy link
Member

mikewest commented Oct 9, 2024

Closing this in favor of #16.

@mikewest mikewest closed this as not planned Won't fix, can't repro, duplicate, stale Oct 9, 2024
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

4 participants