Re: StartCom issuing bogus certificates

[Eric Mill via dev-security-policy]

The content on example.com isn't important. An unauthorized certificate can
still potentially be used to intercept an HTTPS connection to example.com
and cause malicious behavior that is unrelated to the "real" content of
example.com.

I'm pushing on this because it's important to understand that a misissuance
like this is bad for more than just "compliance" reasons. It's the same
principle behind moving away from unencrypted connections generally -- even
"unimportant" sites benefit from the use of HTTPS, in part because it
closes off attack vectors that are present for all connections that fail to
treat the network as untrusted.

-- Eric

On Wed, May 31, 2017 at 8:48 PM, Yuhong Bao 
wrote:

> I don't think there is anything important on example.com though
> 
> From: Eric Mill 
> Sent: Wednesday, May 31, 2017 4:34:20 PM
> To: Jeremy Rowley
> Cc: Kurt Roeckx; Yuhong Bao; mozilla-dev-security-pol...@lists.mozilla.org;
> Matthew Hardeman
> Subject: Re: StartCom issuing bogus certificates
>
> It's absolutely not harmless to use example.com to
> test certificate issuance. People visit example.com
> all the time, given its role. An unauthorized certificate for example.com<
> http://example.com> could let someone other than its owner hijack user
> connections, and maliciously redirect traffic or inject code/content, same
> as for any other online service people use. It's an actual security
> problem, not just a compliance violation.
>
> -- Eric
>
> On Wed, May 31, 2017 at 3:18 PM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org security-pol...@lists.mozilla.org>> wrote:
> Agreed - the license to use the domain granted by IANA is only for
> inclusion
> in documents (https://www.iana.org/domains/reserved). There isn't a
> license
> to use the domain for testing or any other purposes.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley ev-security-policy-bounces%2Bjeremy.rowley>=digicert.com@lists.mozilla
> .org] On Behalf Of Kurt Roeckx via dev-security-policy
> Sent: Wednesday, May 31, 2017 11:55 AM
> To: Yuhong Bao  >>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org la-dev-security-pol...@lists.mozilla.org>; Matthew Hardeman
> >
> Subject: Re: StartCom issuing bogus certificates
>
> On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via
> dev-security-policy
> wrote:
> > The point is that "misissuance" of example.com is
> harmless as they are
> reserved by IANA.
>
> But example.com is a real domain that that even has
> an https website. The
> certificate is issued by digicert, and the subject says it's to ICANN. If
> the certificate is not requested by IANA or ICANN nobody should issue a
> certificate for it.
>
>
> Kurt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org security-pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org security-pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
>
> --
> konklone.com | @konklone konklone>
>



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

Re: StartCom issuing bogus certificates

[Yuhong Bao via dev-security-policy]

I don't think there is anything important on example.com though

From: Eric Mill 
Sent: Wednesday, May 31, 2017 4:34:20 PM
To: Jeremy Rowley
Cc: Kurt Roeckx; Yuhong Bao; mozilla-dev-security-pol...@lists.mozilla.org; 
Matthew Hardeman
Subject: Re: StartCom issuing bogus certificates

It's absolutely not harmless to use example.com to test 
certificate issuance. People visit example.com all the 
time, given its role. An unauthorized certificate for 
example.com could let someone other than its owner hijack 
user connections, and maliciously redirect traffic or inject code/content, same 
as for any other online service people use. It's an actual security problem, 
not just a compliance violation.

-- Eric

On Wed, May 31, 2017 at 3:18 PM, Jeremy Rowley via dev-security-policy 
>
 wrote:
