Comodo issued a certificate for an extension

[Showfom]

First, let me introduce myself, I'm a famous investor of ccTLD domains from China.

Recently we get an easy-remember domain www.sb, please note the extension is .sb

I ordered a Comodo Positive SSL for this domain, the common name which I submit is www.sb

Usually they will give us a certificate for www.sb and www.www.sb, but this time Comodo issues a certificate with DNS name www.sb and sb

I can't find our certificate in crt.sh but can be viewed here

https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966

Or you can simply type https://www.sb/ in your browser to view the certificate

https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png

I also tried to make an nginx conf in my server for https://sb/ you can change your /etc/hosts or just use curl commmand

curl -v -H "Host: sb" https://www.sb/

You can find 403 Forbidden in title without any SSL certificate error because I set the return status for https://sb/ to 403

Sorry for my bad English

Best Regards,
@Showfom

[Richard Wang]

First, I must make declaration that I don't know "Showfom", and I don't know if he/she is a WoSign customer.

As I said in my final statement that I wish all Mozilla trusted CA can post their issued certificate to CT log server for full trenchancy, I am sure not WoSign mis-issued certificate, maybe some CA have more serious problems..

I paste my statement again here:
WoSign believes that the Certificate Transparency is a very good solution for self-discipline that force employees to attach great importance to product quality control, and for external oversight mechanism that let the third party supervise the CA's activity.
WoSign is the first CA that volunteer to post all issued SSL Certificates to Google CT log server initiatively. Our aim is to let the worldwide users trust WoSign SSL certificates, and hope to drive the global CAs to be open and transparent publishing all issued certificates to CT log server, making worldwide users, browser vendors and related stakeholder to take an overall supervision, this will benefit the global Internet security.


@Showfom: you don't need to say " Sorry for my bad English", your English is very good! Our native language is Chinese, not English, so no need to say sorry, I NEVER say this word again.


Regards,

Richard

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Richard Wang]

First, I must make declaration that I don't know "Showfom", and I don't know if he/she is a WoSign customer.

As I said in my final statement that I wish all Mozilla trusted CA can post their issued certificate to CT log server for full transparency, I am sure not WoSign mis-issued certificate only, maybe some CA have more serious problems.

[s...@gmx.ch]

The affected cert has been logged here: https://crt.sh/?id=34242572

[mono...@gmail.com]

am I the only one who a) thinks this is slightly problematic and b) is surprised that the cert still isn't revoked?
Cheers,
mono

[Nick Lamb]

On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com wrote:
> am I the only one who a) thinks this is slightly problematic and b) is surprised that the cert still isn't revoked?

I don't know enough about the .sb ccTLD to be clear how problematic the described scenario is. I would certainly like to know more. Wikipedia tells me that .sb is operated like .uk used to be, with registrant domains appearing only as 3LDs e.g. you used to able to buy example.co.uk but not example.uk, so that having control of example.sb is itself exceptional, let alone www.sb

It is important to me - as a relying party - to know if there is a problem in Comodo's domain validation which allows people to obtain certificates for names which they do not (or perhaps, depending how .sb is run, even cannot) control. It is not terribly important to me in principle which names are affected, but in practice the extent of the risk might influence Mozilla's decision as to what if anything should be done, by them or by Comodo.

However right now it's the weekend, people who do this stuff as their day job, rather than an outside interest, may not have responded because they're busy watching televised sports or baking cakes. I will grow more concerned if there's no follow-up from anybody next week.

[Peter Bowen]

On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb <tiala...@gmail.com> wrote:
> On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com wrote:

>> am I the only one who a) thinks this is slightly problematic and b) is surprised that the cert still isn't revoked?
>

> I don't know enough about the .sb ccTLD to be clear how problematic the described scenario is. I would certainly like to know more. Wikipedia tells me that .sb is operated like .uk used to be, with registrant domains appearing only as 3LDs e.g. you used to able to buy example.co.uk but not example.uk, so that having control of example.sb is itself exceptional, let alone www.sb

According to https://nic.net.sb/, which is linked from
http://www.iana.org/domains/root/db/sb.html:

"Starting from February 12, 2016 Solomon Telekom Company Limited is
pleased to announce the extending of .sb domain space place by
allowing registrations directly at the ‘second-level’."

So it appears that the scenario is that someone (presumably the
reporter of this issue) registered www.sb., a second level domain
name, which would be in accordance with the described change.

