On 6/18/19 4:50 AM, Rob Stradling wrote:
Adam, thanks for your review, and I apologize that none of this
document's authors have been available to respond until now.
I have filed
https://github.com/google/certificate-transparency-rfcs/pull/310, which
I believe addresses all of your concerns.
Thanks! This looks good, although you'll also need to register "ct" in
the Well-Known URIs registry [1]. See [2] for the registration template,
and [3] for an example of it in use.
I'll clear my discuss as soon as a new version is available in the
internet-drafts repository.
/a
____
[1] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
[2] https://tools.ietf.org/html/rfc5785#section-5.1.1
[3] https://tools.ietf.org/html/rfc7033#section-10.1
On 13/03/2019 20:52, Alexey Melnikov wrote:
On Wed, Mar 13, 2019, at 5:26 PM, Adam Roach wrote:
On 3/13/19 8:28 AM, Eric Rescorla wrote:
On Tue, Mar 12, 2019 at 11:36 PM Adam Roach via Datatracker
<[email protected] <mailto:[email protected]>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thanks to everyone who worked on updating this protocol to
reflect experience
gathered from the initial CT protocol. I have one blocking
comment, and a small
number of editorial suggestions.
---------------------------------------------------------------------------
§5:
> Clients are configured with a base URL for a log and construct
URLs
> for requests by appending suffixes to this base URL. This
structure
> places some degree of restriction on how log operators can deploy
> these services, as noted in [RFC7320]. However, operational
> experience with version 1 of this protocol has not indicated that
> these restrictions are a problem in practice.
The synthesis of URLs by a protocol in this fashion is prohibited
by BCP 190:
Scheme definitions define the presence, format, and semantics of a
path component in URIs; all other specifications MUST NOT
constrain,
or define the structure or the semantics for any path component.
Unless the intention of this document is to update BCP 190 to
change this
normative requirement, we can't publish it in its current form.
Note that doing
so would require a change of venue, as updates to BCP 190 would
not be covered
by the current TRANS charter.
Please see BCP 190 section 3 for alternate approaches. All three
approaches
could be made to work for CT, and I would be happy to explain how
to do so if
clarification is desired.
While I agree that this is forbidden by BCP 190, this structure is
inherited from
RFC 6962, which predated 7320, so making that change seems like it's
going
to be fairly disruptive. This seems like it is falling into our
discussion the other
day about what must be changed in -bis documents.
I think the timing of this document is fortuitous, in that it can help
inform that conversation. In particular, this situation helps me
better understand why both you and Benjamin raised objections to the
high-level proposal that unchanged parts of -bis documents shouldn't
be subject to DISCUSS positions. The take-away that I plan to bring to
that conversation is that such a decision needs to be informed by (a)
scope of changes between a document and its -bis, and (b) scope of
changes required to satisfy a potential DISCUSS position.
In cases like this one, where a not-even-remotely-backwards-compatible
suite of protocol changes is being made to a protocol in a document
update whose diff [1] is basically the entire document, I don't think
the principle of ignoring existing flaws in a previous document really
applies. I get that both of those predicates are somewhat subjective
evaluations, and that drawing a line in a process document might be
difficult; but I think that any standard, however subjective, that you
would be willing to sign on to would place this document outside the
category of "bis versions that are making small, incremental changes
to existing documents."
If the remedy for the flaw were a major overhaul rather than a
relatively minor tweak, it would again shift the evaluation a bit;
however, the naïve band-aid solution of moving CT endpoints to live
under "/.well-known/ct" is a trivial change, both for this document
and for implementations (in fact, for implementations, it can
generally be accomplished with a configuration tweak rather than
writing new code). To be clear, this is a textbook example of the kind
of situation URI templates were designed for, but that would require
substantially more work than simply moving it into the .well-known
tree. Either approach would address the URI ownership issue.
I am in full agreement with this.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
