TubID should be computed from root of certificate chain

[warner]

glyph said he would look into newpb connection negotiation. There is a detailed
list of design goals in sandbox/warner/newpb-jobs.txt, near the top.
This is probably the single biggest issue to handle before newpb is ready to
release, since we need it to offer any hope of making the first release be
forwards compatible with future releases.

[jknight]

"""
 negotiation should take place with regular banana sequences: don't invent a
 new protocol that is only used at the start of the connection
"""
Seems to me that you at least want to send a version string in a non-banana format, so if you
completely change the protocol again for v3, you can, and provide an autodetecting v2/v3 client.
Ssh's introduction message is a good example of this theory:
"SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3"

[warner]

well, I'm thinking a VERSION token (same syntax as a STRING token) sent as the
first thing on the wire would do the job without requiring a separate state to
the receive state machine. (specifically the tokenizer). Given the way tokens
are encoded, this is effectively the same as what you suggest, just with a bit
of extra binary goop at the start of the string.
 ver = "Twisted Perspective Broker protocol version=%d" % vernum
 token = "%c\x8E%s" % (len(ver), ver)

[glyph]

Uh, 13 months, wow.
How's this doing?

[warner]

This one is done. The only remaining issue is how to accomodate Tyler's
suggestion that the TubID be the hash of one of the certificates along the
signing chain of the peer's cert, rather than always being that of the peer's
cert. This would allow folks to create a master certificate, keep it in a safe
(offline) place, and use shorter-lived working certs (signed by the master one)
for the actual Tub.
I don't yet know how to do this without allowing everybody with a
Verisign-signed cert to claim to be Verisign. I'm not sure how disruptive this
change will be when I finally *do* figure it out.. it may not require
wire-protocol changes at all, and might only affect people who choose to take
advantage of the new feature (i.e. old peers might not accept the new
indirectly-signed certificates). Limited disruptiveness means it's later on my
queue than issues which really need to be nailed down before we freeze the protocol.

[warner]

Just a note, I'm adding a NewPB wiki page to give a home to some introductory documentation and pointers to work-in-progress. Hopefully this entry will create a link so I can actually create the new page.

[warner]

ok, how about wiki:NewPB ?

[warner]

Foolscap's negotiation does what I want it to do now, but the TubID computation process does not yet do the chained-certificate thing. Updating the title and component of this ticket to reflect this.

[exarkun]

Foolscap issue tracker

[warner]

http://foolscap.lothar.com/trac/ticket/68 is the new Foolscap ticket for this one.