> It is important to me - as a relying party - to know if there is a problem in Comodo's domain validation which allows people to obtain certificates for names which they do not (or perhaps, depending how .sb is run, even cannot) control. It is not terribly important to me in principle which names are affected, but in practice the extent of the risk might influence Mozilla's decision as to what if anything should be done, by them or by Comodo.
>
> However right now it's the weekend, people who do this stuff as their day job, rather than an outside interest, may not have responded because they're busy watching televised sports or baking cakes. I will grow more concerned if there's no follow-up from anybody next week.

It is unclear if this has been reported to the CA (Comodo). While
some CA operators do read this Mozilla forum, it is not an official
communication channel for any CA, as far as I know. Any request to
revoke a certificate needs to be sent to the address specified by the
CA in their CPS.

Thanks,
Peter

[Richard Wang]

I think I know the reason; this may be helpful for your investigation.

This is a code bug from CA issuing system that the engineer mis-understand the free additional domain added rule. System treat the "www" as a subdomain, most case it is, but in this case, it is top domain.
Subscriber finished the domain validation for domain "www.sb", then the issuing system using the rule "if the domain is validated, and if the cert request is for www.domain.com, then add its top domain - domain.com to the certificate automatically", then the signing system added the domain ".sb" as its top domain to the certificate. This rule is ok for more case, but for this case, it is wrong.

There is another bug that it means Comodo don't have the gTLD blocking system that according to the BR, CA can't issue the gTLD domain to subscriber.

And the excuse of "don’t know this new gTLD" is not a good reason that there are many new gTLDs come out very frequently, system can NOT issue the gTLD name for subscribers, system must block any known or unknown gTLD in the certificate. And this domain - "www.sb" is passed the domain validation, it means Comodo system know this gTLD.

This is a BR violated misissuance, I don't know if any more certificates are mis-issued since it is a bug in the code that may affect other similar order. I recommend Comodo post all issued SSL certificate to CT log server for full transparency to let worldwide user to check if any more mis-issuance happened.


Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Robin Alden
Sent: Monday, September 26, 2016 1:29 AM
To: 'Peter Bowen' <pzb...@gmail.com>; 'Nick Lamb' <tiala...@gmail.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: RE: Comodo issued a certificate for an extension

Hi All,
We did receive a direct report of the problem yesterday (24th September) from a Mozilla rep., thanks, and we undertook an investigation and remediation exercise yesterday.

The software problem which caused or allowed this certificate to be issued has been corrected.

That certificate (https://crt.sh/?id=34242572) was revoked yesterday morning.

We will issue a report tomorrow (26th September).

Regards
Robin Alden
Comodo

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

> bounces+robin=comod...@lists.mozilla.org] On Behalf Of Peter Bowen
> Sent: 25 September 2016 17:37
> To: Nick Lamb <tiala...@gmail.com>
> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Comodo issued a certificate for an extension
>
> On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb <tiala...@gmail.com> wrote:
> > On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com
> wrote:

> >> am I the only one who a) thinks this is slightly problematic and b)
> >> is
> surprised that the cert still isn't revoked?
> >

[Ryan Sleevi]

On Sunday, September 25, 2016 at 6:14:06 PM UTC-7, Richard Wang wrote:
> This rule is ok for more case, but for this case, it is wrong.

This rule is NEVER ok. Please re-read the BRs to understand why.

> There is another bug that it means Comodo don't have the gTLD blocking system that according to the BR, CA can't issue the gTLD domain to subscriber.

The BRs do not say this. Please re-read the BRs to understand why.

> This is a BR violated misissuance, I don't know if any more certificates are mis-issued since it is a bug in the code that may affect other similar order.

You are correct that this is potentially BR violating. However, the details of that remain to be determined. It would be useful if you allow the CA the opportunity to respond.

[Showfom]

The curl command is wrong, but after changed /etc/hosts or c:\Windows\System32\Drivers\etc\hosts , I can visit https://sb/ without any problem.

[Showfom]

On Sunday, September 25, 2016 at 6:24:11 AM UTC+8, Percy wrote:
> Ha! @Showfom perhaps you should try getting a widecard cert from them and consequently obtain a cert for all *.sb domains.

I tried to get cert from StartSSL, they will only issue www.sb or www.www.sb, that's good.

[Jason Milionis]

Still no response from COMODO CA, that's interesting, but why?

[Patrick Figel]

