[Wpack] Interpreting package signatures

[Jeffrey Yasskin <[e-mail]>]

Larry wrote in
https://mailarchive.ietf.org/arch/msg/wpack/dL8feENuL9t-HpKj1PWCYjz0r2A/
that:

I suspect your requirements may be at the wrong level (you’re starting with
> a very operational view of the “web security model” (if there is such a
> thing) by translating TLS into digital signatures and asking who signs what
> and how can you do that with minimal changes to the browser “security
> model”.
>
> Asking what’s the origin of a data: URL is asking the wrong question. The
> problem is the notion of “origin” is tied to the HTTP transaction model.
>
> PDF signatures are package signatures, but the signature isn’t tied to the
> origin of any of the parts. Isn’t that what you want when you want to show
> something is trusted not because it was assembled from trusted parts but
> because you trust the assembler? What use case forces you to assume that
> interpretations packages have to look the same in the browser showing URLs?


In the web packaging drafts, I've tried to consistently distinguish between
the "author" of content versus the "publisher" of a package, for example in
https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-08.html#terminology.
The HTTP "origin" corresponds to a publisher, rather than an author, as you
can see when the byline of
https://www.propublica.org/article/what-happens-if-workers-cutting-up-the-nations-meat-get-sick
isn't
reflected in the URL. That is, the "origin" isn't the entity that
originally wrote the bytes, it's the entity that assembled the parts, which
I think matches what you're asking for. And in my signing proposal, indeed,
signatures come from publishers, not authors.

This means that if a client saves some unsigned content, they have the
option of signing it as themself when forwarding it to a friend. There's
not much benefit to doing that, since the client likely doesn't have a
publicly-recognized key, but it's possible.

Jeffrey