[cabfpub] Pre-Ballot 169: Revised Validation Requirements

J.C. Jones jjones at mozilla.com
Wed May 4 00:06:50 UTC 2016

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.

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



On Tue, May 3, 2016 at 4:21 PM, Tim Hollebeek <THollebeek at trustwave.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160503/d79b7e98/attachment-0003.html>

More information about the Public mailing list