[cabf_validation] [cabfpub] Pre-Ballot 169: Revised Validation Requirements

[J.C. Jones]

Thanks, Jeremy.

I think we need to keep "Authorized Port" in the first clause, so I copied
wording from "Test Certificate" a little bit. I also fixed caps and changed
wording in clause 2 from "does not appear" to "MUST NOT appear".

Confirming the Applicant's control over the requested FQDN by confirming
> one of the following 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 is accessible by the CA via
> HTTP/HTTPS over an Authorized Port:*
>
> 1. The presence of Required Website Content contained in the body of the
> response. The entire Required Website Content MUST NOT appear in the
> request used to retrieve the file or web page, OR
> 2. The presence of the Request Token or Request Value contained in the
> body of the response where the Request Token or Random Value* MUST NOT*
> appear in the request.
>
> If a Random Value is used, the CA or Delegated Third Party SHALL provide a
> Random Value unique to the certificate request and SHALL not use the Random
> Value after the longer of (i) 30 days or (ii) if the Applicant submitted
> the certificate request, the timeframe permitted for reuse of validated
> information relevant to the certificate (such as in Section 3.3.1 of these
> Guidelines or Section 11.14.3 of the EV Guidelines).
>

I updated the graphical diff:
https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1

Cheers,
J.C.

On Thu, May 5, 2016 at 8:27 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> Version 2:
>
>
>
> 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
> one of the following 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 HTTP/HTTPS:
>
> 1.     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). The entire Required
> Website Content MUST NOT appear in the request used to retrieve the file or
> web page OR
>
> 2.       The presence of the Request Token or Random Value where the
> Request Token or Random value does 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.
>
>
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160505/d079818b/attachment-0001.html