Implementation should throw if it would overwrite an Existing Authorization or Signature Header.

[aljones15]

In the signature step:

Case 1: Adding a header if no existing Authorization or Signature Header exists.

Case 2: Adding a Signature header when there is an existing Authorization header that is not the same as the existing Authorization header.

In all other cases you need to throw an error.

[ioggstream]

I suggest to define the authorization header in another draft. This one is already too complex.

Il gio 15 ago 2019, 20:34 Andrew Jones notifications@github.com ha scritto:

In the signature step:

Case 1: Adding a header if no existing Authorization or Signature Header exists.

Case 2: Adding a Signature header when there is an existing Authorization header that is not the same as the existing Authorization header.

In all other cases you need to throw an error.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c-dvcg/http-signatures/issues/85?email_source=notifications&email_token=AAIWQ3ES2K5AJWHFPZGOFTLQEWOR7A5CNFSM4IMAXD32YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HFPX3ZA, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIWQ3CKRPQ3FZPWRSVPERLQEWOR7ANCNFSM4IMAXD3Q .

[liamdennehy]

In all cases, simply add the requested header.

We're adding authentication or authenticity assurances to a message, it shouldn't matter if it already has one from me or someone else.

• as a client, I'm forwarding someone else's message and want to sign it for a different purpose e.g. As a proxy or gateway.
• I may want multiple parties to sign a message before sending it
• I may want to sign a message I just received as a form of "digital receipt" for my own logs.

Any implementer is going to decide for themselves what constitutes a valid signature (alg, minimum headers etc) and may keep checking all received headers until it finds one it understands and accepts. They may also choose to reject messages with more than one signature. Up to them.

I don't think explicitly constraining the spec to a single instance of a header type is worthwhile. What we're describing is how to validate a presented header, not the header.

[liamdennehy]

@ioggstream, this spec actually started life with only the authentication scheme:

https://tools.ietf.org/id/draft-cavage-http-signatures-01.html

If anything, Signature: is the intruder 😋

[msporny]

In all cases, simply add the requested header.

@ioggstream @liamdennehy -- we need to be really careful here, I don't think there has been enough red teaming on these cases. We had a discussion in the office yesterday where we found 3 ways where it's safe to add the header and many other cases where it is not.

This really needs to be thought through, this discussion has raised a number of questions regarding the security characteristics of people blindly misusing the specification (and they will). Like, how does this compose w/ Bearer tokens, how does it compose with the SXG stuff, how does it compose w/ other signatures by other parties. There are compos-ability problems here that can be addressed w/ simple language in the specification, but we absolutely should not think that this is a trivial issue and we can easily address it by just doing X.

In any case, just want to make sure if anyone is thinking "oh, this is easy, we'll just do X" that they pause and take a breath, because this issue is not that easy to say "oh yeah, no security implications here, let's just proceed." :)

[msporny]

I suggest to define the authorization header in another draft.

The mechanism is nearly identical, and IETF (in general) frowns upon having two RFCs that basically say the same thing and only differ in the HTTP header they apply to. :)

[ioggstream]

IETF frowns upon having two [identical] RFCs

I understand. I see though that with signature and authentication we have two big challenges that may be complex to address in the same document.

how does this compose w/ Bearer tokens, how does it compose with the SXG stuff, how does it compose w/ other signatures by other parties.

We could say that composition is NOT RECOMMENDED :)

There are compos-ability problems here that can be addressed w/ simple language in the specification

I agree, especially about avoiding managing some corner cases.

[msporny]

I understand. I see though that with signature and authentication we have two big challenges that may be complex to address in the same document.

The challenges would be more complex to address in different documents.

We could say that composition is NOT RECOMMENDED :)

We could, but people would do it anyway. :)

Besides, technologies that fail to compose well typically point to design flaws in the technology.

We need to clearly state when it is safe to do so (and there are a few good reasons you'd want to), and when it's not safe to do.