Subject: [Wpack] WPACK GitHub Repo?

From: Sean Turner <[email-masked]>
Date: Wed, 25 Mar 2020 15:45:45 -0400

hi WPACK,

The chairs have had some success with using GitHub repos for WGs, but whether we set one up is a WG decision. So, if there are objections to use establishing a WG repo please let us know 2359 UTC 27 March 2020 and please state why.

Thanks,
Dave and Sean

---

From: Larry Masinter <[email-masked]>
Date: Wed, 25 Mar 2020 13:47:54 -0700

I think relying on GitHub Issues and responses might work out fine for a
close knit group that is solving a narrow problem.

It's appropriate for a design team or a repo shared by a few document
editors to coordinate their work.

It's difficult to get a sense of working group status and topics of interest
and controversy by trying to delve into GitHub activities.

The main reason that there's a BOF at an IETF meeting and forming a working
group in the IETF (rather than through WHATWG) is to get broader review from
people who aren't following the work day to day.

Personally, I'd like to see the working group take on as part of its charter
the possible replacement of MIME multipart (mutlipart/related for MHTL,
multipart/form-data) and also for PDF (a package of content independently
assembled by a sender and signable as a package). 

> -----Original Message-----
> From: Wpack <[email-masked]> On Behalf Of Sean Turner
> Sent: Wednesday, March 25, 2020 12:46 PM
> To: WPACK List <[email-masked]>
> Subject: [Wpack] WPACK GitHub Repo?
> 
> hi WPACK,
> 
> The chairs have had some success with using GitHub repos for WGs, but
> whether we set one up is a WG decision. So, if there are objections to use
> establishing a WG repo please let us know 2359 UTC 27 March 2020 and
> please state why.
> 
> Thanks,
> Dave and Sean
> _______________________________________________
> Wpack mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpack

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Mar 2020 19:53:39 -0700

As this seems to be controversial, i want to voice support for using
Github. It's a much better system than what we had before.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 25 Mar 2020 23:51:23 -0700

I’m sorry. I’m fine with using GitHub, I was grousing about something else -- the difficulty in searching in GitHub comments and responses to find out what things were the focus of the work of the working group.

I’m on the mailing list, but it’s clearly some other forum in which the discussion about the different kinds of signing and trust and identity are being discussed.

Or not.  I want to learn enough of the language you use in these discussions so I can explain and be understood. 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?

Anyway, this is the kind of question / discussion I’d try to do in the hallway at a F2F IETF. I don’t see the mailing list, a github issue, or a group videoconference call. But if you want to chat, let me know.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Mar 2020 09:27:02 -0400

hi Larry -

I find for a wg I am heavily invested in, its often handy to subscribe to
all notifications of a github repo (and then mail filter). This creates the
sort of serialized back and forth that conveys the tone and areas of
emphasis of a very good email discussion. Its even better though because
everything is properly threaded :)

I recognize that this is mostly helpful looking forward. ymmv
-P

On Thu, Mar 26, 2020 at 2:51 AM Larry Masinter <[email-masked]> wrote:

> I’m sorry. I’m fine with using GitHub, I was grousing about something else
> -- the difficulty in searching in GitHub comments and responses to find out
> what things were the focus of the work of the working group.
>
> I’m on the mailing list, but it’s clearly some other forum in which the
> discussion about the different kinds of signing and trust and identity are
> being discussed.
>
> Or not.  I want to learn enough of the language you use in these
> discussions so I can explain and be understood. 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?
>
>
>
>
>
> Anyway, this is the kind of question / discussion I’d try to do in the
> hallway at a F2F IETF. I don’t see the mailing list, a github issue, or a
> group videoconference call. But if you want to chat, let me know.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 26 Mar 2020 13:52:02 +0000

As long as its name ietf-wg-wpack, please use github.

Yes, if you’ve got an active GH group, catching up can be hard. It should be possible to catchup by reading the WG mailing list, perhaps diving into occasional issue threads; if not, that’s a failure, probably of WG leadership. What if it’s before the mailing list or WG is formed?  Well, that’s out of scope, and at least you have an archival record (via issues) of discussions.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Mar 2020 13:56:02 +0000

GitHub has worked out quite well for several other WGs I participate in.  All-in on GitHub, please.

-----Original Message-----
From: Wpack <[email-masked]> On Behalf Of Sean Turner
Sent: Wednesday, March 25, 2020 3:46 PM
To: WPACK List <[email-masked]>
Subject: [Wpack] WPACK GitHub Repo?

hi WPACK,

Thanks,
Dave and Sean

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 26 Mar 2020 11:11:01 -0700

