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
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 is
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, s
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+je
For completeness, same for EV: https://crt.sh/?cn=ev&icaid=46855
Looks like some poor soul has been experimenting with test certificates for 3
weeks now, but has yet to succeed in issuing one that isn't violating the BRs...
___
dev-security-policy maili
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 su
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 co
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 (rou
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.moz
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-t
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: pa
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
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 infr
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
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
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
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
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/#
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
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 a
20 matches
Mail list logo