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

[Rob Stradling <[e-mail]>]

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.

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

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [e-mail]
Bradford, UK
Office: [phone]
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.