On 02/10/16 12:01, Jason Milionis wrote:
> Still no response from COMODO CA, that's interesting, but why?

They published an incident report a couple of days ago. For some reason,
it's not visible in the Google Groups archive of m.d.s.p (at least for
me). Here's an alternative link:

https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg04274.html

[Nick Lamb]

On Sunday, 2 October 2016 11:11:34 UTC+1, Patrick Figel wrote:
> https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg04274.html

Thanks, I too could not find this in Google Groups. That is a little concerning as I had assumed this was the authoritative source, since it's linked from Mozilla's own pages.

The first thing that jumps out at me from their report is that they mistake .sb for a gTLD when it is actually a ccTLD.

The second thing obviously is that they do have exactly the "rule" Richard Wang described, and they believe this was justified under the BRs old 3.2.2.4 method 7 (which isn't a method at all, it's basically a catch-all).

I examined the Comodo CPS and wasn't able to find any mention of this rule. Indeed based on the CPS I would have assumed that control over a website www.example.com would under no circumstances be sufficient to get a certificate for the name example.com from Comodo and I would be grateful if anyone can point me to where they have written that it is.

I think that's probably something that needs to go to CA/B although of course Mozilla would be well within its rights to just write to all CAs, asking if they have this or any similar "rules" that frustrate the intention of 3.2.2.4 and if so asking them to fix it by some reasonable deadline, such as EOY 2016.

[Peter Bowen]

On Sun, Oct 2, 2016 at 9:49 AM, Nick Lamb <tiala...@gmail.com> wrote:
>
> The second thing obviously is that they do have exactly the "rule" Richard Wang described, and they believe this was justified under the BRs old 3.2.2.4 method 7 (which isn't a method at all, it's basically a catch-all).
>

> I think that's probably something that needs to go to CA/B although of course Mozilla would be well within its rights to just write to all CAs, asking if they have this or any similar "rules" that frustrate the intention of 3.2.2.4 and if so asking them to fix it by some reasonable deadline, such as EOY 2016.

There is some good news. The CA/Browser Forum has already addressed
this, even prior to the current discussions. Ballot 169
(https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/)
revises 3.2.2.4 considerably. The new section 3.2.2.4.7 specifically
addresses DNS validation. Under the new rules, which should be in
effect as of 1 March 2017, validating www.<domain> will not be a valid
method of showing control of <domain>. The name is true for any valid
hostname under <domain>. The only note is that names in the form
_<something>.<domain> (that is starting with an underscore) can be
used to validate <domain>.

So this gap will close soon.

Thanks,
Peter

[Nick Lamb]

On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote:
> There is some good news. The CA/Browser Forum has already addressed
> this, even prior to the current discussions. Ballot 169
> (https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/)
> revises 3.2.2.4 considerably.

I'm aware of Ballot 169

> Under the new rules, which should be in
> effect as of 1 March 2017, validating www.<domain> will not be a valid
> method of showing control of <domain>. The name is true for any valid
> hostname under <domain>. The only note is that names in the form
> _<something>.<domain> (that is starting with an underscore) can be
> used to validate <domain>.

I wish I shared your confidence. My expectation is that if we leave this as it is, in April 2017 subscribers will still be able to get a certificate issued using this lackadaisical validation, and the issuing CA will say they feel it's not "really" disobeying the rules, that it's just a "technicality" and anyway what's the harm, it's so much more convenient for their customers this way?

Comodo's document never actually says that they're abolishing this "rule" as a result of Ballot 169. It lets you choose to draw that implication, by specifying that their current practices pre-date Ballot 169's changes, but it never says as much. Hence I think Mozilla's rep should take this to CA/B, or it should go in one of the bulk CA communications, to find out at least how widespread the crazy is and whether it's even consistent in how it works from one CA to the next.

On https://community.letsencrypt.org/ more than once users who've previously had certificates from elsewhere have expressed confusion or dismay when they realise that Let's Encrypt doesn't automatically issue them a certificate for both www.example.com and example.com after they only asked for one of the two. So this practice has apparently been widespread enough for some subscribers to assume it's "just how it works" even though it was never actually permitted by the BRs...

[Peter Bowen]

On Sun, Oct 2, 2016 at 6:23 PM, Nick Lamb <tiala...@gmail.com> wrote:
> On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote:
>

