Re: [Trans] Adam Roach's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

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
>>>> <noreply@ietf..org <mailto:[e-mail]>> 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.
>>