[cabf_validation] Domain Validation Update

J.C. Jones jjones at mozilla.com
Wed Mar 30 08:55:23 MST 2016


Sounds good to me! Here's a redline for that change.

On Wed, Mar 30, 2016 at 8:48 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> Thanks – I think we should uncapitalize to match the rest of the document.
> As defining Certificate Request will impact the rest of the document, that
> should be done in a separate ballot (imo).
>
>
>
> *From:* J.C. Jones [mailto:jjones at mozilla.com]
> *Sent:* Wednesday, March 30, 2016 9:45 AM
> *To:* Jeremy Rowley
> *Cc:* Doug Beattie; validation at cabforum.org
>
> *Subject:* Re: [cabf_validation] Domain Validation Update
>
>
>
> Jeremy,
>
> My only comment on this draft regards the capitalized "Certificate
> Request" without a definition in methods 6 & 7 which could be construed to
> mean a specific PKCS#10 CSR, which has implications for ACME's order of
> operations. [1] Perhaps we could un-capitalize it to match the rest of the
> document, or provide a definition such as:
>
> > Certificate Request: The logical process of requesting a Certificate
> from a CA.
>
> Thanks!
>
>
> 1) https://cabforum.org/pipermail/validation/2016-March/000249.html
>
>
>
> On Wed, Mar 30, 2016 at 7:41 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
> Thanks Doug – any additional comments on the draft?  Are we ready to
> present it as a working group product?
>
>
>
> *From:* Doug Beattie [mailto:doug.beattie at globalsign.com]
> *Sent:* Tuesday, March 29, 2016 8:14 AM
> *To:* Jeremy Rowley; validation at cabforum.org
>
>
> *Subject:* RE: [cabf_validation] Domain Validation Update
>
>
>
> That’s fine by me.
>
>
>
> *From:* Jeremy Rowley [mailto:jeremy.rowley at digicert.com
> <jeremy.rowley at digicert.com>]
> *Sent:* Monday, March 28, 2016 6:54 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; validation at cabforum.org
> *Subject:* RE: [cabf_validation] Domain Validation Update
>
>
>
> What if we dropped “Verification by” since every single heading has it?
>
>
>
> *From:* validation-bounces at cabforum.org [
> mailto:validation-bounces at cabforum.org <validation-bounces at cabforum.org>] *On
> Behalf Of *Doug Beattie
> *Sent:* Thursday, March 24, 2016 11:05 AM
> *To:* validation at cabforum.org
> *Subject:* Re: [cabf_validation] Domain Validation Update
>
>
>
> Based on today’s call, I updated the proposed section headings for your
> consideration.
>
>
>
> Jeremy – do you want to add these to the next version of the ballot?
>
>
>
> 3.2.2.4.1   Verification by validating Applicant is a Domain Contact <not
> awesome, open to ideas>
>
> 3.2.2.4.2   Verification by Domain Contact using a random number
>
> 3.2.2.4.3   Verification by Domain Contact using phone
>
> 3.2.2.4.4   Verification by Domain Name based constructed emails
>
> 3.2.2.4.5   Verification by DAD
>
> 3.2.2.4.6   Verification by agree upon web site change
>
> 3.2.2.4.7   Verification by agreed upon DNS change
>
> 3.2.2.4.8   Verification by IP address
>
> 3.2.2.4.9   Verification by Test Certificate
>
> 3.2.2.4.10   Verification by Random Number in a certificate <not
> Certificate, not Test Certificate, but just a self-signed(?) certificate?
> I defer to the ACME experts.
>
>
>
> Doug
>
>
>
>
>
>
>
> *From:* validation-bounces at cabforum.org [
> mailto:validation-bounces at cabforum.org <validation-bounces at cabforum.org>] *On
> Behalf Of *Doug Beattie
> *Sent:* Friday, March 11, 2016 3:40 PM
> *To:* Peter Bowen <pzb at amzn.com>
> *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
>
>
>
>
> _______________________________________________
> 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/20160330/dd4d2d4c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Domain Validation Draft (3-11-2016)-JCJ.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 38148 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160330/dd4d2d4c/attachment-0001.bin 


More information about the Validation mailing list