On Mon, Mar 12, 2018 at 11:38 PM jacob.hoffmanandrews--- via
dev-security-policy wrote:
> On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote:
> > Given that Let's Encrypt has been operating a Staging Endpoint (
> > https://letsencrypt.org/docs/staging-environment/ ) for issuing
> wi
On Monday, March 12, 2018 at 8:27:06 PM UTC-7, Ryan Sleevi wrote:
> Also, is this the correct timestamp? For example, examining
> https://crt.sh/?id=353754255&opt=ocsp
>
> Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a
> revocation time of 2018-03-12 23:58:10 UTC , but you s
On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote:
> Given that Let's Encrypt has been operating a Staging Endpoint (
> https://letsencrypt.org/docs/staging-environment/ ) for issuing wildcards,
> what controls, if any, existed to examine the certificate profiles prior to
> being dep
On Mon, Mar 12, 2018 at 10:53 PM, taher.mestiri--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I asked about fast tracks because it's taking long time to get things
> processed related to the fact that all this is running by a community and I
> think it can be great t
On Mon, Mar 12, 2018 at 11:22 PM, Ryan Sleevi wrote:
>
>
> On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> During final tests for the general availability of wildcard certificate
>> support, the Let's Encrypt operations team
On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> During final tests for the general availability of wildcard certificate
> support, the Let's Encrypt operations team issued six test wildcard
> certificates under our publicly truste
My reaction was primarily based on the following suggestion:
"Generally speaking I would insist on the fact that for country CAs, some
kind
of fast tracks should be established because the impact of time losing at
country level is highly expensive."
The answer is, and must be, no.
-Tim
> -
Dear Tim,
Not sure your penguin-related example would make the picture sharper or ideas
clearer.
I asked about fast tracks because it's taking long time to get things processed
related to the fact that all this is running by a community and I think it can
be great to brainstorm ways to handle
During final tests for the general availability of wildcard certificate
support, the Let's Encrypt operations team issued six test wildcard
certificates under our publicly trusted root:
https://crt.sh/?id=353759994
https://crt.sh/?id=353758875
https://crt.sh/?id=353757861
https://crt.sh/?id=3537
Nobody is blocking any country from advancing. There are no Mozilla rules
that prevent any country from having the best CA on the planet. If a bunch
of penguins at McMurdo station run an awesome CA, I'll ask some hard
questions about how they meet the OCSP requirements with their limited
bandwid
Dear All,
Thank you for your detailed description of your concerns with the Tunisian CA.
I have been one of those guys that developped IT communities for more than 7
years in Tunisia, starting by Tunandroid (Tunisian Android Community), Google
Developers Groups, organized the best Software Free
Thanks, Jeremy.
I also found a certificate [1] with both 16-character.onion and
56-character.onion addresses [2] listed in the SAN. The v3 address is
not included in the 2.23.140.1.31 extension, which seems to violate
the same rule as below. However, v3 addresses include the service's
entire publi
Thanks Alex. Sorry for the delayed response. I've been traveling today.
We're reaching out to each of the customers and getting their cert replaced.
Looking into this, we did not correctly implement the ballot:
1. We didn't add a check to our backend system too verify the cert included
a descript
All,
Wayne and I have posted a Mozilla Security Blog regarding the current
plan for distrusting the Symantec TLS certs.
https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/
Kathleen
___
dev-security-policy mailing list
d
You might be interested in the following blog post:
https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practice
s/
We are continuing to look into whether there are any additional partners or
resellers that are misbehaving. This may indeed be an area where stricter
requirements a
Hi Wayne
Here my answers to the ==Meh== questions.
1 * Camerfirma has had a number of recent compliance issues as listed below:
Resolved:
* Non-BR-compliant OCSP responders:
https://bugzilla.mozilla.org/show_bug.cgi?id=14262
These responses demonstrate why the request is troubling. They attempt to
paint it as "other people do it"
The risk of removing an included CA must balance the ecosystem disruption
to those non-erroneous certs, while the risk to ecosystem inclusion needs
to balance both the aggregate harm to the e
Hi Ryan
I am so sorry but is the same error.
CN NAME NOT INCLUDE IN THE SAN
Local IP ADRESS
Policy not upto date
Is clear for me and i understand.
All this error became from approuved authority. Is the risk no.
Then The ecosystem is not protected!
ANIS
_
> 1 * The inclusion request references a much older CPS [3] that doesn't
> list the 2016 versions of these roots or comply with current policies.
> I only reviewed the newer CPS [5], but this CPS (section 1.2.1)
> doesn't cover the older roots that are currently included. I believe
> this is a comp
to whom it may concern
Last week we have reported a Bug on
https://bugzilla.mozilla.org/show_bug.cgi?id=1443731 about a certificate we
issued with a to long validity period.
We are now asked to publish the same incident report also on this
mozilla.dev.security.policy forum:
Topic 1: How your
20 matches
Mail list logo