[cabfpub] Pre-Ballot 169: Revised Validation Requirements

Wed May 4 14:36:42 UTC 2016

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/49282743/attachment-0003.html>