It's my fault that much more discussion has happened on
https://github.com/WICG/webpackage/ PRs and issues, and even private
discussions, than this mailing list. Sorry about that. I don't think you've
missed anything significant since IETF 106, as I was mostly waiting for the
WG to finish spinning up. Hopefully having actual chairs will help us do
better here in the future.

https://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.html has
a lot of good advice on how to manage this. I prefer the work mode it
describes as "Issue Discussion Mode
<https://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.html#name-issue-discussion-mode>",
with the tweak that even in the "Early Design Phase", the editor gets at
least another person to review each PR, but I'm happy to use whatever the
whole group decides on.

I don't think we've discussed the question of what a signature should mean,
either on the list or as a github issue. I have opinions there that I think
match what you want, which I'll describe in a separate thread. I'm also
happy to chat directly, or I believe we can schedule targeted interim
meetings if that sounds useful.

I *suspect* that we'll come up with something that can replace at least
some multipart/* (certainly MHTML is a goal) and PDF use cases, and like
the other secondary use cases, I support small tweaks to the format to
support that, as long as it doesn't compromise the primary use cases.

Jeffrey

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Mar 2020 15:43:22 +1100

Anyone who is not following QUIC might find the amount of chatter there daunting.  But you might find the search capabilities in this tool helpful: https://quicwg.org/base-drafts/issues.html#user(mcmanus)

For instance, the above link lists everything Patrick has touched.

(It's a little slow to load, because there is a lot of data, but it is still less than a visit to some sites.)

On Fri, Mar 27, 2020, at 00:27, Patrick McManus wrote:
> hi Larry -
> 
> I find for a wg I am heavily invested in, its often handy to subscribe 
> to all notifications of a github repo (and then mail filter). This 
> creates the sort of serialized back and forth that conveys the tone and 
> areas of emphasis of a very good email discussion. Its even better 
> though because everything is properly threaded :)
> 
> > I’m sorry. I’m fine with using GitHub, I was grousing about something else -- the difficulty in searching in GitHub comments and responses to find out what things were the focus of the work of the working group.____
> 
> > I’m on the mailing list, but it’s clearly some other forum in which the discussion about the different kinds of signing and trust and identity are being discussed.____
> 
> > Or not. I want to learn enough of the language you use in these discussions so I can explain and be understood. 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?____
> 
> > __ __
> 
> > __ __
> 
> > Anyway, this is the kind of question / discussion I’d try to do in the hallway at a F2F IETF. I don’t see the mailing list, a github issue, or a group videoconference call. But if you want to chat, let me know.____
>

---

From: Larry Masinter <[email-masked]>
Date: Fri, 27 Mar 2020 22:24:38 -0700

https://www.ietf.org/id/draft-ietf-git-using-github-06.html#name-typical-working-group-polic

My request is that you follow those guidelines and pay attention to the cautions within about using the mailing list to encourage and gauge consensus.

As an example: 
 
I think the attempt to use the 'origin' of each component twists the security into knots unnecessarily.
If you think of a package as just a pushed cache of collection of resources from various sources, they have no decidable relationship.

If you model treats it as document -- an object which may or may not have an origin, then you have to decide what things you'll allow the document  to do, without necessarily knowing the origin of anything.  You could make it a self-updatable document but not a component at a time; updates must be coordinated.

It seems the discussion of double hashing assumes a pushed-cache model. Why not use the hash as a kind of global etag?
(but how is the content-type reflected in the hash?

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 30 Mar 2020 14:15:42 +1100

Hi Larry,

Thanks for your insights.

On Sat, Mar 28, 2020, at 16:24, Larry Masinter wrote:
> If you think of a package as just a pushed cache of collection of 
> resources from various sources, they have no decidable relationship.

This is the core of the debate here.  If we do decide that a bundle is equivalent to a cache, then we have to accept that the process by which bundles are secured is equivalent to the cache.  In my opinion, that buries a lot of important differences, or comes with limitations on use that are unacceptable in the general case.

> It seems the discussion of double hashing assumes a pushed-cache model. 
> Why not use the hash as a kind of global etag?

This is a fairly good general model (I know that hashes are often used for etags in practice; it's a good general purpose technique).

> (but how is the content-type reflected in the hash?

It is not.  It's an aspect of HTTP that continues to annoy me, frankly, that there is no clear delineation between metadata about the representation, metadata about the request, and just data about the request.  

In this case, we depend on the bundle being considered adequately self-describing so that content is not accidentally (or maliciously) mis-classified.

For what it is worth, techniques from QUIC might translate well here.  QUIC packets are self-authenticating because they include a keyed integrity check that would be hard to generate by accident.  The current bundling proposal only includes a short fixed header (and a bunch of things that might lead any attempt to misrepresent a different content-type into error handling paths).