[cabf_validation] Domain Validation Update

J.C. Jones jjones at mozilla.com
Tue Mar 15 16:21:33 MST 2016


Kirk,

The draft of Method 10 from the original post on this thread (3-11-2016) I
think is fine for the purposes of public comment; I don't recall us making
any changes last week on the call. I do still have the question regarding
the capitalized "Certificate Request", but that doesn't have to be resolved
before the Forum call.

Side note: should I figure out how to join the full Forum call?

- J.C.

On Tue, Mar 15, 2016 at 3:03 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

> We have a slot on Thursday’s regular Forum call to discuss the current
> status of this ballot.  Can someone (Peter?) create the latest update of
> the domain validation methods, and post to the Public list by tomorrow
> morning, telling people we will ask for comments and input on the Thursday
> call.
>
>
>
> We don’t have to include labels, etc. (Doug’s suggestions below) if we
> aren’t ready, but let’s allow the group to see all the rest of the agreed
> wording to date.
>
>
>
> OK?  *Who will post?*
>
>
>
> JC, do you have a draft of “Method 10” you want to circulate to the Forum
> yet, or do you want to wait for further review by this Working Group?
>
>
>
> *From:* validation-bounces at cabforum.org [mailto:
> validation-bounces at cabforum.org] *On Behalf Of *Doug Beattie
> *Sent:* Friday, March 11, 2016 12:40 PM
> *To:* Peter Bowen
>
> *Cc:* validation at cabforum.org
> *Subject:* Re: [cabf_validation] Domain Validation Update
>
>
>
> Sure, try this:
>
>
>
> 1.      Verify the Applicant is <the new term for Registrant, technical
> or admin contact>
>
> 2.      Send Random value via email, fax, SMS or postal mail to  <that
> same new term>
>
> 3.      Call the <same new term>
>
> 4.      Send Random Number to one of the 5 approved constructed email
> address
>
> 5.      Use a Domain Authorization Document
>
> 6.      Make agreed upon change to web site
>
> 7.      Make agreed upon change to DNS TXT or CAA record
>
> 8.      Verify IP address control
>
> 9.      Use a Test Certificate
>
> 10.   Use a Random Number in a Certificate
>
>
>
> Doug
>
>
>
> *From:* Peter Bowen [mailto:pzb at amzn.com <pzb at amzn.com>]
> *Sent:* Friday, March 11, 2016 2:48 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>
> *Cc:* Jeremy Rowley <jeremy.rowley at digicert.com>; validation at cabforum.org
> *Subject:* Re: [cabf_validation] Domain Validation Update
>
>
>
> I think putting heading on the methods is not a bad idea.  Anyone want to
> take a shot proposing a title for each?
>
>
>
> On Mar 11, 2016, at 6:19 AM, Doug Beattie <doug.beattie at globalsign.com>
> wrote:
>
>
>
> Sure, that works.  Looks like our ballot need to include a change to EVGL,
> so we should add that to the end of the current document/proposed ballot.
>
>
>
> I mentioned this before, but with the long list of complicated domain
> validation options, I think each one should be in a numbered subsection
> under 3.2.2.4, what do others think?
>
>
>
> Also, we might want to number the paragraphs in some of the longer
> options, like methods 2 and 4, so everyone can more easily reference the
> specific items.
>
>
>
> *From:* Peter Bowen [mailto:pzb at amzn.com <pzb at amzn.com>]
> *Sent:* Friday, March 11, 2016 9:14 AM
> *To:* Doug Beattie <doug.beattie at globalsign.com>
> *Cc:* Jeremy Rowley <jeremy.rowley at digicert.com>; validation at cabforum.org
> *Subject:* Re: [cabf_validation] Domain Validation Update
>
>
>
> EV currently says: "using a procedure specified in Section 3.2.2.4 of the
> Baseline Requirements, except that a CA MAY NOT verify a domain using the
> procedure described subsection 3.2.2.4(7)”.
>
>
>
> With the removal of (7) and insertion of other methods, the EV guidelines
> are going to need updating anyway.  EV can be updated to say “using at
> least one of the methods specified in BR 3.2.2.4” and then make it own
> reuse statement.  For example:
>
>
>
> 11.7.1 Verification Requirements
>
>
>
> (1) The CA SHALL confirm that, as of the date the Certificate issues,
> either the CA or a Delegated Third Party has confirmed, for each
> Fully-Qualified Domain Name (FQDN) in the Certificate, the authority of the
> Applicant to receive a Certificate containing the FQDN using at least one
> of the methods specified in the Baseline Requirements section 3.2.2.4 or
> via the method described in Appendix F.  The method in Appendix F shall
> only be used when the right most label in the FQDN is “onion”.
>
> Completed confirmations of Applicant authority may be valid for the
> issuance of multiple certificates over time.  In all cases, the
> confirmation must have been initiated no more than 13 months prior to
> certificate issuance.
>
> For purposes of domain validation, the term Applicant includes the
> Applicant’s Parent Company, Subsidiary Company, or Affiliate.
>
>
>
>
>
> On Mar 11, 2016, at 6:06 AM, Doug Beattie <doug.beattie at globalsign.com>
> wrote:
>
>
>
> EV references this same section and they are limited to reusing the data
> to 13 months and up to 27 months for reissue, so this gets a bit
> complicated if we need to call out durations in this section.
>
>
>
>
>
> *From:* validation-bounces at cabforum.org [
> mailto:validation-bounces at cabforum.org <validation-bounces at cabforum.org>] *On
> Behalf Of *Peter Bowen
> *Sent:* Friday, March 11, 2016 9:03 AM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* validation at cabforum.org
> *Subject:* Re: [cabf_validation] Domain Validation Update
>
>
>
> I suggest we change the introduction (lines A & B) to read
>
>
>
> *3.2.2.4. Authorization by Domain Name Registrant*
>
> The CA SHALL confirm that, as of the date the Certificate issues, either
> the CA or a Delegated Third Party has confirmed, for each Fully-Qualified
> Domain Name (FQDN) in the Certificate, the authority of the Applicant to
> receive a Certificate containing the FQDN using at least one of the methods
> listed below.
>
> Completed confirmations of Applicant authority may be valid for the
> issuance of multiple certificates over time.  In all cases, the
> confirmation must have been initiated no more than 39 months prior to
> certificate issuance.
>
> For purposes of domain validation, the term Applicant includes the
> Applicant’s Parent Company, Subsidiary Company, or Affiliate.
>
>
>
>
> There has been lots of discussion about the model where a CA validates
> domain authorization prior to receiving a specific certificate request.  I
> think that this revised text should assist in clarifying the situation.  It
> also make it very clear that the 39 month re-use rule applies to domain
> authorizations, rather than having to infer it based on the text in
> "Identification and Authentication for Routine Re‐key”.
>
>
>
> Thanks,
>
> Peter
>
>
>
>
>
> On Mar 10, 2016, at 9:34 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
>
>
> Here’s the updated domain validation draft based on today’s discussion
> (and a couple of attempts to clarify items of confusion).  I look forward
> to the comments.
>
> <Domain Validation Draft (3-11-2016).docx>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
>
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>
> _______________________________________________
> 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/20160315/3a2b2909/attachment-0001.html 


More information about the Validation mailing list