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

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

Re: Mozilla Policy and CCADB Disclosure scope

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:

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."

Re: StartCom issuing bogus certificates

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

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

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

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

Re: StartCom issuing bogus certificates

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

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

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

Re: Mozilla Policy and CCADB Disclosure scope

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

Re: StartCom issuing bogus certificates

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

Re: StartCom issuing bogus certificates

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

Re: StartCom issuing bogus certificates

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

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,

Re: StartCom issuing bogus certificates

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

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

RE: StartCom issuing bogus certificates

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

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

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

Re: StartCom issuing bogus certificates

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