Re: Comodo issued a certificate for an extension

2016-10-02 Thread 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 _
(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

On Sun, Oct 2, 2016 at 8:25 PM, Man Ho (Certizen)  wrote:
> 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
>> effect as of 1 March 2017, validating www. will not be a valid
>> method of showing control of .  The name is true for any valid
>> hostname under .  The only note is that names in the form
>> _. (that is starting with an underscore) can be
>> used to validate .
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

2016-10-02 Thread 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
> effect as of 1 March 2017, validating www. will not be a valid
> method of showing control of .  The name is true for any valid
> hostname under .  The only note is that names in the form
> _. (that is starting with an underscore) can be
> used to validate .


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

Re: Comodo issued a certificate for an extension

2016-10-02 Thread Eric Mill 
On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb  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. will not be a valid
> > method of showing control of .  The name is true for any valid
> > hostname under .  The only note is that names in the form
> > _. (that is starting with an underscore) can be
> > used to validate .
>
> 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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

2016-10-02 Thread Peter Bowen 
On Sun, Oct 2, 2016 at 6:23 PM, Nick Lamb  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. will not be a valid
>> method of showing control of .  The name is true for any valid
>> hostname under .  The only note is that names in the form
>> _. (that is starting with an underscore) can be
>> used to validate .
>
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

2016-10-02 Thread 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. will not be a valid
> method of showing control of .  The name is true for any valid
> hostname under .  The only note is that names in the form
> _. (that is starting with an underscore) can be
> used to validate .

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...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

2016-10-02 Thread Peter Bowen 
On Sun, Oct 2, 2016 at 9:49 AM, Nick Lamb  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. will not be a valid
method of showing control of .  The name is true for any valid
hostname under .  The only note is that names in the form
_. (that is starting with an underscore) can be
used to validate .

So this gap will close soon.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

2016-10-02 Thread Nick Lamb 
On Sunday, 2 October 2016 11:11:34 UTC+1, Patrick Figel  wrote:
> https://www.mail-archive.com/dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

2016-10-02 Thread 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-security-policy@lists.mozilla.org/msg04274.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

2016-10-02 Thread Percy 
On Monday, September 26, 2016 at 7:21:13 AM UTC-7, Gervase Markham wrote:
> Today, Mozilla is publishing an additional document containing further
> research into the back-dating of SHA-1 certificates, in violation of the
> CAB Forum Baseline Requirements, to avoid browser blocks. It also
> contains some conclusions we have drawn from the recent investigations,
> and a proposal for discussion regarding the action that Mozilla's root
> program should take in response.
> 
> Because this document is extensive and contains embedded images, links
> and formatting, I have published it on Google Docs instead of as an
> email message here:
> 
> https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit
> 
> However, this forum is the appropriate place for discussing it. Please
> feel free to cut and paste any parts you wish to quote and comment on.
> 
> Gerv

FYI, WoSign has stopped issuing new DV certs. 
"Sorry, due to some security consideration, 
WoSign decide to close the free SSL certificate application temporarily. Sept. 
29th 2016."
https://buy.wosign.com/free/?lan=en
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Apple's response to the WoSign incidents

2016-10-02 Thread Percy 
On Saturday, October 1, 2016 at 9:03:38 PM UTC-7, Kurt Roeckx wrote:
> On Sat, Oct 01, 2016 at 11:35:06AM -0700, Percy wrote:
> > "Apple products will trust individual existing certificates issued from 
> > this intermediate CA and published to public Certificate Transparency log 
> > servers by 2016-09-19"
> > 
> > It seems that Apple has taken the explicit white-listed approach despite 
> > the size drawback mentioned in the other thread.
> 
> >From what I get, they check that it's been logged in CT. And I'm
> not sure what that means, like doing an online check against at CT
> log, require that the SCT has been stappled or have a whitelist.
> 
> 
> Kurt

Either way, this is far better than trusting a notBefore date of the certs when 
the main problem of WoSign is the  tampering of the notBefore date when the 
cover up when explicitly questioned about it. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy