[cabfpub] Pre-Ballot 169: Revised Validation Requirements

[J.C. Jones]

Tim, Ryan, Richard: Thank you again for your help in solidifying this.

Taking Richard's updates then, I propose that the working group proposal be
amended before the vote begins:

Define the term "Required Website Content":

*Required Website Content*: Either a Random Value or a Request Token,
> together with additional information that uniquely identifies the
> Subscriber, as specified by the CA.
>

Change the first paragraph of section 3.2.2.4.6, "Agreed-Upon Change to
Website", to state:

Confirming the Applicant's control over the requested FQDN by confirming
> the presence of Required Website Content (contained in the content of a
> file or on a web page in the form of a meta tag) under the
> "/.well-known/pki-validation" directory, or another path registered with
> IANA for the purpose of Domain Validation, on the Authorization Domain Name
> that can be validated over an Authorized Port. The entire Required
> Website Content MUST NOT appear in the request used to retrieve the file or
> web page.


The graphical diff of this proposed amendment is here:
https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1

Cheers,
J.C.

On Wed, May 4, 2016 at 7:36 AM, Richard Barnes <rbarnes at mozilla.com> wrote:

> Fair enough.  So, JC's text without the optionality:
>
> *"Required Website Content*: Either a Random Value or a Request Token,
> together with information that uniquely identifies the Subscriber, as
> specified by the CA"
>
> On Wed, May 4, 2016 at 10:27 AM, Tim Hollebeek <THollebeek at trustwave.com>
> wrote:
>
>> Well, the point is that in addition to removing the optionality, the
>> added information must bind the RWC to the request.  I actually like JC’s
>> change as a good step in the right direction.
>>
>>
>>
>> Writing generic descriptions of validation methods tends to allow more
>> bad things than it helps.  I’d rather see a description of enough of the
>> ACME protocol to capture it’s necessary security features.  If people want
>> to add similar validation schemes in the future, they should be added as
>> new methods after being adequately reviewed, instead of trying to
>> anticipate all possible similar future methods in advance.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Richard Barnes [mailto:rbarnes at mozilla.com]
>> *Sent:* Wednesday, May 04, 2016 10:18 AM
>> *To:* J.C. Jones
>> *Cc:* Tim Hollebeek; Ryan Sleevi; CABFPub
>>
>> *Subject:* Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements
>>
>>
>>
>>
>>
>>
>>
>> On Tue, May 3, 2016 at 8:06 PM, J.C. Jones <jjones at mozilla.com> wrote:
>>
>> Tim, Ryan:
>>
>> Your points are well-made. As it sounds like we'd prefer to err being
>> more ACME-specific, I propose changing the definition of Required Website
>> Content (RWC) to:
>>
>> *Required Website Content*: Either a Random Value or a Request Token,
>> optionally concatenated with additional information +{*to uniquely
>> identify the Subscriber*}+ as specified by the CA.
>>
>>
>>
>> I would think the change needed would be in the other direction -- rather
>> than adding description, remove the optionality:
>>
>> *"Required Website Content*: A byte string specified by the CA
>> containing either a Random Value or a Request Token, as well as some
>> additional information"
>>
>>
>>
>>
>>
>> This should preclude concatenating a fixed prefix, or other such simple
>> validation schemes.
>>
>> I've also made a one-word clarification to my change from yesterday,
>> clarifying that the RWC can't be contained in its entirety anywhere in the
>> whole request, not only the path.
>>
>> Both of these changes are reflected in the diff at GitHub [1].
>>
>> 1)
>> https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1
>>
>> Cheers,
>> J.C.
>>
>>
>>
>> On Tue, May 3, 2016 at 4:21 PM, Tim Hollebeek <THollebeek at trustwave.com>
>> wrote:
>>
>> Given the goal of this ballot is to remove "any other method", and we
>> explicitly agreed at the start of this process to simply enumerate existing
>> practice (unless egregiously wrong), I'm not going to hold things up over
>> my concerns.  I'd like to see any other method go away ASAP.
>>
>>
>>
>> That said, this language allows "Tim's Zero Fuss Certificate Authority",
>> which uses Random Value + "ZFCA" as the challenge, and "Tim's Zero Fuss Web
>> Server" which simply parrots back Request + "ZFCA" for all requests for any
>> file under .well_known/pki-validation.
>>
>>
>>
>> I predict my product will be extremely popular, as issuance will always
>> succeed without any configuration or manual steps.  Once my web server
>> achieves ubiquity, it will succeed even if you accidentally use the wrong
>> domain name in your CSR!
>>
>>
>>
>> Basically, I don't see anywhere in the proposed text where there is a
>> requirement that the validation method must include the essential security
>> that account_key_thumbprint might provide.
>>
>>
>>
>> -Tim
>>
>>
>> ------------------------------
>>
>> *From:* public-bounces at cabforum.org <public-bounces at cabforum.org> on
>> behalf of Ryan Sleevi <sleevi at google.com>
>> *Sent:* Tuesday, May 3, 2016 6:07:23 PM
>> *To:* Richard Barnes
>> *Cc:* CABFPub
>> *Subject:* Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements
>>
>>
>>
>>
>>
>>
>>
>> On Tue, May 3, 2016 at 3:02 PM, Richard Barnes <rbarnes at mozilla.com>
>> wrote:
>>
>> Hey Ryan,
>>
>> I'm confused about where you're going here.
>>
>> It seems like the property that we need to remedy the flaw that Peter
>> exposed is that the server's response cannot be generated based on the
>> request from the CA.  It seems to me that the right response is just to
>> make that requirement explicitly.  As I think JC's text does, though
>> perhaps it could be made clearer.
>>
>> Do you agree with that approach, and we're just arguing about wording?
>> Or do you think the HTTP validation method needs to be even more
>> prescriptive?
>>
>>
>>
>> Well, the wording is to make the HTTP validation method more prescriptive
>> ;)
>>
>>
>>
>> To be clear: We're discussing wording. Tim proposed some more restrictive
>> changes, and J.C. raised the concern that ACME relies on the lax language.
>> The question is fundamentally trying to find out what options we have to
>> tweak wording or implementation - to try to close the gap so that everyone
>> is happy.
>>
>>
>> ------------------------------
>>
>>
>> This transmission may contain information that is privileged,
>> confidential, and/or exempt from disclosure under applicable law. If you
>> are not the intended recipient, you are hereby notified that any
>> disclosure, copying, distribution, or use of the information contained
>> herein (including any reliance thereon) is strictly prohibited. If you
>> received this transmission in error, please immediately contact the sender
>> and destroy the material in its entirety, whether in electronic or hard
>> copy format.
>>
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> This transmission may contain information that is privileged,
>> confidential, and/or exempt from disclosure under applicable law. If you
>> are not the intended recipient, you are hereby notified that any
>> disclosure, copying, distribution, or use of the information contained
>> herein (including any reliance thereon) is strictly prohibited. If you
>> received this transmission in error, please immediately contact the sender
>> and destroy the material in its entirety, whether in electronic or hard
>> copy format.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160504/b206609a/attachment-0003.html>