> On Jan 30, 2017, at 7:33 PM, Rob Austein <[email protected]> wrote: > > At Tue, 17 Jan 2017 07:46:06 -0800, Alissa Cooper wrote: > ... >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> What is the upgrade path for the future when new versions of this >> protocol get published? How are clients and servers meant to agree on >> which version to use? > > The schema includes a version number, so a new protocol version would > be detectable; in the most straightforward implementation, attempting > to parse an unknown protocol version would result in a schema > validation error.
I think it would be useful to note that expectation (also since the document talks about existing older versions of the protocol, presumably not standardized). Thanks, Alissa > I don't think it's really possible to specify the > upgrade path in detail until one knows what the newer version looks > like, ie, what changed, so I'd defer this until the (hypothetical) new > version. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Although I understand why Section 6 says transport security is not >> strictly required, given that the authentication and authorization >> mechanisms that this protocol relies on are outside of the scope here, >> isn't it possible that clients and servers may be exchanging cookies or >> other headers in the course of using this protocol that would benefit >> from transport encryption? It seems like mentioning that transport >> security may still be beneficial although not required might be a good >> idea. > > Um, the authentication is CMS signatures, it's just the authorization > that's out of scope. > > I can't think of any sane reason for stuffing cookies or the like into > this protocol, but yes, it's theoretically possible. > > The protocol is currently specified in terms of plain HTTP because an > earlier version using HTTPS included a horrible authentication > hairball in which HTTPS and CMS were required to use the same BPKI > certificates for authentication, which turned out to be an > implementation nightmare. So we backed off to plain HTTP to cut free > of that mess, and we didn't think there were any privacy issues in the > real data (if there had been, we would have been using CMS encryption > too). > > That said, the world has changed, and I see at least one other discuss > asking for HTTPS, so I guess we'll be going down that path, but this > time with no required linkage between CMS and HTTPS, and with the > authentication (still) just based on CMS. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