Agreed - the license to use the domain granted by IANA is only for inclusion
in documents (https://www.iana.org/domains/reserved). There isn't a license
to use the domain for testing or any other purposes.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kurt Roeckx via dev-security-policy
Sent: Wednesday, May 31, 2017 11:55 AM
To: Yuhong Bao >
Cc: 
mozilla-dev-security-pol...@lists.mozilla.org;
 Matthew Hardeman
>
Subject: Re: StartCom issuing bogus certificates

On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy
wrote:
> The point is that "misissuance" of example.com is 
> harmless as they are
reserved by IANA.

But example.com is a real domain that that even has an 
https website. The
certificate is issued by digicert, and the subject says it's to ICANN. If
the certificate is not requested by IANA or ICANN nobody should issue a
certificate for it.


Kurt

___
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




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

Re: StartCom issuing bogus certificates

[Eric Mill via dev-security-policy]

It's absolutely not harmless to use example.com to test certificate
issuance. People visit example.com all the time, given its role. An
unauthorized certificate for example.com could let someone other than its
owner hijack user connections, and maliciously redirect traffic or inject
code/content, same as for any other online service people use. It's an
actual security problem, not just a compliance violation.

-- Eric

On Wed, May 31, 2017 at 3:18 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Agreed - the license to use the domain granted by IANA is only for
> inclusion
> in documents (https://www.iana.org/domains/reserved). There isn't a
> license
> to use the domain for testing or any other purposes.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.c
> om@lists.mozilla
> .org] On Behalf Of Kurt Roeckx via dev-security-policy
> Sent: Wednesday, May 31, 2017 11:55 AM
> To: Yuhong Bao 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman
> 
> Subject: Re: StartCom issuing bogus certificates
>
> On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via
> dev-security-policy
> wrote:
> > The point is that "misissuance" of example.com is harmless as they are
> reserved by IANA.
>
> But example.com is a real domain that that even has an https website. The
> certificate is issued by digicert, and the subject says it's to ICANN. If
> the certificate is not requested by IANA or ICANN nobody should issue a
> certificate for it.
>
>
> Kurt
>
> ___
> 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
>
>


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

RE: StartCom issuing bogus certificates

[Jeremy Rowley via dev-security-policy]

Agreed - the license to use the domain granted by IANA is only for inclusion
in documents (https://www.iana.org/domains/reserved). There isn't a license
to use the domain for testing or any other purposes. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kurt Roeckx via dev-security-policy
Sent: Wednesday, May 31, 2017 11:55 AM
To: Yuhong Bao 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman

Subject: Re: StartCom issuing bogus certificates

On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy
wrote:
> The point is that "misissuance" of example.com is harmless as they are
reserved by IANA.

But example.com is a real domain that that even has an https website. The
certificate is issued by digicert, and the subject says it's to ICANN. If
the certificate is not requested by IANA or ICANN nobody should issue a
certificate for it.


Kurt

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom issuing bogus certificates

[Kurt Roeckx via dev-security-policy]

On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy 
wrote:
> The point is that "misissuance" of example.com is harmless as they are 
> reserved by IANA.

But example.com is a real domain that that even has an https
website. The certificate is issued by digicert, and the subject
says it's to ICANN. If the certificate is not requested by IANA
or ICANN nobody should issue a certificate for it.


Kurt

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

Re: StartCom issuing bogus certificates

[Vincent Lynch via dev-security-policy]

Hi Yuhong,

Yes, there may not be much harm in a mis-issued certificate for example.com
due to its purpose/use.

However, from the perspective of root programs and the CA/B Forum, it is
still mis-issuance and considered a serious problem. CAs should not be
issuing certificates without documented confirmation that the certificate
request was properly verified.

As Matthew suggested, the proper thing for a CA to do is operate their own
domain for these kinds of tests.

-Vincent

On Wed, May 31, 2017 at 1:10 PM Yuhong Bao via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The point is that "misissuance" of example.com is harmless as they are
> reserved by IANA.
> 
> From: dev-security-policy  hotmail@lists.mozilla.org> on behalf of Matthew Hardeman via
> dev-security-policy 
> Sent: Wednesday, May 31, 2017 10:08:10 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: StartCom issuing bogus certificates
>
> On Wednesday, May 31, 2017 at 12:04:51 PM UTC-5, Yuhong Bao wrote:
> > It would be better to use example.com and not test.com or anything like
> that, as that is defined by IANA as a reserved domain.
>
> No, it is necessary to respect the baseline requirements in issuing from
> "real" trusted or to-be-trusted systems.
>
> CAs have gotten in trouble / are in trouble for mis-issuances including
> example.com quite recently.
>
> If a dnsName needs to be included in your test certificate, register a
> domain owned by the CA for testing purposes.
>
> ___
> 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
>
-- 
Vincent Lynch
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom issuing bogus certificates

[Matthew Hardeman via dev-security-policy]

On Wednesday, May 31, 2017 at 12:10:36 PM UTC-5, Yuhong Bao wrote:
> The point is that "misissuance" of example.com is harmless as they are 
> reserved by IANA.

Except that having a trusted root CA in the major root programs is a privileged 
club with a lot of non-obvious rules.  One of those (roughly) being that you 
are never allowed to issue certs for things you don't have permission to issue 
a cert for.  Not even for tests.

See this certificate.  https://crt.sh/?id=24558997

Ask Symantec if the misissuance of that certificate for www.example.com was 
harmless to them.  I suspect they won't answer [at least not timely answer], 
but if they were being honest I'll be they really really regret that 
certificate's issuance.

Hint: The issuance of that "harmless" certificate is one of the reasons that 
they're on their way to being a really-close-to-not-trusted CA.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom issuing bogus certificates

[Yuhong Bao via dev-security-policy]

The point is that "misissuance" of example.com is harmless as they are reserved 
by IANA.

From: dev-security-policy 
 on 
behalf of Matthew Hardeman via dev-security-policy 

Sent: Wednesday, May 31, 2017 10:08:10 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom issuing bogus certificates

On Wednesday, May 31, 2017 at 12:04:51 PM UTC-5, Yuhong Bao wrote:
> It would be better to use example.com and not test.com or anything like that, 
> as that is defined by IANA as a reserved domain.

No, it is necessary to respect the baseline requirements in issuing from "real" 
trusted or to-be-trusted systems.

CAs have gotten in trouble / are in trouble for mis-issuances including 
example.com quite recently.

If a dnsName needs to be included in your test certificate, register a domain 
owned by the CA for testing purposes.

___
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: StartCom issuing bogus certificates

[Yuhong Bao via dev-security-policy]

It would be better to use example.com and not test.com or anything like that, 
as that is defined by IANA as a reserved domain.

From: dev-security-policy 
 on 
behalf of Inigo Barreira via dev-security-policy 

Sent: Wednesday, May 31, 2017 9:21:00 AM
To: patryk.szczyglow...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: StartCom issuing bogus certificates

Hi all,

There´s been a misunderstanding internally when requested to create some "test" 
certificates as indicated in the Microsoft root program requirements as stated 
in 4b "Test URLs for each root, or a URL of a publicly accessible server that 
Microsoft can use to verify the certificates." but of course not this way.

We will revoke them inmediately.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of patryk.szczyglowski--- via dev-security-policy
Sent: miércoles, 31 de mayo de 2017 17:45
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: StartCom issuing bogus certificates

Hello,

My first post here.

I just noticed StartCom have issued today couple obviously fake certificates:

https://crt.sh/?id=146437565
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name:
DNS:www.test.cn

https://crt.sh/?id=146484676
Subject:
commonName= iv
givenName = Jeremy
surname   = Liao
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = CN
X509v3 Subject Alternative Name:
DNS:www.test.cn

https://crt.sh/?id=146517428
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name:
DNS:www.test.cn

I am well aware these certificates will not be accepted in Firefox/NSS, but 
because of the fact their root certificate is still in NSS trust store, there 
might be some interest in the community regarding obvious policy violation.

Regards,
Patryk Szczygłowski
___
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: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Matthew Hardeman via dev-security-policy]

On Wednesday, May 31, 2017 at 11:04:53 AM UTC-5, Gervase Markham wrote:
> 
> If you have suggestions on how to improve this definition, let's keep
> brevity in mind :-)

