[cabfpub] Domain Validation Revision

[Doug Beattie]

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-
> bounces at cabforum.org] On Behalf Of Ryan Sleevi
> Sent: Thursday, February 12, 2015 10:09 PM
> To: Jeremy Rowley
> Cc: CABFPub (public at cabforum.org)
> Subject: Re: [cabfpub] Domain Validation Revision
> 
>
> 8 concerns me for a couple reasons, even though it's moving in the right
> direction.
> - You require HTTPS, but that seems overkill, when you only need to perform
> a TLS handshake. That is, consider a mail server configured for SMTP-S - it
> seems that would be a viable configuration

Sure, we can change this to be just TLS handshake.

> - It would seem that anyone that can get a port forwarded on a particular
> address can now get a certificate on that address. For things like STUN-TCP
> services, this seems quite bad!

We might want to align this with the final approach regarding making a change on the web server at a well-known URI and/or list a small number of approved ports.  We'll need to circle back on this later when the other updates are closer to consensus. 

> - The definition of "test certificate" is, from experience, a bit of a handwave
> that varies from CA to CA. It would be nice to put some explicit technical
> profile in place here (e.g. a critical poison extension, a requirement that EKUs
> are present but not serverAuth/clientAuth, issued from a CA independent of
> the issuing CA's 'trusted' hierarchy) that would prevent relying parties from
> believing the test certificate is "real"

Sure, we can define what we mean by a "test" certificate to cover these.

Proposed new wording for item 8):

Having the Applicant demonstrate practical control over the FQDN by the Applicant requesting and then installing a Test TLS Certificate issued by the CA on the FQDN which is accessed via a TLS handshake by the CA

New Definition in section 4:
Test TLS Certificate: A certificate which contains a poison extension, does not have serverAuth/clientAuth, is issued under a root not in browser public key stores, or similar such methods which would render a cert unusable for TLS server use.