>> Under the new rules, which should be in
>> effect as of 1 March 2017, validating www.<domain> will not be a valid
>> method of showing control of <domain>. The name is true for any valid
>> hostname under <domain>. The only note is that names in the form
>> _<something>.<domain> (that is starting with an underscore) can be
>> used to validate <domain>.
>

> I wish I shared your confidence. My expectation is that if we leave this as it is, in April 2017 subscribers will still be able to get a certificate issued using this lackadaisical validation, and the issuing CA will say they feel it's not "really" disobeying the rules, that it's just a "technicality" and anyway what's the harm, it's so much more convenient for their customers this way?

I'm rather confident, but then I was one of the authors of 169 and
will be pushing hard to ensure all CAs get this right.

> On https://community.letsencrypt.org/ more than once users who've previously had certificates from elsewhere have expressed confusion or dismay when they realise that Let's Encrypt doesn't automatically issue them a certificate for both www.example.com and example.com after they only asked for one of the two. So this practice has apparently been widespread enough for some subscribers to assume it's "just how it works" even though it was never actually permitted by the BRs...

>From my experience running a CA, it does seem customers are surprised
if certs don't automatically contain both www.example.com and
example.com. However that is unrelated to how validation works -- in
this case the simple answer for the CA to validate control of
example.com which allows issuance for both names. The incorrect
method is to validate www.example.com and then issue for example.com.

Thanks,
Peter

[Eric Mill]

On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb <tiala...@gmail.com> wrote:

> On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote:

> > There is some good news. The CA/Browser Forum has already addressed
> > this, even prior to the current discussions. Ballot 169
> > (https://cabforum.org/2016/08/05/ballot-169-revised-
> validation-requirements/)

> > revises 3.2.2.4 considerably.
>
> I'm aware of Ballot 169
>

> > Under the new rules, which should be in
> > effect as of 1 March 2017, validating www.<domain> will not be a valid
> > method of showing control of <domain>. The name is true for any valid
> > hostname under <domain>. The only note is that names in the form
> > _<something>.<domain> (that is starting with an underscore) can be
> > used to validate <domain>.
>

> I wish I shared your confidence. My expectation is that if we leave this
> as it is, in April 2017 subscribers will still be able to get a certificate
> issued using this lackadaisical validation, and the issuing CA will say
> they feel it's not "really" disobeying the rules, that it's just a
> "technicality" and anyway what's the harm, it's so much more convenient for
> their customers this way?
>

> Comodo's document never actually says that they're abolishing this "rule"
> as a result of Ballot 169. It lets you choose to draw that implication, by
> specifying that their current practices pre-date Ballot 169's changes, but
> it never says as much. Hence I think Mozilla's rep should take this to
> CA/B, or it should go in one of the bulk CA communications, to find out at
> least how widespread the crazy is and whether it's even consistent in how
> it works from one CA to the next.
>

It would be nice for Comodo to make it explicit that this practice will
cease when Ballot 169 takes effect, and the lack of an explicit update
jumped out at me immediately when I read it. But the BRs post-169 seem
crystal clear on this, and I don't think CAs would be able to write off
this practice as a technicality or misinterpretation.

-- Eric

>
> On https://community.letsencrypt.org/ more than once users who've
> previously had certificates from elsewhere have expressed confusion or
> dismay when they realise that Let's Encrypt doesn't automatically issue
> them a certificate for both www.example.com and example.com after they
> only asked for one of the two. So this practice has apparently been
> widespread enough for some subscribers to assume it's "just how it works"
> even though it was never actually permitted by the BRs...

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[Man Ho (Certizen)]

Peter,

I'm confused why only the section 3.2.2.4.7 specifically addresses this
concern, and how. If only it does, would it implies that CA must use
this method of section 3.2.2.4.7 to validate a Base Domain Name, which
happened to be an Authorization Domain Name requested by the applicant ?
However, according to section 3.2.2.4, each FQDN listed in the
certificate is required to be validated using AT LEAST one of the
methods only.

Thanks,

Man

On 10/3/2016 3:53 AM, Peter Bowen wrote:
> The new section 3.2.2.4.7 specifically

> addresses DNS validation. Under the new rules, which should be in

[Peter Bowen]

You are correct, I was not clear.

3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly
defined "Authorization Domain Name", which should avoid this in the
future.

3.2.2.4.7 is actually the outlier, in that it allows _<something>
(underscore + some label) prefixed to the name being validated. It is
the one remaining place where showing control over a subdomain allows
validation of the direct parent.