Perhaps some reference to technologically incorrect syntax (i.e. an incorrectly 
encoded certificate) being a mis-issuance?

How far does "those containing information which was not properly validated" 
go?  Does that leave the opportunity for someone's tortured construction of the 
rule to suggest that a certificate that everyone agrees is NOT mis-issued is in 
fact technically mis-issued?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom issuing bogus certificates

[Matthew Hardeman via dev-security-policy]

Wow.

That is disheartening.  Those are issued from their newly cut intermediates 
issued descending from their G3 root, which I had assumed was the 
infrastructure that they intend to get audited for inclusion into the various 
root programs again.

It would seem an issuance like that on that infrastructure was a bad call if 
I'm correct on that part.

Or at a minimum, I really hope they had permission from whoever owns test.cn.

I actually was a long time paying customer and fan of StartCom.  It really was 
the cheapest way to pre-validate and do multiple EV issuances.  I thought their 
issuance interface was rather innovative, along with their pricing model.

(I'm aware of the controversy on the charging for revocation thing, and I see 
both sides.  Ultimately, I agree that responsible revocation is a matter that 
should not disincentivized by economic policies of an individual CA.)

Matt

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

Re: Mozilla Policy and CCADB Disclosure scope

[Matthew Hardeman via dev-security-policy]

