> On Jun 30, 2016, at 15:44, Christiaan Ottow wrote:
>
> The certificates we had issuedto us as proof of concept (only for our own
> domains), were not revoked and we don't see them in the CT logs. However, we
> informed StartCom that we had only issued certificates for
> On Sep 5, 2016, at 16:25, hanyuwe...@gmail.com wrote:
>
> I thought Wosign's report is not very convincible. The bug of subdomain have
> existed for a long time and it made me feel it is a feature not a bug. It's
> not a secret among the admin of personal or small sites. I am not very
>
Here’s the crt.sh link for this certificate: https://crt.sh/?id=29884704
Can you provide more details about where this certificate came from? Did you
issue it using one of the vulnerabilities discussed in this thread?
> On Aug 26, 2016, at 01:12, 233sec Team wrote:
>
>
On Oct 13, 2016, at 12:49, Kathleen Wilson wrote:
>
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date
> after October 21, 2016. If additional back-dating is discovered (by any
> means) to circumvent this control, then Mozilla will immediately
> On Dec 8, 2016, at 12:48, Gervase Markham wrote:
>
> Require CAs to publish their CPs and CPSes under one of the following
> Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND.
I think this is reasonable. Does it make sense to add CC0 to the list as well?
This would
For reference, I’ve added crt.sh links for the replacement certificates below.
> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy
> wrote:
>
> https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016;
> notAfter March
> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy
> wrote:
>
> ==> The CA proceeded to notify the end entity of the certificate
> https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new
> certificate is issued by
> On Aug 3, 2017, at 04:47, Inigo Barreira via dev-security-policy
> wrote:
>
> For those which are not revoked are due to use different curves (P-384,
> P-521) that have been discussed in the mozilla m.d.s.p as well as the CAB
> Forum and there´s no
> On Aug 3, 2017, at 12:26, Kathleen Wilson via dev-security-policy
> wrote:
>
> All,
>
> I have conflicting opinions about this situation:
>
> On the one hand, I want to see better behavior, and am inclinded to add these
> two intermediate certs to
> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy
> wrote:
>
> Feedback will be appreciated on the following draft for the Bugzilla Bugs
> that I will be filing for the problems listed below.
I think we should ask for the CAs to
> On Aug 15, 2017, at 15:45, Ryan Sleevi via dev-security-policy
> wrote:
>
> I would note that any CA which does not or has not promptly revoked these
> within 24 hours of contact should, at a minimum, contact all root programs
> that they participate in
> On Aug 15, 2017, at 15:37, Kathleen Wilson via dev-security-policy
> wrote:
>
> ** Common Name not in SAN
> https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ
> It is not clear to me if I need to add this item to the
tificate.
> Thank you for letting us know of this issue.
>
> Regards
> Adriano Santoni
> Actalis
>
>
>
>
> Inviato dal mio dispositivo Samsung
>
>
> Messaggio originale
> Da: Jonathan Rudenberg via dev-security-policy
> <
> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy
> wrote:
>
> Feedback will be appreciated on the following draft for the Bugzilla Bugs
> that I will be filing for the problems listed below.
It would be useful to know when and
> On Aug 16, 2017, at 11:37, Amus via dev-security-policy
> wrote:
>
> What's wrong with the two Well's Fargo certs? I don't see any invalid
> characters in them.
https://crt.sh/?opt=cablint=19558707
https://crt.sh/?opt=cablint=11382596
Both have
Two intermediates issued by AC Camerfirma that are not disclosed in the CCADB
were logged today:
-
https://crt.sh/?sha256=201c0617cc3310c7f29fcbe46b57459bc6786a8ba2753018eb27c1e800168a2e=mozilladisclosure
(issued on 2017-05-25)
-
> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> QuoVadis (560)
>Siemens Issuing CA Internet Server 2016 (560)
>
> D-TRUST (224)
>D-TRUST SSL Class 3 CA 1 2009 (178)
>D-T
> On Aug 5, 2017, at 17:36, alex.gaynor--- via dev-security-policy
> wrote:
>
> Hi all,
>
> 7.1.4.2.2 of the CABF Baseline Requirements requires that common names always
> be an element from the SAN.
>
> Here are 62 certs, from a variety of CAs which
RFC 5280 section 7.2 and the associated IDNA RFC requires that
Internationalized Domain Names are normalized before encoding to punycode.
Let’s Encrypt appears to have issued at least three certificates that have at
least one dnsName without the proper Unicode normalization applied.
> On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On 10/08/2017 22:22, Jonathan Rudenberg wrote:
>> RFC 5280 section 7.2 and the associated IDNA RFC requires that
>> Internationalized Domain Names
> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy
> wrote:
>
> Can anyone point out a real world X.509 framework that gets confused by
> a redundant pathlen:0 in a CA:FALSE certificate? (Merely to assess the
> seriousness of the issue,
> On Aug 10, 2017, at 07:55, Fiedler, Arno via dev-security-policy
> wrote:
>
> Hello Jonathan,
>
> the certificate has 64 bits of entropy in the "DNqualifier" field instead of
> the serial number field.
>
> Since 2012 we used this way of adding
Baseline Requirements section 7.1 says:
> Effective September 30, 2016, CAs SHALL generate non‐sequential Certificate
> serial numbers greater than zero (0) containing at least 64 bits of output
> from a CSPRNG.
There are 1027 unexpired unrevoked certificates known to CT with a notBefore
date
Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from
containing IANA reserved IP addresses and any certificates containing them
should have been revoked by 2016-10-01.
There are seven unexpired unrevoked certificates that are known to CT and
trusted by NSS containing reserved
I’ve found 54 additional unexpired unrevoked certificates that are known to CT
and trusted by NSS containing dnsNames that are invalid. The errors include
invalid characters, internal names, and wildcards in the wrong position.
The full list is here: https://misissued.com/batch/8/
There are a
Hi Arno and Martin,
> On Aug 14, 2017, at 11:44, Arno Fiedler wrote:
>
> Dear Forum,
>
> since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at least
> 64 bits of entropy in the serial number.
>
> Since 01-12-2016 D-TRUST TLS certificates requested
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which
chains up to a Baltimore CyberTrust root, contains an invalid dnsName of
“www.intesasanpaolovita..biz” (note the two dots):
> On Jul 17, 2017, at 15:27, Nick Lamb via dev-security-policy
> wrote:
>
> On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson wrote:
>> Thank you for bringing this to our attention. We have contacted Intesa
>> Sanpaolo regarding this error and have
> On Jul 11, 2017, at 06:53, okaphone.elektronika--- via dev-security-policy
> wrote:
>
> On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
>>
>> Please note this email topic is just for releasing the news that WoSign new
>> system passed the
There are several intermediates on the dashboard
(https://crt.sh/mozilla-disclosures) that have been incorrectly disclosed and
have not been brought up on this list yet:
a) One intermediate issued by SECOM is undisclosed:
-
The Common CCADB Policy states:
> CAs must provide English versions of any Certificate Policy, Certification
> Practice Statement and Audit documents which are not originally in English,
> with version numbers matching the document they are a translation of.
The page at
RFC 5280 section 4.1.2.2 says:
> Conforming CAs MUST NOT use serialNumber values longer than 20 octets.
There are two CAs that appear to misissue certificates with serial numbers that
are longer than 20 octets on an ongoing basis:
- Certinomis
- TI Trust Technologies (chains up to a
> On Jul 28, 2017, at 09:34, Alex Gaynor via dev-security-policy
> wrote:
>
> Frankly I was surprised to see Chromium reverse course on this -- they have
> a history of aggressive leadership in their handling of CA failures, it's a
> little disappointing
> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy
> wrote:
>
> On 16/05/17 02:26, userwithuid wrote:
>> After skimming the responses and checking a few CAs, I'm starting to
>> wonder: Wouldn't it be easier to just add another mandatory
> On Aug 2, 2017, at 12:28, Jonathan Rudenberg via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> This certificate, issued on July 27 by certSIGN, has an invalid common name
> of “todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note
> On Aug 2, 2017, at 12:02, Jonathan Rudenberg via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> There are still three intermediates (one issued by Firmaprofesional and two
> issued by Swisscom) that are missing audit disclosures in the CCA
Two intermediates were issued by the Taiwan Government Root Certification
Authority two weeks ago and have not been disclosed in CCADB:
-
https://crt.sh/?sha256=a423a33493b31953226df96477627dbd056756704211001b6161fb5f8299dc3a
-
There are still three intermediates (one issued by Firmaprofesional and two
issued by Swisscom) that are missing audit disclosures in the CCADB and do not
have a pending OneCRL revocation:
-
https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b
(see
This certificate, issued on July 27 by certSIGN, has an invalid common name of
“todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading space):
https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96=cablint
The "AC FNMT Usuarios” intermediate operated by the Government of Spain,
Fábrica Nacional de Moneda y Timbre (FNMT) issues certificates that are not
BR-compliant. This was acknowledged during the FNMT root inclusion request
discussion and allowed as long as the intermediate "never issues
> On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy
> wrote:
>
> Dear Mozilla Security Policy Community,
>
> Thanks for the advice about the short serial numbers and apologies for the
> delayed response.
>
> Since 2016, all D-TRUST TLS
Baseline Requirements section 7.1.4.2.2(j) says:
> All other optional attributes, when present within the subject field, MUST
> contain information that has been verified by the CA. Optional attributes
> MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters,
> and/or any
> On Aug 9, 2017, at 17:50, Peter Bowen wrote:
>
> The point of certlint was to help identify issues. While I appreciate
> it getting broad usage, I don't think pushing for revocation of every
> certificate that trips any of the Error level checks is productive.
I agree,
> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>>
>>> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo...@gmail.com> wrote:
>>>
> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
>>
>>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy
>>> <
> On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder
> On Aug 7, 2017, at 16:57, Jakob Bohm via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On 07/08/2017 22:47, Jonathan Rudenberg wrote:
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder
>> URL that has a HTTPS
“IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL
that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is
required to have the plaintext HTTP scheme according to Baseline Requirements
section 7.1.2.2(c).
Here’s the list of certificates:
> On Aug 7, 2017, at 16:47, Jonathan Rudenberg via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL
> that has a HTTPS URI scheme. This is not valid, the OCSP respond
> On Aug 16, 2017, at 19:18, Kathleen Wilson via dev-security-policy
> wrote:
>
> Bugs filed...
Hi Kathleen,
It looks like a bug was not created for GoDaddy about these certificates with
invalid dnsNames, containing a space at the beginning of the
> On Aug 16, 2017, at 13:44, Jonathan Rudenberg via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> After looking into this more, I’ve found that the majority of certificates
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA
> On Aug 15, 2017, at 14:53, identrust--- via dev-security-policy
> wrote:
>
> On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote:
>> On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote:
>>> IdenTrust is fully
> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> I looked through the CT logs and found 15 more unexpired unrevoked
> certificates that are trusted by NSS and appear to have the same inaccurat
For those who aren’t following Bugzilla closely, here’s a quick update on where
things are with the large batch of misissuance bugs that was filed this week.
Most CAs have provided an initial response, and many have finished their
initial incident reviews and provided details.
Only two CAs
> On Aug 16, 2017, at 23:35, Aaron Wu via dev-security-policy
> wrote:
>
> Hi Jonathan,
>
> Thanks for reminding! I've sent mail to POC of AC Camerfirma and these two
> intermediate certs has been disclosed in CCADB now.
One of these intermediates is
+mdsp
> On Aug 18, 2017, at 05:56, ramirommu...@gmail.com wrote:
>
> Hi Jonathan
> You are right, we are going to look into this, taken into account that the
> same serial number should be in the real certificate.
>
> Regards
>
> El jueves, 17 de agosto de 2017,
> On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy
> wrote:
>
> https://crt.sh/?id=112929021=cablint
> is a precertificate. You can see the CT Precertificate Poison critical
> extention.
The serial number of this certificate should
> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy
> wrote:
>
> I would appreciate people's comments on the details of the current draft.
I don’t think that this proposal goes far enough.
Symantec has demonstrated that they have no
> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy
> wrote:
>
> I don't believe that disclosure of root certificates is the responsibility
> of a CA that has cross-certified a key. For instance, the CCADB interface
> talks in terms of
> On Jun 8, 2017, at 05:17, Gervase Markham via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On 08/06/17 00:42, Jonathan Rudenberg wrote:
>> Yet another batch of undisclosed intermediates has shown up in CT:
>
> Like, seriously?
Ano
> On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy
> wrote:
>
> Apparently, in at least one case, the certificate was issued directly(!) to
> localhost by Symantec.
>
> https://news.ycombinator.com/item?id=14598262
>
>
> On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy
> wrote:
>
> On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
>> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via
>> dev-security-policy wrote:
>>> If you should
> On Jun 5, 2017, at 09:29, Alex Gaynor via dev-security-policy
> wrote:
>
> Happy Monday!
>
> Another week, another set of intermediate certs that have shown up in CT
> without having been properly disclosed:
>
> On Jun 7, 2017, at 21:56, Matthew Hardeman via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote:
>
>> Yet another batch of undisclosed intermediates has shown u
> On Jun 16, 2017, at 05:00, Rob Stradling via dev-security-policy
> wrote:
>
> On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
>> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
>> intermediate certificates that
> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy
> wrote:
>
> That seems like very poor logic and justification.
>
> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
> literally years now, perhaps it's worth asking
> On Sep 14, 2017, at 04:49, Gervase Markham via dev-security-policy
> wrote:
>
> We should add the existing Certnomis cross-signs to OneCRL to revoke
> all the existing certificates. As of 10th August (now a month ago)
> StartCom said they have 5
> On Sep 8, 2017, at 12:27, Kathleen Wilson via dev-security-policy
> wrote:
>
>> I have updated the list again to note the additional responders fixed (in
>> this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly
>> less enormous I've
> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
> wrote:
>
> In all three of these cases, the "domain's zone does not have a DNSSEC
> validation chain to the ICANN root" -- I requested SOA, DNSKEY, NS,
> and CAA records types for each zone
For reference, here is the relevant bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398428
> On Sep 9, 2017, at 05:21, Jeremy Rowley via dev-security-policy
> wrote:
>
> big.basic.caatestsuite.com
>
> [JR] We only check CAA records with UDP to keep
> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy
> wrote:
>
> For a little more context, the idea is that we can speed up the CAA check for
> all customers while working with those who have DNSSEC to make sure they
> aren't killing
> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>&g
> On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy
> wrote:
>
> Hello, In reference to 3)"Certificates that appear to be intended as client
> certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for
> the Mozilla Root
> On Dec 12, 2017, at 08:36, Jakob Bohm via dev-security-policy
> wrote:
>
> A lot of people have posed suggestions for countermeasures so extreme
> they should not be taken seriously. This includes discontinuing EV,
I don’t think that removing the EV
> On Dec 11, 2017, at 14:14, Tim Hollebeek via dev-security-policy
> wrote:
>
>
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases.
On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote:
> 2. Performing a scan of current CAA records for the domain names we have
> issued for in the past 90 days, specifically looking for tags in CAA
> records with non-lowercase characters. We’ll examine such instances on a
>
Oops, I missed item 1, disregard :)
On Fri, May 18, 2018, at 13:45, Jonathan Rudenberg via dev-security-policy
wrote:
> On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote:
> > 2. Performing a scan of current CAA records for the domain names we have
> > issued
> On Jan 9, 2018, at 18:42, Peter Gutmann via dev-security-policy
> wrote:
>
> Ryan Sleevi writes:
>
>> Of course, if that doesn’t tickle your fancy, there are other ways that are
>> supported that you may not have heard about - for
> On Jan 9, 2018, at 19:31, Peter Gutmann via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> Jonathan Rudenberg <jonat...@titanous.com> writes:
>
>> For communicating with other machines, the correct thing to do is to issue a
>>
> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy
> wrote:
>
> Hi Wayne,
>
> After some time thinking about it, I struggled to articulate what the right
> rules for inclusion were.
>
> So I decided to approach this from a different
> On Jan 18, 2018, at 08:53, Ryan Sleevi wrote:
>
> If Mozilla was committed to an equitable set of criteria for both incumbents
> and newcomers, then one natural consequence of this is that all incumbents
> should be required to rotate their keys to new roots, created under
> On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy
> wrote:
>
> 2. On 19-December, significant concerns were raised about the reliability
> of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
> [3] Since then,
> On Jan 24, 2018, at 17:05, Wayne Thayer via dev-security-policy
> wrote:
>
> We could still choose to set that date in our own policy if the ballot were
> to fail. The reasoning behind that date has been discussed on the
> CA/Browser Forum lists. I
> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On 17/01/2018 16:13, Jonathan Rudenberg wrote:
>>> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy
>>> <dev-security-polic
> On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On 17/01/2018 21:14, Jonathan Rudenberg wrote:
>>> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy
>>> <dev-s
> On Jan 25, 2018, at 13:09, Wayne Thayer via dev-security-policy
> wrote:
>
> Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an
> explanation of the new method 12 is too much detail for this message, and
> it can be found in the
> On Jan 29, 2018, at 19:48, James Burton via dev-security-policy
> wrote:
>
> I was doing research on the ccadb.org site and was surprised to find that
> the site is running only in HTTP and is not using HTTPS.
There is already a bug about this:
:
>
> Hi Jonathan,
>
> I haven't got the required permission to access bug 1376996.
>
> Thank you,
>
> James
>
>
> On Tue, Jan 30, 2018 at 12:57 AM, Jonathan Rudenberg <jonat...@titanous.com>
> wrote:
>
> > On Jan 29, 2018, at 19:48, Ja
> On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy
> wrote:
>
> In the light of this, I believe it is reasonable to discuss the question
> of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
> https://crt.sh/?id=896972 ,
> On Feb 13, 2018, at 19:16, Wayne Thayer via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg <jonat...@titanous.com>
> wrote:
>
>>
>>> On Sep 19, 2017, at 11:12, Ger
A certificate issued by GlobalSign showed up in CT today with a notBefore date
of March 21, 2018 and a notAfter date of April 23, 2021, a validity period of
~1129 days (more than three years).
https://crt.sh/?id=311477948=zlint
CA/B Forum ballot 193 modified the Baseline Requirements to set a
On Wed, Apr 11, 2018, at 14:48, Matthew Hardeman via dev-security-policy wrote:
> Additionally, I think it's fair to say that I'm aghast that another CA
> (who by their inclusion in the Mozilla root program has agreed to stay
> abreast of developments on this list) has issued for the exact same
On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy wrote:
> It was injudicious of a CA to issue another certificate in this name for
> this entity after the already well documented controversy. Did they just
> not care that it would invite trouble or did they not know that
> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy
> wrote:
>
> This request has been in public discussion for more than 6 months, so I
> would like to make a decision soon. If you have comments or concerns with
> this request, please post
> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
>
>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy
>> <dev-security-policy@lists.mozilla.org> wrote:
>>
>
> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jonat...@titanous.com>
> wrote:
>
>>
>>> On Feb 27, 2018, at 16:35, Jonath
On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote:
> (Posting in a personal capacity as I am no longer employed by Trustwave)
>
> Mozilla Root Store Policy section 5.1
> (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
>
>
On Tue, Feb 26, 2019, at 10:06, Scott Rea via dev-security-policy wrote:
> G’day Folks,
>
> DarkMatter CEO (Karim Sabbagh), has provided an official response to
> Mozilla on the recent media article about the UAE that referenced
> security and intelligence matters. Per Wayne’s request to
On Fri, Feb 22, 2019, at 16:21, Wayne Thayer via dev-security-policy wrote:
> Despite the lack of
> direct evidence of misissuance by DarkMatter, this may be a time when we
> should use our discretion to act in the interest of individuals who rely on
> our root store.
It's worth noting that
Hi Scott,
On Tue, Mar 5, 2019, at 09:02, Scott Rea via dev-security-policy wrote:
>
> • DM has resolved all technical and policy issues raised in the UAE and
> DM Roots submission process on Mozilla list: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
>
> • Since the
1 - 100 of 111 matches
Mail list logo