The other methods mostly rely upon the registered domain name, so they
never have the subdomain problem.

Does that help?

Thanks,
Peter

[Man Ho (Certizen)]

On 10/3/2016 11:50 AM, Peter Bowen wrote:
> 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly
> defined "Authorization Domain Name", which should avoid this in the
> future.

Thank you for pointing me to those sections, but my confusion may be
starting from the definition of "Authorization Domain Name". Does it
simply mean one of the aliases of a FQDN that is specifically used to
obtain authorization for that FQDN? I think an example of "Authorization
Domain Name" could help me jump out from such abstraction of
definition/term. Thank you.

By simply reading the requirement, I feel that if I can create a CNAME
record to let "www.<example.com>" pointing to "<example.com>", and I
prove to a CA that I control the "www.<example.com>", then the CA should
be able to issue a certificate of "<example.com>" according to those
sections, correct?

[Rob Stradling]

On 02/10/16 17:49, Nick Lamb wrote:
> On Sunday, 2 October 2016 11:11:34 UTC+1, Patrick Figel wrote:
>> https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg04274.html
>
> Thanks, I too could not find this in Google Groups. That is a little concerning as I had assumed this was the authoritative source, since it's linked from Mozilla's own pages.
>
> The first thing that jumps out at me from their report is that they mistake .sb for a gTLD when it is actually a ccTLD.

Nick, thanks for pointing out that silly error in our report.

Thankfully the type of TLD has no significance as far as certificate
issuance is concerned.

<snip>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Rob Stradling]

On 03/10/16 02:23, Nick Lamb wrote:
<snip>

> Comodo's document never actually says that they're abolishing this "rule" as a result of Ballot 169. It lets you choose to draw that implication, by specifying that their current practices pre-date Ballot 169's changes, but it never says as much.

Nick,

When we are required (by CABForum and/or root program requirements) to
do <thing>, we will of course undertake to do <thing>.

There are lots of <thing>s that we are already required to do. We
haven't tended to issue a separate announcement for each <thing> just to
say that we do it!

[Nick Lamb]

On Tuesday, 4 October 2016 12:21:47 UTC+1, Rob Stradling wrote:
> When we are required (by CABForum and/or root program requirements) to
> do <thing>, we will of course undertake to do <thing>.
>
> There are lots of <thing>s that we are already required to do. We
> haven't tended to issue a separate announcement for each <thing> just to
> say that we do it!

I don't want to single out Comodo in particular, but you're the example we have. It feels to me, even during CA application processes here on m.d.s.policy as if the <thing>s are most often seen as bureaucratic red tape that gets in the way of your job, rather than, from my point of view as a relying party, as the bare minimum low bar a CA should expect to sail over in your day-to-day operations.

The CA/B BRs didn't previously explicitly say "You can treat control of www.example.com as proof of control over example.com" and they don't (after Ballot 169) now say "You can't treat control of www.example.com as proof of control over example.com". It was obvious before that you shouldn't do this, it's still obvious now, and it will remain obvious in March 2017.

Comodo's special "rule" that they've decided allows them to do this exists only in some unseen Comodo documentation. It's not in the Baseline Requirements, it's not in Comodo's Certificate Practice Statement, how should any Relying Party know about this rule? Suppose I, as a relying party see a certificate issued by Comodo for example.net - how am I supposed to guess that this really means Comodo saw only proof of control for www.example.net ?

What, outside of Comodo's own judgement, makes the Comodo rule OK, while prohibiting a rule that says if you control two-words.example you must be entitled to two.words.example as well if that exists ?

That's why I proposed Mozilla might like to write this to CA/B or in a group CA communication, because I would be astonished if WoSign and Comodo are the only CAs to have such special "rules" that defeat the purpose of the validation step, or if this is the only such "rule" in use today.

[Gervase Markham]

On 04/10/16 14:19, Nick Lamb wrote:
> That's why I proposed Mozilla might like to write this to CA/B or in
> a group CA communication, because I would be astonished if WoSign and
> Comodo are the only CAs to have such special "rules" that defeat the
> purpose of the validation step, or if this is the only such "rule" in
> use today.

The existence of such rules is due to the open-ended nature of the
pre-ballot-169 validation options. Once we get ballot 169 out from the
IPR quagmire, the opportunity to have such rules in this crucial area
will be gone.

Gerv

[Robin Alden]

Nick Lamb, on 02 October 2016 17:50, said..

