On 20 October 2015 at 08:46, Eran Messeri <[email protected]> wrote: > +1 for reporting it backed to the alleged origin - the problem Tom describes > is significant as the client would want to hold onto these suspicious pieces > of information until it is confident it has been reported, but has no way of > knowing if the report has been acknowledged by the 'genuine' origin. > > One option is to not prescribe when clients drop such pieces of information, > so clients are free to re-send it multiple times or even forever, until an > out-of-band signal (i.e. a client software update) is received to indicate > to the client that this information has been received and acted upon.
So reporting it back to the origin is an appropriate solution for a subset of situations. If I have an SCT+certificate I want to resolve to a STH, but can't, I can report it up to the origin via SCT Feedback. We also (or will) have guidelines for submitting it multiple times, and ensuring that it's reported on a connection that 'looks okay' (we have some notes in 7.1.1) There are (at least) two cases that aren't covered by "report it to the origin". (Maybe more, but I can only think of two right now.) - The origin doesn't implement SCT Feedback. - The data I have is an older STH, which is not tied to any specific origin. -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
