Re: Misissued/Suspicious Symantec Certificates

So after reading this, the following auditors aren't trusted by Symantec anymore: - E Korea - E Brazil The following isn't trusted by Mozilla anymore: - E Hong Kong This seems to be a worrying trend to me. Kurt On 2017-02-12 20:25, Eric Mill wrote: Also relevant are Symantec's statements

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

On Mon, Mar 27, 2017 at 09:02:48PM +0100, Gervase Markham via dev-security-policy wrote: > On 27/03/17 16:08, Martin Heaps wrote: > > The next level is now that any business or high valued entity should > > over the course of the next few years implement EV certificates (many > > already have)

Re: Next CA Communication

On 2017-03-21 12:51, Jakob Bohm wrote: On 21/03/2017 10:09, Kurt Roeckx wrote: On 2017-03-17 16:30, Gervase Markham wrote: The URL for the draft of the next CA Communication is here:

Re: Symantec Response B

On 2017-04-11 17:20, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Hi Ryan, On 10/04/17 16:38, Ryan Sleevi wrote: 1) You're arguing that "the issuance of this cert didn't impose risk on anyone but

Re: Symantec Response B

On 2017-04-11 17:54, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The reply indicated that it was a non-browser application. So I understand that a browser should never see that certificate. T

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 2017-04-12 11:47, Gervase Markham wrote: "If the certificate includes the id-kp-emailProtection extended key usage, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees." I think this change itself makes

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what was not. The policy already has some requirements here, in section 3.1.3, mostly

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 14:19, Jakob Bohm wrote: On 12/04/2017 12:44, Kurt Roeckx wrote: On 2017-04-12 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 16:15, Peter Bowen wrote: On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy wrote: A certificate hash does provide distinct value. The certificate hash is what is desired. Yes, there could be multiple certificates. But

Re: Symantec Response J

On 2017-04-11 11:15, Kurt Roeckx wrote: On 2017-04-10 17:52, Ryan Sleevi wrote: Hi Steve, Quick question: 1) You identified that the root cause was related to a deprecated, but not removed, interface. Your remediation was to remove that interface. a) How many deprecated, but unremoved,

Re: Symantec Response J

On 2017-04-10 17:52, Ryan Sleevi wrote: Hi Steve, Quick question: 1) You identified that the root cause was related to a deprecated, but not removed, interface. Your remediation was to remove that interface. a) How many deprecated, but unremoved, interfaces does Symantec have, as of

Re: Symantec Response P

On 2017-04-10 16:57, Steve Medin wrote: Because our customers are our top priority, we attempted to minimize business disruption I think you have your top priority wrong, and this seems to be a reoccurring reason why you do things. Kurt ___

Re: Symantec Conclusions and Next Steps