> The first thing that jumps out at me from their report is that they
mistake .sb
> for a gTLD when it is actually a ccTLD.

That was a mistake in writing the report.
The point is that it is a TLD.

> The second thing obviously is that they do have exactly the "rule" Richard
> Wang described, and they believe this was justified under the BRs old
3.2.2.4
> method 7 (which isn't a method at all, it's basically a catch-all).
>

> I examined the Comodo CPS and wasn't able to find any mention of this
rule.
> Indeed based on the CPS I would have assumed that control over a website
> www.example.com would under no circumstances be sufficient to get a
> certificate for the name example.com from Comodo and I would be grateful
> if anyone can point me to where they have written that it is.
>

I can't speak to your assumptions, but I concede that it is not explicit in
the CPS.

It is now documented at
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
and in the knowledgebase article at:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte
rnative-methods-of-domain-control-validation-dcv

Regards
Robin Alden
Comodo

[Robin Alden]

Eric Mill, on 03 October 2016 03:14, said..

> On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb <tiala...@gmail.com> wrote:
> > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote:

> > > There is some good news. The CA/Browser Forum has already addressed
> > > this, even prior to the current discussions. Ballot 169

> > > (https://cabforum.org/2016/08/05/ballot-169-revised-
> > validation-requirements/)
> > > revises 3.2.2.4 considerably.
> >
> > I'm aware of Ballot 169
> >

> > > Under the new rules, which should be in
> > > effect as of 1 March 2017, validating www.<domain> will not be a valid
> > > method of showing control of <domain>. The name is true for any valid
> > > hostname under <domain>. The only note is that names in the form
> > > _<something>.<domain> (that is starting with an underscore) can be
> > > used to validate <domain>.
> >

> > I wish I shared your confidence. My expectation is that if we leave this
> > as it is, in April 2017 subscribers will still be able to get a
certificate
> > issued using this lackadaisical validation, and the issuing CA will say
> > they feel it's not "really" disobeying the rules, that it's just a
> > "technicality" and anyway what's the harm, it's so much more convenient
> for
> > their customers this way?
> >

> > Comodo's document never actually says that they're abolishing this
"rule"
> > as a result of Ballot 169. It lets you choose to draw that implication,
by
> > specifying that their current practices pre-date Ballot 169's changes,
but

> > it never says as much. Hence I think Mozilla's rep should take this to
> > CA/B, or it should go in one of the bulk CA communications, to find out
at
> > least how widespread the crazy is and whether it's even consistent in
how
> > it works from one CA to the next.
> >
>
> It would be nice for Comodo to make it explicit that this practice will
> cease when Ballot 169 takes effect, and the lack of an explicit update
> jumped out at me immediately when I read it. But the BRs post-169 seem
> crystal clear on this, and I don't think CAs would be able to write off
> this practice as a technicality or misinterpretation.
>
> -- Eric

I'm happy to state definitively that this practice will cease when Ballot
169 takes effect.

To avoid suggestions of weasel-words around the CA/B forum's struggle with
their IP policy my understanding is that at least Microsoft, and I hope
other browsers too, will incorporate the Ballot 169 wording into their
policy regardless of whether the CA/B has ratified it by then.

Comodo will have implemented some or all of the new validation methods
described in Ballot 169 before 1 March 2017.
Comodo will be withdrawing any and all validation methods which do not
conform with Ballot 169, and/or which rely on the pre-Ballot 169 3.2.2.4.7
'any-other-equivalent method' rule before 1 March 2017.

Regards
Robin Alden
Comodo

[Nick Lamb]

On Thursday, 10 November 2016 19:53:25 UTC, Robin Alden wrote:
> I can't speak to your assumptions, but I concede that it is not explicit in
> the CPS.
>
> It is now documented at
> https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
> and in the knowledgebase article at:
> https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte
> rnative-methods-of-domain-control-validation-dcv

Thanks Robin. And also for your definitive statement in the other post.

A brief comment on the API document (the PDF):

In section 3, HTTP Based DCV, an example is given and the hexadecimal values shown are the same for both the MD5 and SHA-1 hashes. Of course this would never happen in a real system, not least because the hashes are of different lengths. It would probably be clearer as an example if this was corrected (I assume the actual implementation is correct).

[Gervase Markham]

