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 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
