Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT)

[Rob Austein <[e-mail]>]

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.