[cabf_validation] FW: Domain Validation ballot draft

Tue Mar 1 14:53:01 MST 2016

I'm having the same troubles Robin is with formatting in the Word
document. Nevertheless, it is attached. The two proposed changes (one
from last week, and the new clause), are below, surrounded in {{}}'s
to indicate additions.

First is the one from DV Ballot / IETF ACME alignment [1] last week,
clearing the path for the ACME-specified HTTP-01 challenge:

   Clause 6. Confirming the Applicant's control over the requested
   FQDN by confirming the presence of a Random Value or
   Request Token (contained in the name of the file, the content of
   a file, on a web page in the form of a meta tag, or any other format
   as determined by the CA) under "/.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 an Authorized Port.

Second is the new "Clause 10" covering the ACME TLS-SNI-01 challenge,
with acknowledgements to James Kasten at U. Michigan for draft
language:

+  {{Clause NEW. Confirming the Applicant's control over the requested
+  FQDN by confirming the presence of a Random Value within a
+  self-signed Certificate accessible by the CA via TLS over an
+  Authorized Port.}}

This is deliberately not using the Test Certificate definition, as in
TLS-SNI-01 these certificates are self-signed (and thus off-root), but
contain a Subject Alternative Name entry that is derived from a Random
Value [2]. It also does not specify "Authorization Domain Name" as the
TLS-SNI-01 protocol uses the Subject Name Indicator field as part of
the random challenge.

I believe these two adjustments will align the DV updates and the IETF
ACME efforts.

Cheers,

- J.C.

1) https://cabforum.org/pipermail/validation/2016-February/000210.html
2) https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.3

On Mon, Feb 29, 2016 at 11:00 AM, J.C. Jones <jjones at mozilla.com> wrote:
> Doug,
>
> Absolutely; thank you for the feedback. I will send one out in the
> morning, containing this general substance.
>
> Cheers!
>  - J.C.
>
>
> On Mon, Feb 29, 2016 at 10:34 AM, Doug Beattie
> <doug.beattie at globalsign.com> wrote:
>>
>> J.C.,
>>
>> I think it would be better to create a new validation option for this so we don't confuse the different options (we've been down this path before).  When using a cert from the CA we 'll need to define the Test certificate and it's validation steps differently from what you propose and I worry that adding this to the current definition (which already has an option in it) will cause confusion and/or ambiguity.  Can you create Domain Validation option 10?
>>
>>
>>> -----Original Message-----
>>> From: validation-bounces at cabforum.org [mailto:validation-
>>> bounces at cabforum.org] On Behalf Of J.C. Jones
>>> Sent: Monday, February 29, 2016 9:18 AM
>>> To: validation at cabforum.org
>>> Subject: Re: [cabf_validation] FW: Domain Validation ballot draft
>>>
>>> The TLS-SNI validation type defined in ACME [1] maps most closely to the
>>> Test Certificate concept in Clause 9. The TLS-SNI validation type works by
>>> validating the presentation of a Test Certificate, self-signed by the Applicant,
>>> which contains a Random Value provided by the CA encoded within the
>>> Subject Alternative Name.
>>>
>>> To permit the use of the TLS-SNI validation type, I would propose we keep
>>> Doug's updated definition of Test Certificate, and further amend Clause 9 to
>>> provide an either/or for the non-expired Test Certificate,
>>> either:
>>>   1) issued by the CA for the purpose of issuing a certificate with the same
>>> Public Key as in the Test Certificate, or
>>>   2) containing a Random Value
>>>
>>>  Clause 9. Confirming the Applicant's control over the requested FQDN by
>>> confirming the presence on the Authorization Domain Name which is
>>> accessible by the CA via TLS over an Authorized Port of a non-expired Test
>>> Certificate either issued by the CA for the purpose of issuing a certificate with
>>> the same Public Key as in the Test Certificate, or containing a Random Value.
>>>
>>> 1) https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.3
>>>
>>> Cheers!
>>>
>>> - J.C. Jones
>>>
>>>
>>>
>>> On Sun, Feb 28, 2016 at 9:32 AM, Doug Beattie
>>> <doug.beattie at globalsign.com> wrote:
>>> > Here are my inputs on Test Certificate:
>>> >
>>> > Item 9:
>>> > 9. Confirming the Applicant's control over the requested FQDN by
>>> confirming the presence on the Authorization Domain Name of a non-expired
>>> Test Certificate  issued by the CA and which is accessible by the CA via TLS
>>> over an Authorized Port for the purpose of issuing a certificate with the same
>>> Public Key as in the Test Certificate.
>>> >
>>> >
>>> >
>>> > Definition:
>>> > Test Certificate: A Certificate with a maximum validity period of 30 days and
>>> which i) includes a critical extension with the specified Test Certificate CABF
>>> OID, or ii) which chains to a root certificate not subject to these
>>> Requirements.
>>> >
>>> > Commentary: During the F2F meeting it was recommended we add an
>>> specified critical Extension to test certificates, which I've added a provision
>>> for.  But I'd still like the other option to be an SSL certificate issued under a
>>> non-public root (without that critical extension).
>>> >
>>> > Doug
>>> >
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: validation-bounces at cabforum.org [mailto:validation-
>>> >> bounces at cabforum.org] On Behalf Of Robin Alden
>>> >> Sent: Thursday, February 25, 2016 11:04 AM
>>> >> To: kirk_hall at trendmicro.com; validation at cabforum.org
>>> >> Subject: Re: [cabf_validation] FW: Domain Validation ballot draft
>>> >>
>>> >>
>>> >>
>>> >> > -----Original Message-----
>>> >> > From: validation-bounces at cabforum.org [mailto:validation-
>>> >> > bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
>>> >> > Sent: 25 February 2016 15:58
>>> >> > To: validation at cabforum.org
>>> >> > Subject: [cabf_validation] FW: Domain Validation ballot draft
>>> >> >
>>> >> > I have not seen a newer draft, so we can work from this draft from
>>> >> > last
>>> >> week
>>> >> >
>>> >> > -----Original Message-----
>>> >> > From: Peter Bowen [mailto:pzb at amzn.com]
>>> >> > Sent: Thursday, February 18, 2016 8:46 AM
>>> >> > To: CABFPub; Kirk Hall (RD-US)
>>> >> > Subject: Domain Validation ballot draft
>>> >> >
>>> >> > Here is the latest draft based on the revisions coming out of the
>>> >> > working group discussion yesterday.  The Word document is the
>>> >> > master; the slides are a reformatting for the discussion tomorrow.
>>> >> >
>>> >> > Thanks,
>>> >> > Peter
>>> >> >
>>> >> >
>>> >> > <table class="TM_EMAIL_NOTICE"><tr><td><pre>
>>> >> > 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.
>>> >> > </pre></td></tr></table>
>>> > _______________________________________________
>>> > 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 --------------
A non-text attachment was scrubbed...
Name: Domain Validation Draft (2-25-2016) JCJ v2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 47870 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160301/638a5241/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Domain Validation Draft (2-25-2016) JCJ v2.pdf
Type: application/pdf
Size: 317184 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160301/638a5241/attachment-0001.pdf 