On Wednesday, May 31, 2017 at 10:34:34 AM UTC-5, Gervase Markham wrote:

> However, that discussion suggests to me that we should do the following:
> 
> * Given CT, and the need within it to disclose TCSCs, the privacy
> argument seems to have been abandoned. So I think it's reasonable to
> also require disclosure of TCSCs themselves. This allows checking that
> they are indeed appropriately constrained. The obvious place to put them
> is the CCADB but it's possible we could consider something CT-based, as
> we don't need to track the paperwork the CCADB stores (audits, etc.).
> 

Regardless of whether policy would ultimately dictate that they must be 
disclosed in CCADB, I do think mandatory disclosure via CT mechanisms would 
encourage public participation in discovery of improperly constrained 
certificates.  It also would ultimately allow potentially affected third 
parties to monitor for  mis-issued TCSCs with constraints that would allow for 
infringement of their [the affected third parties'] properties.

> * So the options for intermediate certs would change from "(technically
> constrained) or (publicly disclosed and audited)" to "(publicly
> disclosed) and (technically constrained or fully audited)".
> 
> * In terms of my original message, this would mean adding type F) to the
> CCADB disclosure list.

That would seem to be case, if CCADB disclosure of these is still required in 
light of CT.  If you're not also tracking the additional matters that one would 
want in CCADB for roots and less stringently constrained intermediates but not 
for TCSCs, one wonders if there's really value in having them in CCADB?

> 
> * We should consider going above and beyond the BRs by tweaking the
> parameters for the section 8.7 audit of the certs below a TCSC. At the
> moment, it's "the greater of one certificate or at least three percent
> of the Certificates issued". I think it should be more like: MAX(MIN(5
> certificates, all certificates), 3% of certificates). In other words:
> 
> Issued Audited
> 0  0
> 1  1
> 
> 5  5
> 6  5
> 
> 1665
> 1676
> 
> 
> Auditing just a single certificate (currently OK up until 33 are issued)
> makes it too easy to overlook problems when volumes are small.
> 
> Comments?

I still maintain that if the TCSC is correctly construed and the validation 
library is correct, it would seem difficult for even random hot garbage wrapped 
with a correct signature by TCSC's key to surface an actual immediate risk to 
the Web PKI.  If I'm right about that, I would ask Mozilla to deviate in the 
other direction, waiving the 8.7 requirements as to Mozilla's policy for the 
certs below the TCSC.  That said, if the decision is to require compliance 
in-line with or exceeding the 8.7 requirement, I do like the direction you're 
heading.  One is too small a number to identify a pattern of behavior.

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

RE: StartCom issuing bogus certificates

[Inigo Barreira via dev-security-policy]

Hi all,

There´s been a misunderstanding internally when requested to create some "test" 
certificates as indicated in the Microsoft root program requirements as stated 
in 4b "Test URLs for each root, or a URL of a publicly accessible server that 
Microsoft can use to verify the certificates." but of course not this way.

We will revoke them inmediately.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of patryk.szczyglowski--- via dev-security-policy
Sent: miércoles, 31 de mayo de 2017 17:45
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: StartCom issuing bogus certificates

Hello,

My first post here.

I just noticed StartCom have issued today couple obviously fake certificates:

https://crt.sh/?id=146437565
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name: 
DNS:www.test.cn

https://crt.sh/?id=146484676
Subject:
commonName= iv
givenName = Jeremy
surname   = Liao
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = CN
X509v3 Subject Alternative Name: 
DNS:www.test.cn

https://crt.sh/?id=146517428
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name: 
DNS:www.test.cn

I am well aware these certificates will not be accepted in Firefox/NSS, but 
because of the fact their root certificate is still in NSS trust store, there 
might be some interest in the community regarding obvious policy violation.

Regards,
Patryk Szczygłowski
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.5 Proposal: Add definition of "mis-issuance"

[Gervase Markham via dev-security-policy]

It has been suggested we need a formal definition of what we consider
mis-issuance. The closest we have is currently a couple of sentence in
section 7.3:

