On Mon, 23 Feb 2004, Brian Candler wrote:
> On Mon, Feb 23, 2004 at 10:15:50AM +0000, Brian Candler wrote:
> > > > srs0+sssss+domain.com+user@domain2.com
> > > > ^^^^^
> > > > replaces +ttt+hhh+
> > ...
> > > I am fairly agnostic about this particular argument. My main reason for
> > > not doing this so far is that it becomes possible to change the size of
> > > the timestamp and the hash independently while a separator remains between
> > > them, and this seemed like a significant forwards compatibility advantage
> > > when compared with the removal of one character from the local-part
> >
> > I think you can do that anyway. I'm suggesting it's entirely a private
> > decision at the sender how many bits of hash and how many bits of timestamp
> > to have
>
> And I forgot to add: if there is a single stamp field "sssss" the
> implementor is still free to define her own delimiter and split it into two
> fields (e.g. "aaaa:bbb"), or more than two.
>
> I'm saying that the standard does need to *require* it to be split into
> exactly two parts, nor to dictate a particular timestamp format or character
> encoding scheme.
I'm going to push the boat out and suggest an alternative perspective.
Let us assume that the SRS standard does not define the SRS format at all.
Let us assume that SRS only defines a set of conventions to say what
information can be discarded during multiple forwarding hops and a
convention for letting hosts know whether or not they are a secondary hop.
Somewhere between the specification and the implementation, an example
protocol is also defined for implementing this discarding of information
without introducing cryptographic or game-theoretical weaknesses.
Now the = which is used by SRS _is_ this alternate separator.
From this perspective, the current SRS implementation already implements
your suggestion.
I can forsee a considerable amount of standards-bashing coming up, where
we look at the possible syntaxes and decide, "Well, in fact, this whole
chunk after the SRS0 might as well be opaque, so the standard doesn't need
to dictate it at all."
Given the thoughts in this mail, I should consider modifying the
database-based solution to prepend "SRS0<sep>", since this would inform
following rewriters that in fact, the dtaabase forwarder has provided an
opaque local-part from which it can perform cryptographic checks, and the
next hop need not insert a hash.
I'm not proposing this as the one-and-only answer to your question. Hell,
perhaps I'm trolling. But I hope it's an interesting way of thinking about
SRS. I could see it becoming a strong candidate for "The Answer".
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
> On Mon, Feb 23, 2004 at 10:15:50AM +0000, Brian Candler wrote:
> > > > srs0+sssss+domain.com+user@domain2.com
> > > > ^^^^^
> > > > replaces +ttt+hhh+
> > ...
> > > I am fairly agnostic about this particular argument. My main reason for
> > > not doing this so far is that it becomes possible to change the size of
> > > the timestamp and the hash independently while a separator remains between
> > > them, and this seemed like a significant forwards compatibility advantage
> > > when compared with the removal of one character from the local-part
> >
> > I think you can do that anyway. I'm suggesting it's entirely a private
> > decision at the sender how many bits of hash and how many bits of timestamp
> > to have
>
> And I forgot to add: if there is a single stamp field "sssss" the
> implementor is still free to define her own delimiter and split it into two
> fields (e.g. "aaaa:bbb"), or more than two.
>
> I'm saying that the standard does need to *require* it to be split into
> exactly two parts, nor to dictate a particular timestamp format or character
> encoding scheme.
I'm going to push the boat out and suggest an alternative perspective.
Let us assume that the SRS standard does not define the SRS format at all.
Let us assume that SRS only defines a set of conventions to say what
information can be discarded during multiple forwarding hops and a
convention for letting hosts know whether or not they are a secondary hop.
Somewhere between the specification and the implementation, an example
protocol is also defined for implementing this discarding of information
without introducing cryptographic or game-theoretical weaknesses.
Now the = which is used by SRS _is_ this alternate separator.
From this perspective, the current SRS implementation already implements
your suggestion.
I can forsee a considerable amount of standards-bashing coming up, where
we look at the possible syntaxes and decide, "Well, in fact, this whole
chunk after the SRS0 might as well be opaque, so the standard doesn't need
to dictate it at all."
Given the thoughts in this mail, I should consider modifying the
database-based solution to prepend "SRS0<sep>", since this would inform
following rewriters that in fact, the dtaabase forwarder has provided an
opaque local-part from which it can perform cryptographic checks, and the
next hop need not insert a hash.
I'm not proposing this as the one-and-only answer to your question. Hell,
perhaps I'm trolling. But I hope it's an interesting way of thinking about
SRS. I could see it becoming a strong candidate for "The Answer".
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com