[cabf_validation] Domain Validation Update

J.C. Jones jjones at mozilla.com
Fri Mar 11 10:14:43 MST 2016


Methods 6 and 7 both refer to "Certificate Request" (and "Certificate
request" as well, in 6) but without a corresponding definition. Other parts
of the BRs use the un-capitalized "certificate request" to refer to the
logical process of requesting a certificate[1]; capitalizing it here makes
it look like these could be explicitly PKCS#10 CSRs. (If so, that could
have implications for ACME's validation-then-CSR order of operations.)

Perhaps we can un-capitalize the noun-phrase in these two methods?

1) Sections 4.1, 5.4, 4.9.1.2, 5.5.2, 6.1.1.3, etc..

On Fri, Mar 11, 2016 at 7: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]
> *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/20160311/75346cf9/attachment.html 


More information about the Validation mailing list