Re: Summary of Camerfirma's Compliance Issues

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

Re: Extending Android Device Compatibility for Let's Encrypt Certificates

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 >

Re: Extending Android Device Compatibility for Let's Encrypt Certificates

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

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

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

Re: Non-DER certificate (PKCS #7) in CA Issuers AIA field

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

Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours

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

Re: Digicert issued certificate with let's encrypts public key

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 the p

Digicert issued certificate with let's encrypts public key

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

Re: Mozilla's Expectations for OCSP Incident Reporting

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]).

Re: Mozilla's Expectations for OCSP Incident Reporting

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

Re: GTS - OCSP serving issue 2020-04-09

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,

Re: Is issuing a certificate for a previously-reported compromised private key misissuance?

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

Re: Which fields containing email addresses need to be validated?

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

Re: Which fields containing email addresses need to be validated?

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

Re: Certificate OU= fields with missing O= field

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

Re: Website owner survey data on identity, browser UIs, and the EV UI

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

Re: Website owner survey data on identity, browser UIs, and the EV UI

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

Re: Website owner survey data on identity, browser UIs, and the EV UI

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 accordin

Re: Website owner survey data on identity, browser UIs, and the EV UI

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

Re: DigiCert OCSP services returns 1 byte

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

Re: DigiCert OCSP services returns 1 byte

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

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

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

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,

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

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

Re: [FORGED] Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

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

Re: Audit Reminder Email Summary

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 >

Re: Survey of (potentially noncompliant) Serial Number Lengths

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

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

Re: DarkMatter Concerns

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

Re: DarkMatter Concerns

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

Re: Discrepancy on Address

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:

Re: Changing Date Checks in Audit Reminder Emails

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

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

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

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

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):

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

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

Re: Yet more undisclosed intermediates

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

Re: Online exposed keys database

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 various time

Re: Online exposed keys database

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've picked

Re: Online exposed keys database

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

Re: Incident report Certum CA: Corrupted certificates

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

Re: Incident report Certum CA: Corrupted certificates

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

Re: Incident report Certum CA: Corrupted certificates

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.

Re: Audit Reminder Email Summary

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:

Re: Questions regarding the qualifications and competency of TUVIT

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

Re: Questions regarding the qualifications and competency of TUVIT

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

Re: Audit Reminder Email Summary

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

Re: No Russian CAs

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

Re: Audit Reminder Email Summary

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

Re: AC Camerfirma's undisclosed itermediate certificates incident report

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

Re: Chunghwa Telecom eCA Root Inclusion Request

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

Re: [FORGED] TeletexString

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,

Re: [FORGED] TeletexString

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

Re: [FORGED] TeletexString

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

Re: TeletexString

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

Re: Audit Reminder Email Summary

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:

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

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

Re: 825 days success and future progress!

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

Re: Discovering unlogged certificates in internet-wide scans

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

Re: Audit Reminder Email Summary

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:

Re: Code signing and malware

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

Code signing and malware

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

Re: Certificates with 2008 Debian weak key bug

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

Re: Certificate for com and it

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 pro

Re: Certificate for com and it

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 ___

Re: Certificates with 2008 Debian weak key bug

On 5/02/2018 17:08, Hanno Böck wrote: https://crt.sh/?id=308392091=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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: Audit Reminder Email Summary

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=pdf Audit Statement Date: 2016-09-15 CA Comments: null The audit period of that is 2015-07-01 to 2016-04-30. They

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

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

Re: On the value of EV

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

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

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

Re: DigiCert ROCA fingerprint incident report

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

Re: Violations of Baseline Requirements 4.9.10

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

Re: Violations of Baseline Requirements 4.9.10

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

Re: AC FNMT Usuarios and anyExtendedKeyUsage

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

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

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

Re: Certificates with common names not present in their SANs

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

Re: StartCom cross-signs disclosed by Certinomis

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

Re: Bad characters in dNSNames

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

Re: Miss-issuance: URI in dNSName SAN

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

Re: How long to resolve unaudited unconstrained intermediates?

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 >

Re: How long to resolve unaudited unconstrained intermediates?

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

Re: How long to resolve unaudited unconstrained intermediates?

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

Re: How long to resolve unaudited unconstrained intermediates?

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.

Re: P-521

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

Re: P-521

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

Re: Unknown Intermediates

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.

Re: New undisclosed intermediates

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

Re: New undisclosed intermediates

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:

Re: New undisclosed intermediates

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 2017-06-02 12:28, Gervase Markham wrote: "Insofar as the Baseline Requirements attempt to define their own scope, the scope of this policy (section 1.1) overrides that. Mozilla expects CA operations relating to issuance of all SSL certificates in the scope of this policy to conform to the

Re: StartCom issuing bogus certificates

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

Re: Google Plan for Symantec posted

On Mon, May 22, 2017 at 05:33:26PM +0100, Gervase Markham via dev-security-policy wrote: > Google are doing a phased distrust of old certs, but they have not set a > date in their plan for total distrust of the old PKI. We should ask them > what their plans are for that. My understanding is that

Re: Google Plan for Symantec posted

On Fri, May 19, 2017 at 01:04:45PM -0700, Kathleen Wilson via dev-security-policy wrote: > > Gerv, thank you for all the effort you have been putting into this > investigation into Symantec's mis-issuances, and in identifying the best way > to move forward with the primary goal being to help

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

On 2017-05-19 14: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

  1   2   3   4   >