On 10/11/16 19:52, Robin Alden wrote:
> To avoid suggestions of weasel-words around the CA/B forum's struggle with
> their IP policy my understanding is that at least Microsoft, and I hope
> other browsers too, will incorporate the Ballot 169 wording into their
> policy regardless of whether the CA/B has ratified it by then.

If Microsoft are going to do this, maybe it's a moot point, but my
current feeling is that requiring CAs to implement exactly one of the
methods from ballot 169, at a time when all methods are under a greater
or smaller IPR uncertainty cloud, would put CAs who would need to make
changes at risk of an unknowing IPR infringement. So our current plan is
not to require this. However, comments on this viewpoint are welcomed.

Our preference is that CAs who are not using "any other method" don't
start using it, and CAs which are using it don't invent new "any other
method" schemes between now and when they stop using "any other method"
altogether. But this view is somewhat difficult to encode in policy.

Gerv

[Nick Lamb]

On Friday, 11 November 2016 12:55:02 UTC, Gervase Markham wrote:
> If Microsoft are going to do this, maybe it's a moot point, but my
> current feeling is that requiring CAs to implement exactly one of the
> methods from ballot 169, at a time when all methods are under a greater
> or smaller IPR uncertainty cloud, would put CAs who would need to make
> changes at risk of an unknowing IPR infringement. So our current plan is
> not to require this. However, comments on this viewpoint are welcomed.

My review (based on what I saw posted to CA/B mailing lists) suggested that there isn't active patent uncertainty at all for some Ballot 169 methods. I would welcome more information if you have some.

I saw documents citing patents which might be infringed by implementing methods
3.2.2.4.1 through 4, plus numbers 7 and 8. This leaves, seemingly unpatented

3.2.2.4.5 Domain Authorization Document
3.2.2.4.6 Agreed-Upon Change to Website
3.2.2.4.9 Test Certificate
3.2.2.4.10. TLS Using a Random Number

[Gervase Markham]

On 11/11/16 15:43, Nick Lamb wrote:
> My review (based on what I saw posted to CA/B mailing lists)
> suggested
> that there isn't active patent uncertainty at all for some Ballot 169
> methods. I would welcome more information if you have some.

Well, if previous IPR disclosures are, in fact, invalid, then we cannot
assume that they are complete.

> I saw documents citing patents which might be infringed by implementing methods
> 3.2.2.4.1 through 4, plus numbers 7 and 8. This leaves, seemingly unpatented
>
> 3.2.2.4.5 Domain Authorization Document
> 3.2.2.4.6 Agreed-Upon Change to Website
> 3.2.2.4.9 Test Certificate
> 3.2.2.4.10. TLS Using a Random Number

But even if they are complete, I believe this is incorrect - one CA
asked for method 9 to be moved from ballot 181 to ballot 182, implying
that they might perhaps have a patent that covered it.

Gerv

[Eric Mill]

Thank you for the update and for making it super clear, Robin.

-- Eric

On Thu, Nov 10, 2016 at 2:52 PM, Robin Alden <ro...@comodo.com> wrote:

> Eric Mill, on 03 October 2016 03:14, said..
> > On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb <tiala...@gmail.com> wrote:
> > > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote:

> > > > There is some good news. The CA/Browser Forum has already addressed
> > > > this, even prior to the current discussions. Ballot 169

> > > > (https://cabforum.org/2016/08/05/ballot-169-revised-
> > > validation-requirements/)
> > > > revises 3.2.2.4 considerably.
> > >
> > > I'm aware of Ballot 169
> > >

> > > > Under the new rules, which should be in
> > > > effect as of 1 March 2017, validating www.<domain> will not be a
> valid
> > > > method of showing control of <domain>. The name is true for any
> valid
> > > > hostname under <domain>. The only note is that names in the form
> > > > _<something>.<domain> (that is starting with an underscore) can be
> > > > used to validate <domain>.
> > >

> To avoid suggestions of weasel-words around the CA/B forum's struggle with
> their IP policy my understanding is that at least Microsoft, and I hope
> other browsers too, will incorporate the Ballot 169 wording into their
> policy regardless of whether the CA/B has ratified it by then.
>

> Comodo will have implemented some or all of the new validation methods
> described in Ballot 169 before 1 March 2017.
> Comodo will be withdrawing any and all validation methods which do not
> conform with Ballot 169, and/or which rely on the pre-Ballot 169 3.2.2.4.7
> 'any-other-equivalent method' rule before 1 March 2017.
>
> Regards
> Robin Alden
> Comodo
>
>