[cabfpub] Pre-Ballot 169: Revised Validation Requirements

[Richard Barnes]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160504/93fe6a98/attachment-0001.html