"A certificate that includes domain names that have not been verified
according to section 3.2.2.4 of the Baseline Requirements is considered
to be mis-issued. A certificate that is intended to be used only as an
end entity certificate but includes a keyUsage extension with values
keyCertSign and/or cRLSign or a basicConstraints extension with the cA
field set to true is considered to be mis-issued."

This is clearly not an exhaustive list; one would also want to include
BR violations, RFC violations, and insufficient EV vetting, at least.

The downside of defining it is that CAs might try and rules-lawyer us in
a particular situation.

Here's some proposed text which provides more clarity while hopefully
avoiding rules-lawyering:

"The category of mis-issued certificates includes (but is not limited
to) those issued to someone who should not have received them, those
containing information which was not properly validated, those having
incorrect technical constraints, and those using algorithms other than
those permitted."

If you have suggestions on how to improve this definition, let's keep
brevity in mind :-)

This is: https://github.com/mozilla/pkipolicy/issues/76

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

StartCom issuing bogus certificates

[patryk.szczyglowski--- via dev-security-policy]

Hello,

My first post here.

I just noticed StartCom have issued today couple obviously fake certificates:

https://crt.sh/?id=146437565
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name: 
DNS:www.test.cn

https://crt.sh/?id=146484676
Subject:
commonName= iv
givenName = Jeremy
surname   = Liao
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = CN
X509v3 Subject Alternative Name: 
DNS:www.test.cn

https://crt.sh/?id=146517428
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name: 
DNS:www.test.cn

I am well aware these certificates will not be accepted in Firefox/NSS, but 
because of the fact their root certificate is still in NSS trust store, there 
might be some interest in the community regarding obvious policy violation.

Regards,
Patryk Szczygłowski
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Policy and CCADB Disclosure scope

[Gervase Markham via dev-security-policy]

On 19/05/17 14:47, Gervase Markham wrote:
> We need to have a discussion about the appropriate scope for:
> 
> 1) the applicability of Mozilla's root policy
> 2) required disclosure in the CCADB

I've now reviewed the previous discussion we had on this topic, here:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ

In it, Ryan writes: "This wording implies that technically constrained
sub-CAs, from a Mozilla Policy standpoint, are not required to adhere to
the Baseline Requirements."

I don't believe that's true now, if it ever was. I think the scope
statement in policy 2.4.1 section 1.1 and the BR applicability statement
in section 2.3 makes it clear that Mozilla policy applies, and Mozilla
policy expects the BRs to apply, to all certificates in publicly-trusted
hierarchies except those which are constrained to not issue/be used for
SSL or email.

However, that discussion suggests to me that we should do the following:

* Given CT, and the need within it to disclose TCSCs, the privacy
argument seems to have been abandoned. So I think it's reasonable to
also require disclosure of TCSCs themselves. This allows checking that
they are indeed appropriately constrained. The obvious place to put them
is the CCADB but it's possible we could consider something CT-based, as
we don't need to track the paperwork the CCADB stores (audits, etc.).

* So the options for intermediate certs would change from "(technically
constrained) or (publicly disclosed and audited)" to "(publicly
disclosed) and (technically constrained or fully audited)".

* In terms of my original message, this would mean adding type F) to the
CCADB disclosure list.

* We should consider going above and beyond the BRs by tweaking the
parameters for the section 8.7 audit of the certs below a TCSC. At the
moment, it's "the greater of one certificate or at least three percent
of the Certificates issued". I think it should be more like: MAX(MIN(5
certificates, all certificates), 3% of certificates). In other words:

Issued Audited
0  0
1  1

5  5
6  5

1665
1676


Auditing just a single certificate (currently OK up until 33 are issued)
makes it too easy to overlook problems when volumes are small.

Comments?

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

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

On 19/05/17 13:18, Gervase Markham wrote:
> Ryan Sleevi suggested a wording clarification/policy extension to the
> multi-factor auth requirement, from:
> 
> "enforce multi-factor authentication for all accounts capable of
> directly causing certificate issuance"
> 
> to
> 
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing validation functions"

Implemented as specced.

Gerv

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

Re: Policy 2.5 Proposal: Require all CAs to have appropriate network security

[Gervase Markham via dev-security-policy]

On 19/05/17 13:55, Gervase Markham wrote:
> "CAs whose certificates are included in Mozilla's root program MUST:
> .
> * follow industry best practice for securing their networks, for example
> by conforming to the CAB Forum Network Security Guidelines or a
> successor document;"

Implemented as specced.

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