Ticket #711 (closed enhancement: invalid)

Opened 6 years ago

Last modified 2 years ago

TubID should be computed from root of certificate chain

Reported by: warner Owned by: warner
Priority: normal Milestone:
Component: foolscap Keywords:
Cc: warner Branch:
Author: Launchpad Bug:

Description


Change History

Changed 6 years ago by 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.

Changed 6 years ago by 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"

Changed 6 years ago by 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)

Changed 5 years ago by glyph

Uh, 13 months, wow.

How's this doing?

Changed 5 years ago by 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.

Changed 4 years ago by 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.

Changed 4 years ago by warner

ok, how about wiki:NewPB ?

Changed 4 years ago by warner

  • cc glyph removed
  • component changed from pb to foolscap
  • summary changed from [newpb] connection negotiation to TubID should be computed from root of certificate chain

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.

Changed 2 years ago by exarkun

  • status changed from new to closed
  • resolution set to invalid

Changed 2 years ago by warner

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

Note: See TracTickets for help on using tickets.