On Fri, Apr 21, 2017 at 11:16:56AM +0100, Gervase Markham via dev-security-policy wrote: > Minor: > Issue B: Issuance of 1024-bit Certificate Expiring After Deadline I'm still concerned that they don't seem to have an idea of what software they're all (still) running, and they didn't reply to

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 12:28:16PM -0700, Ryan Sleevi via dev-security-policy wrote: > > https://portal.mobilitymixx.nl > > I'm not sure I understand enough to know what the issues are here. Could you > explain? Both the localityName and stateOrProvinceName are Almere, while the province is

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 10:41:33PM +, Peter Gutmann via dev-security-policy wrote: > Kurt Roeckx via dev-security-policy <dev-security-policy@lists.mozilla.org> > writes: > > >Both the localityName and stateOrProvinceName are Almere, while the province > >

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 11:58:28PM +, Jeremy Rowley wrote: > That was changed in ballot 127. Which is adopted in july 2014. This was somewhere in 2016. As I understood it, they didn't ask for the HR department, just someone else. That might of course be a misunderstanding of what was asked,

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 09:00:22PM -0400, Ryan Sleevi wrote: > On Wed, Apr 19, 2017 at 7:53 PM, Kurt Roeckx via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > (It was a code sign certificate, but I expect if it's labeled EV > &

Re: DigiCert BR violation

On Thu, Mar 09, 2017 at 06:29:57PM -0500, Ryan Sleevi via dev-security-policy wrote: > > However, I think this discussion raises some very interesting points about > > real world scenarios and RFC 5280 that should be addressed. DigiCert > > actually has three items that routinely show up on

Re: DigiCert BR violation

On 2017-03-09 02:08, Ryan Sleevi wrote: It appears that DigiCert has violated the Baseline Requirements, as recently notified to the CA/Browser Forum. The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280. RFC 5280 defines the upper-bound of the commonName field as 64

Re: Google Trust Services roots

On 2017-03-09 05:21, Ryan Sleevi wrote: Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details. Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate.

Re: DigiCert BR violation

On 2017-03-14 02:19, Peter Bowen wrote: On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy wrote: On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: Are you saying that there are one or more clients that require DigiCert to

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

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: 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: 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: 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 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: 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: 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, and it should

Re: Symantec Conclusions and Next Steps

On 2017-04-24 11:18, Gervase Markham wrote: On 21/04/17 11:38, Kurt Roeckx wrote: I'm still concerned that they don't seem to have an idea of what software they're all (still) running, and they didn't reply to any question about it. I'm sorry, I don't follow. Can you expand? I confused some

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: 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: Aetna and UniCredit audits

On 2017-05-15 12:52, Gervase Markham wrote: Symantec never received any formal audits from UniCredit; I am trying to get hold of the informal ones. Their participation in the GeoRoot program started in January 2012: https://crt.sh/?CN=UniCredit+Subordinate+External So both organizations had

Re: April CA Communication: Results

On 2017-05-15 13:40, Gervase Markham wrote: * (Q13) Many CAs plan to stop issuing SHA-1 S/MIME by the end of this year. CAs without a firm date are: Comodo, GlobalSign, SECOM, TWCA, and Visa. A couple of these CAs hint that an industry deadline to stop would help their customers see the need to

Re: April CA Communication: Results

On 2017-05-15 15:26, Gervase Markham wrote: On 15/05/17 14:19, Doug Beattie wrote: https://support.globalsign.com/customer/portal/articles/1216323 Thanks, Doug. There's no date on that doc - are you able to say when it was written? It says: Last Updated: Aug 26, 2013 11:24AM EDT Kurt

Re: April CA Communication: Results

On 2017-05-15 15:38, Kurt Roeckx wrote: On 2017-05-15 15:26, Gervase Markham wrote: On 15/05/17 14:19, Doug Beattie wrote: https://support.globalsign.com/customer/portal/articles/1216323 Thanks, Doug. There's no date on that doc - are you able to say when it was written? It says: Last

Re: Hunting for intermediates that still haven't been disclosed to CCADB

On 2017-05-11 13:07, Rob Stradling wrote: It would seem that DigiCert noticed these 19 intermediates appear on https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, because they've all now been disclosed to the CCADB. They should've been disclosed some time ago, however. Does

Re: Symantec: Update

On Tue, May 09, 2017 at 04:51:12PM +0100, Gervase Markham via dev-security-policy wrote: > Despite the fact that there appear to be > numerous under-audited and unaudited publicly-trusted sub-CAs out there, > and this fact has been known for weeks now, Symantec has not said > anything about the

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

On 2017-05-16 14:24, Michael Casadevall wrote: Maybe a bit out there, but an interesting thought none the less. It would definitely go a good way at preventing one root certificate from underpinning a large chunk of the internet. My thought here is if a large "Too Big to Fail" CA's private key

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

On 2017-05-17 13:23, Michael Casadevall wrote: On 05/17/2017 05:04 AM, Kurt Roeckx wrote: If the key is compromised, you can't rely on any date information anymore, you need to revoke it completely and break things. Won't that only be true in certificates without SCTs? Once you have a SCT,

Re: Hunting for intermediates that still haven't been disclosed to CCADB

On 2017-05-17 14:40, Rob Stradling wrote: On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote: On 2017-05-11 19:05, Gervase Markham wrote: On 11/05/17 12:46, Rob Stradling wrote: There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field

Re: Policy 2.5 Proposal: Add anyEKU to scope

On 2017-05-12 15:00, Gervase Markham wrote: Because the Mozilla root store is used by more people than Mozilla, Kathleen would like to put anyEKU in scope even though Firefox ignores it. I think the CCADB document needs to be updated too. Kurt

Re: Policy 2.5 Proposal: Add anyEKU to scope

On 2017-05-12 17:31, Kurt Roeckx wrote: On 2017-05-12 15:00, Gervase Markham wrote: Because the Mozilla root store is used by more people than Mozilla, Kathleen would like to put anyEKU in scope even though Firefox ignores it. I think the CCADB document needs to be updated too. It might

Re: Hunting for intermediates that still haven't been disclosed to CCADB

On 2017-05-11 19:05, Gervase Markham wrote: On 11/05/17 12:46, Rob Stradling wrote: There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla

Re: Configuring Graduated Trust for Non-Browser Consumption

On Fri, May 12, 2017 at 07:50:46PM +0200, Jakob Bohm via dev-security-policy wrote: > On 12/05/2017 10:06, Kurt Roeckx wrote: > > From past discussion on the OpenSSL list, I understand that we want to > > support a trust store that supports all such kind of attributes. Some > > things like for

Re: Symantec: Update

On Tue, May 09, 2017 at 07:03:16PM +0200, Kurt Roeckx via dev-security-policy wrote: > > Instead of the removal of the roots, I suggest we either ask them > to revoke all the intermediate CAs that do not have the required > audits or that Mozilla adds them to OneCRL. Just to clarif

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

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: 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: 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 understand what you're trying to do. If

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: 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: 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: Symantec: Draft Proposal

On Sun, May 07, 2017 at 03:09:10PM -0700, Rick Andrews via dev-security-policy wrote: > We urge Symantec customers and the browser community to pause on decisions > related to this matter until final proposals are posted and accepted. You appear to be saying that Mozilla doesn't have anything

Re: Symantec: Draft Proposal

On 2017-05-04 22:55, Alex Gaynor wrote: I believe this further underscores finding Y, and others related to lack of visibility into and BR-compliance of Symantec's intermediates. The fact that we can still be finding new intermediates leaves me to wonder if this is really the last of them, or

Re: Draft further questions for Symantec

On 2017-05-08 14:24, Gervase Markham wrote: 1) Did any of the RAs in your program (CrossCert and co.) have the technical ability to independently issue EV certificates? If they did not not, given that they had issuance capability from intermediates which chained up to EV-enabled roots, what

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

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

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

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

  1   2   >