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

Thu May 5 21:18:49 MST 2016

Jeremy,

The particular situation that seems to be a common occurrence is  when a web dev has also registered the domain name. So we know that the Applicant Representative (the web dev) has administrative control over the domain. Therefore the Applicant would not be the domain contact.

tyler myers | supervisor – secure certifcate services
602 420 4228
tmyers at godaddy.com<mailto:tmyers at godaddy.com>
[cid:image001.png at 01D1A711.6C8149B0]<http://www.godaddy.com/>

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Thursday, May 05, 2016 6:38 PM
To: Tyler J. Myers; validation (validation at cabforum.org)
Subject: RE: [cabf_validation] [cabfpub] Pre-Ballot 169: Revised Validation Requirements

How are you confirming control over the authorization domain? I’m also not seeing the conflict.

The applicant is the client in this scenario with the web dev the applicant representative (an authorized agent of the applicant)

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Tyler J. Myers
Sent: Thursday, May 5, 2016 5:01 PM
To: validation (validation at cabforum.org<mailto:validation at cabforum.org>) <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: Re: [cabf_validation] [cabfpub] Pre-Ballot 169: Revised Validation Requirements

Hello,

During final review of the proposed new domain validation, I did come across 1 item that I believe we need to look at. Current BR requirements allow for the domain to be validated via the Applicant being the Domain Name Registrant or has control of the FQDN by accomplishing 1 of the 7 requirements for that section.

Section 3.2.2.4.1 Section C in the proposed verbiage identifies that we are able to confirm the Applicant of the base domain name is the domain contact. What my concern is if someone like a web dev is requesting certs for their client. The web dev is often listed as the domain registrant, differing from the Applicant. Wouldn't they  be considered an Applicant Representative and not the Applicant?

The propose verbiage for section 3.2.2.4.1. ( c ) is as follows:

Validating the Applicant as a Domain Contact:
 (c) The CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name and directly confirms that the Applicant is the Domain Contact.

BR define Applicant as:     Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request.

BR define Applicant Representative as:    Applicant Representative: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: (i) who signs and submits, or approves a certificate request on behalf of the Applicant, and/or (ii) who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or (iii) who acknowledges and agrees to the Certificate Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA. Section C in the proposed verbiage identifies that we are able to confirm the Applicant of the base domain name is the domain contact.

I believe we may be able to alleviate this by using some of the old verbiage that was contained in the intro paragraph from current BR’s and option 7 of 3.2.2.4  of Authorization by Domain Name Registrant. It previously listed having control of the FQDN, I believe if we can establish the control of the FQDN by adding “and/or has control over the Authorization Domain Name.”

Proposed to modify 3.2.2.4.1 ( c )
The CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name and directly confirms that the Applicant is the Domain Contact and/or has control over the Authorization Domain Name.

tyler myers | supervisor – secure certifcate services
602 420 4228
tmyers at godaddy.com<mailto:tmyers at godaddy.com>
[cid:image001.png at 01D1A6E1.8050DAD0]<http://www.godaddy.com/>

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, May 05, 2016 8:28 AM
To: Jeremy Rowley; validation (validation at cabforum.org<mailto:validation at cabforum.org>)
Subject: Re: [cabf_validation] [cabfpub] Pre-Ballot 169: Revised Validation Requirements

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<mailto: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<mailto: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<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<mailto: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<mailto: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<mailto:public-bounces at cabforum.org> <public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>> on behalf of Ryan Sleevi <sleevi at google.com<mailto: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<mailto: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<mailto: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: https://cabforum.org/pipermail/validation/attachments/20160506/9f524b1b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 20542 bytes
Desc: image001.png
Url : https://cabforum.org/pipermail/validation/attachments/20160506/9f524b1b/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 4643 bytes
Desc: image003.png
Url : https://cabforum.org/pipermail/validation/attachments/20160506/9f524b1b/attachment-0003.png 