Answering in reverse order:
2) Subdomains are labels to the left of a verified FQDN. Authorization domains are labels to the right. The reasons for a definition are: a. Under Section 3.2.2.4, the CA is verifying the FQDN. This verification process for some methods may rely on an Authorization Domain Name but the verification is tied to a FQDN (per 3.2.2.4). b. Most CAs reuse verification of an FQDN to issue certificates that are sub-domains of a verified FQDN. Whether this is allowed is ambiguous under 169/190. c. Wildcard domains are always sub-domains of a verified FQDN. Wildcards are called out in the definition of an Authorization Domain Name. However, verification of a Wildcard Domain Name is never addressed in the actual section. d. There could be cases where we don’t want to permit a method to issue certificates for sub-domains. Better to split the permissions out so we can discuss each method individually and provide clarity around the circumstances permitting reuse of validation information. 1) The document is presented as a ballot because I based the revisions on 190. If there are discrete sub-components someone doesn’t like, I don’t mind breaking it up into chunks. Some of the reasons for the proposal: a) As mentioned above, wildcard domains are questionable about how they are validated. b) The language is inconsistent. For example, method 1 says the CA is “confirming control”. We then switch terminology to “validation”. Following that switch, we move to “authenticate”. Do each of these words mean something different? c) The language is unclear on reuse of validation information. Splitting the info out per section so we can change it on a per-validation type basis. Right now reuse is not defined, which means it could either require a validation per issuance or permit reuse for the 825 day period. d) Under method 2, who creates the Random value? The CA specifies the value and send its via email. Seems like the CA should create it as well. e) Under method 2, the interplay in these three sentences is odd: “The Random Value SHALL be unique in each email, fax, SMS, or postal mail.” “The CA or Delegated Third Party MAY resend the email, fax, SMS, or postal mil in its entirety, including re-use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged.” “The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.” Does this mean you can resend for 30 days? Can you send it after 30 days? Why does one sentence say it must be unique but the other permit resending? Etc. From: Ryan Sleevi [mailto:[email protected]] Sent: Monday, May 15, 2017 4:55 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Jeremy Rowley <[email protected]> Subject: Re: [cabfpub] Domain validation Jeremy, I think the trend has been to try to keep revisions simple - so that we don't introduce any unintentional scope. Could you expand on the reasoning for coupling these? As we saw with Ballot 193/197, it seems like it makes it more error prone. You posed it as a ballot, so it makes it hard to comment on line items (Using word to "track changes" is not a very publicly accountable or managable process), but I'm hoping to better understand. Could you 1) Highlight what you believe are inconsistencies in the existing language? 2) Highlight why you believe there are differences between subdomains and authorized domain names? On Mon, May 15, 2017 at 4:41 PM, Jeremy Rowley via Public <[email protected] <mailto:[email protected]> > wrote: While working on implementing the methods defined by ballot 169, we noticed a lot of inconsistencies in the language and process. This made some of the methods confusing, especially on how they applied to reuse of information and verification of subdomains/wildcards. Attached is a proposal that we think clarifies the process and tightens up the language. A couple of notes: 1. The proposal doesn’t intend to substantially change any of the methods. However, this is DigiCert’s interpretation of the requirements. Given the previous language, disagreement on the interpretation is likely and will highlight the need for a clarifying ballot. 2. This method doesn’t necessarily replace 190. If longer discussion is needed (because there are lots of changes), then this could be a subsequent revision to the validation methods and include more stringent controls (like reverifying WHOIS information within 30 days and restricting sub-domain methods). For now, I tried to keep the process and reuse the same. 3. The proposal separates out sub domain reuse, reuse of documentation, and splits the longer methods into discrete steps. There are lots of redundant sections. This is intentional. The goal is to (eventually) talk about each method discretely and decide what requirements are tied to document reuse and sub-domain validation. Look forward to your comments. Jeremy _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
