Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

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 ( > >

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

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=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

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

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

Re: TunRootCA2 root inclusion request

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

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

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

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

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

RE: TunRootCA2 root inclusion request

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 >

Re: TunRootCA2 root inclusion request

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

2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

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

RE: TunRootCA2 root inclusion request

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

Re: TunRootCA2 root inclusion request

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

Re: DigiCert .onion certificates without Tor Service Descriptor Hash extension

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

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

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

Mozilla Security Blog re Symantec TLS Certs

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

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:

Re: TunRootCA2 root inclusion request

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

Re: TunRootCA2 root inclusion request

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

RE: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

> 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

SwissSign: Cert issued with a to long validity period

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