On 2021-01-19 11:02, Ramiro Muñoz wrote:
El martes, 19 de enero de 2021 a las 0:49:42 UTC+1, Matt Palmer escribió:
On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via dev-security-policy
wrote:
We don’t ask the community to disregard the data, on the contrary we ask
the community to ana
On Thu, Jan 07, 2021 at 09:31:17AM -0800, Aaron Gable wrote:
> In cases where we expect OpenSSL to be validating the chain, we expect that
> ISRG Root X1 is also in the trust store (unlike older versions of Android,
> where we know that it hasn't been added). As such, there will be two
> certificat
On 2021-01-07 01:48, Aaron Gable wrote:
As mentioned in the blog post, and as we'll elaborate on further in an
upcoming post, one of the drawbacks of this arrangement is that there
actually is a class of clients for which chaining to an expired root
doesn't work: versions of OpenSSL prior to 1.1.
On Wed, Sep 30, 2020 at 03:58:45PM +, Rob Stradling via dev-security-policy
wrote:
> Starting today, the BRs require a reasonCode in CRLs and OCSP responses for
> revoked CA certificates. Since crt.sh already monitors CRLs and keeps track
> of reasonCodes, I thought I would conduct some ana
On Thu, Aug 13, 2020 at 12:43:01PM -0700, Ronald Crane via dev-security-policy
wrote:
> I'd argue that domain registrars, CAs, and hosting services _should_ have an
> obligation to deny services to obvious phishing domains. [1] (This is
> independent of what (if any) obligations they might current
On Fri, May 22, 2020 at 10:38:34AM +0200, Hanno Böck via dev-security-policy
wrote:
> Just reported this to Chunghwa Telecom Co., Ltd.:
>
> --
>
> I'm contacting you about a problem with the certificate for
> *.hinet.net, as it can be found here [1].
>
> The Authority Information Access
On Thu, May 21, 2020 at 02:01:49PM -0700, Daniela Hood via dev-security-policy
wrote:
> Hello Sandy,
>
> GoDaddy received an email on Friday, May 7, 2020 12:06 UTC, reporting a key
> compromise, by Sandy. Once received our team started working on making sure
> that the certificate had indeed a
On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via dev-security-policy
wrote:
> On Sat, 16 May 2020 14:02:42 +0200
> Kurt Roeckx via dev-security-policy
> wrote:
>
> > https://crt.sh/?id=1902422627
> >
> > It's a certificate for api.pillowz.kz with
Hi,
Browsing crt.sh, I found this:
https://crt.sh/?id=1902422627
It's a certificate for api.pillowz.kz with the public key of Let's
Encrypt Authority X1 and X3 CAs.
It's revoked since 2020-01-31, but I couldn't find any incident
report related to it.
Kurt
_
On 2020-05-15 08:47, Peter Gutmann wrote:
Hanno Böck writes:
The impact it had was a monitoring system that checked whether the
certificate of a host was okay, using gnutls-cli with ocsp enabled (which
also uncovered a somewhat unexpected inconsistency in how the gnutls cli tool
behaves[1]).
On 2020-05-08 21:03, Wayne Thayer wrote:
It was recently reported [1] that IdenTrust experienced a multi-day OCSP
outage about two weeks ago. Other recent OCSP issues have resulted in
incident reports [3][4], so I am concerned that IdenTrust didn't report
this, and I created a bug [5] to ensure t
On 2020-04-16 14:56, Neil Dunbar wrote:
I would have thought that an OCSP-stapling implementation which got an
OCSP status code 'successful' (0) with a 'revoked' status for the
certificate would want to pass that on to the client, replacing any
prior OCSP successful/status-good report, whethe
On 2020-03-19 07:02, Matt Palmer wrote:
2. If there are not explicit prohibitions already in place, *should* there
be? If so, should it be a BR thing, or a Policy thing?
I think there should be. I expect them to publish a CRL that says the
reason for revocation is a key compromise. I exp
On Thu, Feb 06, 2020 at 09:31:40PM +, Doug Beattie via dev-security-policy
wrote:
> I don't agree that the CA MUST validate EVERY field. CAs leverage
> enterprise RAs to validate some information in SMIME certificates, e.g., the
> subscribers name in the CN field because the CA can't readily
On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy
wrote:
> It's not against Mozilla policy to
> issue certificates with unvalidated email addresses in any field as long as
> the Secure Mail EKU is not included, so the intent should be to validate
> only those that are
On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via
dev-security-policy wrote:
> Hi,
>
> I recently noticed that a lot of leaf certificates [0] have
> organizationalUnitName specified without other organizational
> information such as organizationName. Many times this field is use
On Wed, Oct 02, 2019 at 03:17:31PM -0700, Paul Walsh wrote:
> >> In separate research, CAs have shown data to demonstrate that website
> >> owners want to have their identity verified.
> >
> > They have not. In fact, I would say that most website owners are perfectly
> > happy with DV certificat
On Wed, Oct 02, 2019 at 02:48:56PM -0700, Paul Walsh wrote:
> On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy
> wrote:
> >
> > On 2019-10-02 09:20, Kurt Roeckx wrote:
> >> On 2019-10-02 02:39, Paul Walsh wrote:
> >>>
> >>> Ac
On 2019-10-02 09:20, Kurt Roeckx wrote:
On 2019-10-02 02:39, Paul Walsh wrote:
According to Ellis, the goal for a customer survey is to get feedback
from people who had recently experienced "real usage" of the product.
The key question in the survey for these people according to Ellis, is:
On 2019-10-02 02:39, Paul Walsh wrote:
According to Ellis, the goal for a customer survey is to get feedback from people who had
recently experienced "real usage" of the product. The key question in the
survey for these people according to Ellis, is:
"How would you feel if you could no longer
On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via dev-security-policy
wrote:
>
> 1. The new text added to the Mozilla Recommended and Required Practices for
> this topic states only OCSP status is required for precertificates. Many CAs
> provide both CRLs and OCSP services and it would
On 2019-09-16 14:02, Rob Stradling wrote:
ISTM that this "certificate presumed to exist" concept doesn't play
nicely with the current wording of BR 4.9.10:
'If the OCSP responder receives a request for status of a certificate
that has not been issued, then the responder SHOULD NOT respo
On 2019-09-04 14:14, Matt Palmer wrote:
If EV information is of use in anti-phishing efforts, then it would be best
for the providers of anti-phishing services to team up with CAs to describe
the advantages of continuing to provide an EV certificate. If site owners,
who are presumably smart peo
On 2019-08-30 12:14, Jakob Bohm wrote:
On 30/08/2019 01:36, Jacob Hoffman-Andrews wrote:
Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
On 2019.08.28 we read Apple’s bug report at
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP
responder returnin
On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
>
> By way of background, until recently almost all phishing and malware was on
> unencrypted http sites. They received a neutral UI, and the bad guys didn’t
> have to spend time and money getting a certificate, even
On Wed, Aug 14, 2019 at 11:52:46PM -0700, Daniel Marschall via
dev-security-policy wrote:
> In old Firefox, I get a green bar if I visit google.com and paypal.com,
> telling me that this is a well-known company that got the EV certificate.
> The other fake domains goog1e.com and paypa1.com only h
On 2019-08-13 05:27, Peter Gutmann wrote:
Wayne Thayer via dev-security-policy
writes:
Mozilla has announced that we plan to relocate the EV UI in Firefox 70, which
is expected to be released on 22-October. Details below.
Just out of interest, how are the CAs taking this? If there's no mor
On Tue, Jul 16, 2019 at 12:12:57PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> Mozilla: Overdue Audit Statements
> CA Owner: LuxTrust
> Root Certificates:
>LuxTrust Global Root 2
> Standard Audit:
> https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf
> Stan
On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via dev-security-policy
wrote:
>
> When a value in column E is 100%, this is pretty solid evidence of
> noncompliance with BR 7.1.
> When the values in column E and G are both approximately 50%, this
> suggests (but does not prove) that th
On Thu, Mar 14, 2019 at 04:09:10PM -0700, Jaime Hablutzel via
dev-security-policy wrote:
> > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we
> > utilized raw 64 bit output from CSPRING, with uniqueness and non zero
> > checks. This new understanding of the rules calls for
On Wed, Mar 13, 2019 at 05:56:55AM +0900, Hector Martin 'marcan' via
dev-security-policy wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only hav
On Sat, Feb 23, 2019 at 02:07:38PM +0400, Scott Rea via dev-security-policy
wrote:
> G’day Wayne et al,
>
> In response to your post overnight (included below), I want to assure you
> that DarkMatter’s work is solely focused on defensive cyber security, secure
> communications and digital trans
On Fri, Feb 22, 2019 at 03:45:39PM -0800, cooperq--- via dev-security-policy
wrote:
> On Friday, February 22, 2019 at 2:37:20 PM UTC-8, Jonathan Rudenberg wrote:
> > With regards to the broader question, I believe that DarkMatter's alleged
> > involvement with hacking campaigns is incompatible wi
On 2019-02-08 1:04, identr...@gmail.com wrote:
On Thursday, February 7, 2019 at 6:47:03 PM UTC-5, iden...@gmail.com wrote:
On 04/04/2018 we found a discrepancy in the address values for some SSL
certificates. A formal incident Report was just posted:
https://bugzilla.mozilla.org/show_bug.cgi?id
On 2019-02-04 21:33, Kathleen Wilson wrote:
All,
As you know, CCADB sends audit reminder emails regarding root certs in
Mozilla's program on the 3rd Tuesday of each month.
We are going to update the date checks for determining when the email
gets sent, so that rather than keying off of the A
On Fri, Feb 01, 2019 at 03:02:17PM -0700, Wayne Thayer wrote:
> It was pointed out to me that the OCSP status of the misissued certificate
> that is valid for over 5 years is still "unknown" despite having been
> revoked a week ago. I asked KIR about this in the bug [1] and am surprised
> by their
On 2019-01-29 1:29, Wayne Thayer wrote:
Piotr just filed an incident report on the misissuance that was reported on
18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186
I guess this part is not very clear to me:
> We identified and removed from system the registration policy that
>
On 2019-01-24 20:19, Tim Hollebeek wrote:
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Basel
On 2019-01-24 15:41, Rob Stradling wrote:
Here's an example cert containing the A-label in the SAN:dNSName and the
U-label in the CN. (It was issued by Sectigo, known back then as Comodo
CA, before we switched to always putting the A-label in the CN):
https://crt.sh/?id=213062481&opt=cablint,x
On 2019-01-24 12:08, Rob Stradling wrote:
Hi Kurt.
BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
address or Fully-Qualified Domain Name that is one of the values
contained in the Certificate’s subjectAltName extension (see Section
7.1.4.2.1)."
Fitting the U-label int
On 2019-01-24 9:47, Buschart, Rufus wrote:
Good morning!
I would like to sharpen my argument from below a little bit: If a CA gets a
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a
very
On 2019-01-03 16:25, Jakob Bohm wrote:
There is the date fields in the SubCA certificate itself, as well as any
embedded CT data (assuming the parent CA is correctly CT-logged).
Do you expect precertificates for CA certificates?
I currently don't know if there are any requirements for logging
On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy
wrote:
> On 2018-12-18 11:44, Matt Palmer wrote:
> > It's currently loaded with great piles of Debian weak keys (from multiple
> > architectures, etc), as well as some keys I've picked up at va
On 2018-12-19 10:55, Matt Palmer wrote:
On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy
wrote:
On 2018-12-18 11:44, Matt Palmer wrote:
It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I'
On 2018-12-18 11:44, Matt Palmer wrote:
It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.
You might for instance al
On Tue, Dec 04, 2018 at 01:14:44PM -0500, Ryan Sleevi via dev-security-policy
wrote:
>
> > All issued certificates were unusable due to corrupted signature.
> >
>
> Could you speak to more about how you assessed this? An incorrect signature
> on the CRL would not necessarily prevent the certific
On 2018-12-04 10:25, Wojciech Trapczyński wrote:
On 04.12.2018 10:01, Kurt Roeckx via dev-security-policy wrote:
On 2018-12-04 7:24, Wojciech Trapczyński wrote:
Question 1: Was there a period during which this issuing CA had no
validly signed non-expired CRL due to this incident?
Between
On 2018-12-04 7:24, Wojciech Trapczyński wrote:
Question 1: Was there a period during which this issuing CA had no
validly signed non-expired CRL due to this incident?
Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35 (UTC±00:00) we
were serving one CRL with corrupted signature.
On Tue, Oct 23, 2018 at 02:35:37PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> > > Mozilla: Audit Reminder
> > > Root Certificates:
> > > Certinomis - Root CA
> > > Standard Audit:
> > > https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> > > Audit Statement Date: 2017
On 2018-10-31 16:42, Wiedenhorst, Matthias wrote:
In several emails, we answered to his complaint, explained our procedures and
justified the classification of the encoding error as minor (non-critical)
non-conformity.
I think we never consider encoding errors as a minor error.
Kurt
___
On 2018-10-30 16:20, Ryan Sleevi wrote:
Given that the Supervisory Body and National Accreditation bodies exist to
protect the legal value of this scheme, the failure by TUVIT to uphold the
safety and security of the eIDAS regime represents an ongoing threat to the
ecosystem.
Do we have a way o
On Tue, Oct 16, 2018 at 12:49:41PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> Forwarded Message
> Subject: Summary of October 2018 Audit Reminder Emails
> Date: Tue, 16 Oct 2018 19:00:37 + (GMT)
>
> Mozilla: Audit Reminder
> Root Certificates:
>AC Raíz Certi
Probably because no Russian CA has applied to be in the root store.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 2018-08-21 21:03, Kathleen Wilson wrote:
Mozilla: Overdue Audit Statements
Root Certificates:
SwissSign Platinum CA - G2**
** Audit Case in the Common CA Database is under review for this root
certificate.
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Sta
On Thu, Aug 02, 2018 at 06:19:42AM -0700, Juan Angel Martin via
dev-security-policy wrote:
>
> 6) Explanation about how and why the mistakes were made or bugs introduced,
> and how they avoided detection until now.
>
> The procedure established to publish the CAs into CCADB wasn't correct caus
On 2018-07-13 12:02, lcchen.ci...@gmail.com wrote:
We suggest that CA "in principle" must comply with the string length limit
of RFC 5280 for organizationalUnitName or organizationName filed in Subject of a
certificate. But if it is necessary after verification to express an organization’s
On Mon, Jul 09, 2018 at 01:40:17AM +, Peter Gutmann wrote:
>
> Just out of interest, which country did the T61String-containing cert come
> from? With which interpretation of T61String did the resulting strings
> display correctly? Were they in fact latin-1?
As I understand it, it was the S
On Sun, Jul 08, 2018 at 04:41:27PM -0400, Ryan Sleevi wrote:
>
> Is that because you believe it forbidden by spec, or simply unwise?
It's because nobody implements the spec. Those the claim some
support for it are just broken. I have yet to see a certificate
that doesn't just put latin1 in it, wh
On Sat, Jul 07, 2018 at 10:43:26AM +0200, Kurt Roeckx via dev-security-policy
wrote:
> On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via
> dev-security-policy wrote:
> >
> > So for certlint I'd always warn for T61String with anything other than ASCII
> > (
On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via dev-security-policy
wrote:
>
> So for certlint I'd always warn for T61String with anything other than ASCII
> (which century are they living in? Point them at UTF8 and tell them to come
> back when they've implemented it), treat it as a
On Fri, Jul 06, 2018 at 02:43:45PM -0700, Peter Bowen via dev-security-policy
wrote:
> In reviewing a recent CA application, the question came up of what is
> allowed in a certificate in data encoded as "TeletexString" (which is
> also sometimes called T61String).
>
> Specifically, certlint will
On Tue, Jun 19, 2018 at 01:59:26PM -0700, Kathleen Wilson via
dev-security-policy wrote:
>
> Mozilla: Audit Reminder
> Root Certificates:
>SwissSign Platinum CA - G2
>SwissSign Silver CA - G2
> Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
> Audit Statement Date:
On 2018-05-04 12:10, Tim Hollebeek wrote:
It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.
Furthermore, explicit requirements about including mixed case or sp
On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy
wrote:
> seems
> to be mostly justified as a poor workaround for the browsers and
> certificate libraries not properly implementing reliable revocation
> checks.
The problem is not in the libraries, or even the applicati
On Sat, Mar 31, 2018 at 10:14:27PM +, Tim Smith via dev-security-policy
wrote:
> Hi MDSP,
>
> I went looking for corpuses of certificates that may not have been
> previously logged to CT and found some in the Rapid7 "More SSL" dataset,
> which captures certificates from their scans of non-HTT
On Tue, Mar 20, 2018 at 12:07:54PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> Mozilla: Audit Reminder
> Root Certificates:
>Class 2 Primary CA
> Standard Audit:
> https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
> Audit Statement Date: 2017-01-14
> BR Audit: https:/
On 2018-02-27 17:23, Alex Gaynor wrote:
A reasonable compromise that jumps out to me is allowing extensions to make
an otherwise-secure connection fail, but not allow them to rehabilitate an
insecure connection. This would allow experimenting with stricter controls
while avoiding some of the real
On Tue, Feb 27, 2018 at 12:09:01AM +0100, Jakob Bohm via dev-security-policy
wrote:
>
> Hence why an investigation is needed by the 3 CAs named in the paper
> (Comodo, Digicert and Apple). They will probably have to do some deep
> log inspection to figure out patterns, besides reaching out to th
I just came across this:
https://www.recordedfuture.com/code-signing-certificates/
I think the most important part of it is: "we confirmed with a high
degree of certainty that the certificates are created for a specific
buyer per request only and are registered using stolen corporate identitie
On 6/02/2018 17:10, Ryan Sleevi wrote:
The BRs actually seem to allow this, which at least looks like a bug in
the BRs to me.
It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of
the BRs.
It seems that under 3.2.2.3 (b) they can just copy the ccTLD from the
domain name
On 6/02/2018 16:52, Kurt Roeckx wrote:
On 6/02/2018 12:20, Hanno Böck wrote:
Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.
That certificate is revoked, not trusted by Mozilla or chrome.
I should probably more cle
On 6/02/2018 12:20, Hanno Böck wrote:
Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.
That certificate is revoked, not trusted by Mozilla or chrome.
Kurt
___
dev-security-
On 5/02/2018 17:08, Hanno Böck wrote:
https://crt.sh/?id=308392091&opt=ocsp
It has:
Subject:
commonName= ftp.gavdi.pl
countryName = PL
This looks like a combination that's not allowed. Either it's domain
validated, in which case it should
On Wed, Jan 10, 2018 at 01:33:20AM -0800, josh--- via dev-security-policy wrote:
> * Users have the ability to upload certificates for arbitrary names without
> proving domain control.
So a user can always take over the domain of an other user on
those providers just by installing a (self-signed
On 2018-01-04 01:36, Kathleen Wilson wrote:
Mozilla: Audit Reminder
Root Certificates:
AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2120&file=pdf
Audit Statement Date: 2016-09-15
CA Comments: null
The audit period of that is 2015-07-01 to 2016-04-30. The
On Mon, Dec 25, 2017 at 07:59:12AM -0800, Peter Bowen via dev-security-policy
wrote:
> On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy
> wrote:
> > since it's a webserver running on the local machine and is using that
> > certificate key/pair, i think that someone more capable
On Mon, Dec 18, 2017 at 03:04:11PM -0800, Ian Carroll via dev-security-policy
wrote:
>
> I do wonder how many users actually make the connection that the country code
> next to the company name is in fact a country code.
And even if you do make the connection, it's not always obvious
even in wh
On Fri, Dec 08, 2017 at 11:55:46PM +0100, Hanno Böck via dev-security-policy
wrote:
> So I wonder: If a CA signs an intermediate - are they responsible
> making sure that reports brought to the subca are properly handled?
My first reaction would be if you sign it, you take
responsibility. That wo
On 2017-11-15 13:07, Nick Lamb wrote:
And at another extreme Mozilla could decide that Firefox, the browser, won't
trust such names, and blacklist suffixes at its sole discretion, affected DNS
names would simply never get treated as secure in Firefox - it would be
acceptable to issue certifica
Hi,
What I miss is what has been done to prevent new ones from being
issued.
Kurt
On Tue, Nov 07, 2017 at 06:20:53PM +, Jeremy Rowley via dev-security-policy
wrote:
> Hey everyone,
>
>
>
> Here's the DigiCert incident report about the ROCA fingerprints. Note that
> these were all issu
On 2017-09-20 01:09, Kathleen Wilson wrote:
Forwarded Message
Subject: Summary of September 2017 Audit Reminder Emails
Date: Tue, 19 Sep 2017 19:00:08 + (GMT)
Mozilla: Overdue Audit Statements
Root Certificates:
Autoridad de Certificacion Firmaprofesional CIF A62634068
On 2017-08-29 14:47, Paul Kehrer wrote:
I've recently completed a scan of OCSP responders with a focus on checking
whether they are compliant with BR section 4.9.10's requirement: "Effective
1 August 2013, OCSP responders for CAs which are not Technically
Constrained in line with Section 7.1.5 MU
On 2017-08-30 08:46, Adriano Santoni wrote:
>> - 2 are technically constrained sub-CAs (
https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 )
Those two are actually the same certificate; it's not clear to me why
they appear twice on crt.sh
I didn't look if all the name constrains m
On 2017-08-18 16:01, Eric Mill wrote:
Hi Jose,
There was no attachment to your email. Would you mind re-sending with an
attachment?
Attachments never make it to the list.
Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.
On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via dev-security-policy
wrote:
> On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote:
> > > Given that these w
On Sat, Aug 05, 2017 at 02:36:14PM -0700, alex.gaynor--- via
dev-security-policy wrote:
> - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the
> SAN
I think that's actually correrct?
Kurt
___
dev-security-policy mailing list
On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via
dev-security-policy wrote:
> On Thursday, August 3, 2017 at 9:49:41 AM UTC-7, Jonathan Rudenberg wrote:
> > Even absent the BR-violating certificates and disclosure timeline, I
> > believe this cross-sign is problematic because it appe
On 2017-07-26 12:21, Rob Stradling wrote:
At Jonathan's suggestion, I've used the crt.sh DB to produce this report
of certs that have SAN:dNSName(s) that contain non-permitted characters:
The report says "CN or dNSName". It's my understanding that in the CN
you can have international character
On Tue, Jul 25, 2017 at 12:57:44PM -0400, Alex Gaynor via dev-security-policy
wrote:
> Following up on this (and really several other threads). The BRs require
> mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
> are required to track m.d.s.p. per the Mozilla Root Policy,
On Wed, Jul 12, 2017 at 12:12:13PM -0400, Ryan Sleevi wrote:
>
> Consider, for example, a client that does not support path discovery
> (which, for example, includes most actively-deployed OpenSSL versions). If
> one were to extract certdata.txt into trust and distrust records, with the
> algorith
On 2017-07-12 16:12, Ryan Sleevi wrote:
I don't know if this currently happens, but I would like to see all CA
certificates that are in OneCRL but are not revoked to be added to the root
store as distrusted too.
Why? I can share reasons why it might not be desirable, but rather than
start out
On 2017-07-11 15:56, Nick Lamb wrote:
On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:>
So at least some of them have been notified more than 3 months ago, and
a bug was filed a month later. I think you already gave them too much
time to at least respond to it, and suggest that you s
On 2017-07-10 18:35, Alex Gaynor wrote:
Hi all,
I wanted to call some attention to a few intermediates which have been
hanging out in the "Audit required" section for quite a while:
https://crt.sh/mozilla-disclosures#disclosureincomplete
Specifically, the TurkTrust and Firmaprofesional ones. Bo
On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote:
> On 27/06/17 07:17, Kurt Roeckx wrote:
> > I suggest you keep it for now.
>
> An opinion without a rationale is not all that useful :-)
A lot of software supports it, including NSS / Firefox. It's not
an ideal curve, and it should
On 2017-06-27 15:51, Gervase Markham wrote:
This issue seems to come up regularly, and I can never find the
discussion I'm sure we had about it, so I'm starting a thread here with
"P-521" in the subject so it'll be clear.
Should we be permitting use of this curve in our policy?
I suggest you k
On 2017-06-23 14:59, Rob Stradling wrote:
Reasons:
- Some are only trusted by the old Adobe CDS program.
- Some are only trusted for Microsoft Kernel Mode Code Signing.
- Some are very old roots that are no longer trusted.
I wonder if Google's daedalus would like to see some of those.
On 2017-06-08 14:09, wiz...@ida.net wrote:
But Censys lists it as a trusted intermediate chaining to a root (
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:
https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation
I
On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL Distribution
Point URLs for each CA. The CDP URLs listed at
https://crt.sh/?id=12729173 were observed in other certs issued by the > same CA:
That shows:
http://www.cert.fnmt.es/crls/ARLFNMTRC
On 2017-06-08 13:31, richmoor...@gmail.com wrote:
This one is interesting since the domain name of the CRL resolves to an RFC
1918 IP address. Surely that is a violation of the baseline requirements.
https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
That
On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote:
> On 02/06/17 12:24, Kurt Roeckx wrote:
> > Should that be "all certificates" instead of "all SSL certificates"?
>
> No; the Baseline Requirements apply only to SSL certificates.
Then I don't understand what you're trying to do. If
1 - 100 of 152 matches
Mail list logo
