Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 2020-11-18 16:36, Ryan Sleevi wrote: On Wed, Nov 18, 2020 at 8:19 AM Nils Amiet via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: We have carefully read your email, and believe we’ve identified the following important points: 1. Potential feasibility issue due to lack

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 2020-11-16 23:17, Ryan Sleevi wrote: On Mon, Nov 16, 2020 at 8:40 AM Nils Amiet via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Hi Nils, This is interesting, but unfortunately, doesn’t work. The 4-certificate hierarchy makes the very basic, but understandable,

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

On 2020-11-12 05:15, Ben Wilson wrote: Here is an attempt to address the comments received thus far. In Github, here is a markup: https://github.com/BenWilson-Mozilla/pkipolicy/commit/ee19ee89c6101c3a6943956b91574826e34c4932 This sentence would be deleted: "These requirements include all

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On 2020-11-06 18:31, Jeff Ward wrote: > ... Audit reports, whether for WebTrust, financial statements, or other forms of engagement reports providing assurance to users of the information, do not include specific audit team members’ names. Simply stated, this desire to include individual

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

On 2020-11-05 22:43, Tim Hollebeek wrote: So, I'd like to drill down a bit more into one of the cases you discussed. Let's assume the following: 1. The CAO [*] may or may not have requested removal of the CAC, but removal has not been completed. The CAC is still trusted by at least one public

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

On 2020-10-30 18:45, Ryan Sleevi wrote: On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 2020-10-30 16:29, Rob Stradling wrote: Perhaps add: "And also include any other certificates sharing the same private/publi

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

"as CA certificates". ____________ From: Jakob Bohm via dev-security-policy Sent: 29 October 2020 14:57 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates On 2020-10-29 01:25, Ben Wilson wrote

Re: TLS certificates for ECIES keys

On 2020-10-30 01:50, Matthew Hardeman wrote: On Thu, Oct 29, 2020 at 6:30 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The way I read Jacob's description of the process, the subscriber is "misusing" the certificate because they're not going to present

Re: TLS certificates for ECIES keys

On 2020-10-29 19:06, Jacob Hoffman-Andrews wrote: Hi all, ISRG is working with Apple and Google to deploy Prio, a "privacy-preserving system for the collection of aggregate statistics:" https://crypto.stanford.edu/prio/. Mozilla has previously demonstrated Prio for use with telemetry data:

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

On 2020-10-29 01:25, Ben Wilson wrote: Issue #186 in Github deals with the disclosure of CA certificates that directly or transitively chain up to an already-trusted, Mozilla-included root. A common scenario for the situation discussed in Issue

Re: EJBCA performs incorrect calculation of validities

On 2020-10-28 20:54, Ryan Sleevi wrote: On Wed, Oct 28, 2020 at 10:50 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: This aspect of RFC5280 section 4.1.2.5 is quite unusual in computing, where the ends of intervals are typically e

Re: EJBCA performs incorrect calculation of validities

On 2020-10-28 11:55, Mike Kushner wrote: Hi all, We were alerted to the fact that EJBCA does not calculate certificate and OCSP validities in accordance with RFC 5280, which has been a requirement since BR 1.7.1 The word "inclusive" was not caught, meaning that a certificate/response issued

Re: PEM of root certs in Mozilla's root store

On 2020-10-17 01:38, Ryan Sleevi wrote: On Fri, Oct 16, 2020 at 5:27 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: RFC4180 section 3 explicitly warns that there are other variants and specifications of the CSV format, and thus the full generaliz

Re: PEM of root certs in Mozilla's root store

On 2020-10-16 14:11, Ryan Sleevi wrote: On Thu, Oct 15, 2020 at 7:44 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 2020-10-15 11:57, Ryan Sleevi wrote: On Thu, Oct 15, 2020 at 1:14 AM Jakob Bohm via dev-security-policy < dev-securi

Re: Sectigo to Be Acquired by GI Partners

On 2020-10-16 12:33, Rob Stradling wrote: ...clarification of what meaning was intended. Merely this... "Hi Ryan. Tim Callan posted a reply to your questions last week, but his message has not yet appeared on the list. Is it stuck in a moderation queue?" The part needing clarification

Re: Sectigo to Be Acquired by GI Partners

s intended. From: dev-security-policy on behalf of Jakob Bohm via dev-security-policy Sent: 12 October 2020 22:41 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Sectigo to Be Acquired by GI Partners Hi Rob, The e-mail you quote below seems to be ina

Re: PEM of root certs in Mozilla's root store

On 2020-10-15 11:57, Ryan Sleevi wrote: On Thu, Oct 15, 2020 at 1:14 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: For example, embedded new lines are discussed in 2.6 and the ABNF therein. The one difference from RFC4180 is that CR

Re: PEM of root certs in Mozilla's root store

On 2020-10-15 04:52, Ryan Sleevi wrote: On Wed, Oct 14, 2020 at 7:31 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Only the CSV form now contains CSV artifacts. And it isn't really CSV either (even if Microsoft Excel handles it). Hi Jakob, Cou

Re: PEM of root certs in Mozilla's root store

On 2020-10-15 00:16, Kathleen Wilson wrote: The text version has been updated to have each line limited to 64 characters. Text: https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Websites

Re: PEM of root certs in Mozilla's root store

On 2020-10-13 16:32, Ryan Sleevi wrote: Jakob, I had a little trouble following your mail, despite being quite familiar with PEM, so hopefully you'll indulge me in making sure I've got your criticisms/complaints correct. Your objection to the text report is that RFC 7468 requires generators to

Re: PEM of root certs in Mozilla's root store

On 2020-10-12 20:50, Kathleen Wilson wrote: On 10/7/20 1:09 PM, Jakob Bohm wrote: Please note that at least the first CSV download is not really a CSV file, as there are line feeds within each "PEM" value, and only one column.  It would probably be more useful as a simple concatenated PEM

Re: Sectigo to Be Acquired by GI Partners

Hi Rob, The e-mail you quote below seems to be inadvertently "confirming" some suspicions that someone else posed as questions. I think the group as a whole would love to have actual specific answers to those original questions. Remember to always add an extra layer of ">" indents for each

Re: PEM of root certs in Mozilla's root store

On 2020-10-06 23:47, Kathleen Wilson wrote: All, I've been asked to publish Mozilla's root store in a way that is easy to consume by downstreams, so I have added the following to https://wiki.mozilla.org/CA/Included_Certificates CCADB Data Usage Terms

Re: Temporary WebTrust Seal for COVID Issues

On 2020-08-20 20:34, Ben Wilson wrote: All, Some CAs have inquired about Mozilla's acceptance of WebTrust's temporary, 6-month seal related to COVID19 issues. See https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services According to that

Re: [FORGED] Re: How Certificates are Verified by Firefox

On 2019-12-09 11:44, Ben Laurie wrote: On Wed, 4 Dec 2019 at 22:13, Ryan Sleevi wrote: Yes, I am one of the ones who actively disputes the notion that AIA considered harmful. I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. supportive of "considered harmful", since it's

Re: Certificate OU= fields with missing O= field

[Top posting because previous post did] As a relying party and a subscriber of some certificates, I would consider each of the following combinations as something that should be both permitted and useful under any future rules, even if the current BRs don't allow it. 1. O=Actual Org name and

Re: Firefox removes UI for site identity

On 23/10/2019 01:49, Matt Palmer wrote: On Tue, Oct 22, 2019 at 03:35:52PM -0700, Kirk Hall via dev-security-policy wrote: I also have a question for Mozilla on the removal of the EV UI. This is a mischaracterisation. The EV UI has not been removed, it has been moved to a new location.

Re: CAs cross-signing roots whose subjects don't comply with the BRs

On 08/10/2019 13:41, Corey Bonnell wrote: On Monday, October 7, 2019 at 10:52:36 AM UTC-4, Ryan Sleevi wrote: I'm curious how folks feel about the following practice: Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They create this Root Certificate after the effective date

Re: CAs cross-signing roots whose subjects don't comply with the BRs

On 07/10/2019 17:35, Ryan Sleevi wrote: > On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 07/10/2019 16:52, Ryan Sleevi wrote: >>> I'm curious how folks feel about the following practi

Re: CAs cross-signing roots whose subjects don't comply with the BRs

On 07/10/2019 16:52, Ryan Sleevi wrote: I'm curious how folks feel about the following practice: Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They create this Root Certificate after the effective date of the Baseline Requirements, but prior to Root Programs consistently

Re: DigiCert OCSP services returns 1 byte

On 17/09/2019 00:58, Wayne Thayer wrote: > On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote: > >> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote: >> >> >> If a certificate (with embedded SCTs and no CT poison extension) is >> "presumed to exist" but the CA has not actually

Re: DigiCert OCSP services returns 1 byte

On 16/09/2019 19:08, Andrew Ayer wrote: > On Fri, 13 Sep 2019 08:22:21 + > Rob Stradling via dev-security-policy > wrote: > >> Thinking aloud... >> Does anything need to be clarified in 6962-bis though? > > Yes, it's long past time that we clarified what this means: > > "This signature

Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

On 04/09/2019 17:14, Ryan Sleevi wrote: > On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson wrote: > >> I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder >> certificate itself (not the CA that issues the OCSP responder certificate). >> I don't think I've encountered a problem

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

On 03/09/2019 00:54, Ryan Sleevi wrote: > On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla

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

On 02/09/2019 20:13, Alex Cohn wrote: On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: If an OCSP server supports returning (or always returns) properties of the actual cert, such as the CT proofs, then it really cannot

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

If an OCSP server supports returning (or always returns) properties of the actual cert, such as the CT proofs, then it really cannot do its usual "good" responses until the process of retrieving CT proofs and creating the final TBScertificate (and possibly signing it) has been completed. Thus

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

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 returning incorrect results for a

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

On 29/08/2019 19:47, Nick Lamb wrote: > On Thu, 29 Aug 2019 17:05:43 +0200 > Jakob Bohm via dev-security-policy > wrote: > >> The example given a few messages above was a different jurisdiction >> than those two easily duped company registries. > > I see. Perha

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

On 29/08/2019 10:58, Nick Lamb wrote: > On Wed, 28 Aug 2019 11:51:37 -0700 (PDT) > Josef Schneider via dev-security-policy > wrote: > >> Not legally probably and this also depends on the jurisdiction. Since >> an EV cert shows the jurisdiction, a user can draw conclusions from >> that. > > Yes

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

On 27/08/2019 08:03, Peter Gutmann wrote: > Jakob Bohm via dev-security-policy > writes: > >> <https://www.typewritten.net/writer/ev-phishing/> and >> <https://stripe.ian.sh/> both took advantage of weaknesses in two >> government registries >

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

On 26/08/2019 21:49, Jonathan Rudenberg wrote: > On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote: >> <https://www.typewritten.net/writer/ev-phishing/> and >> <https://stripe.ian.sh/> both took advantage of weaknesses in two >> government

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

On 24/08/2019 05:55, Tom Ritter wrote: On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy wrote: Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane: On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote: Whatever the merits of EV (and perhaps

Re: Jurisdiction of incorporation validation issue

[Please note that the way MS Outlook marks quoted text doesn't work well with Mozilla mail programs]. On 23/08/2019 22:37, Jeremy Rowley wrote: >> 1. I believe the BRs and/or underlying technical standards are very >> clear if the ST field should be a full name ("California") or an >>

Re: Jurisdiction of incorporation validation issue

On 23/08/2019 04:29, Jeremy Rowley wrote: I posted this tonight: https://bugzilla.mozilla.org/show_bug.cgi?id=1576013. It's sort of an extension of the "some-state" issue, but with the incorporation information of an EV cert. The tl;dr of the bug is that sometimes the information isn't

Re: CA handling of contact information when reporting problems

On 20/08/2019 03:15, Corey Bonnell wrote: On Monday, August 19, 2019 at 10:26:06 AM UTC-4, Mathew Hodson wrote: Tom Wassenberg on Twitter reported an experience he had with Sectigo when reporting a compromised private key. https://twitter.com/tomwas54/status/1162114413148725248

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

On 17/08/2019 00:56, James Burton wrote: If one compares the first EV specification with the current EV specification one will notice that the EV specification hasn't changed that much during its lifetime. The issues presented during the last years though research have been known about since the

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

On 17/08/2019 03:15, Peter Gutmann wrote: Corey Bonnell via dev-security-policy writes: the effectiveness of the EV UI treatment is predicated on whether or not the user can memorize which websites always use EV certificates *and* no longer proceed with using the website if the EV treatment

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

On 14/08/2019 18:18, Peter Bowen wrote: On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: A policy of switching from positive to negative indicators of security differences is no justification to switch to NO indi

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

DO NOT SHIP THIS. Revert the change immediately and request a CVE number for the nightlies with this change included. That Chrome does something harmful is not surprising, and is no justification for a supposedly independent browser to do the same. A policy of switching from positive to

Re: How to use Cross Certificates to support Root rollover

One note: As a company that actively supports users with old operating systems and OS-provided root stores, we have been deliberately including your R1-R3 cross, and are battling problems with a few really old platforms that plain don't support any certs currently available. This isn't just

Re: Comodo password exposed in GitHub allowed access to internal Comodo files

On 28/07/2019 00:41, Nick Lamb wrote: On Sun, 28 Jul 2019 00:06:38 +0200 Ángel via dev-security-policy wrote: A set of credentials mistakenly exposed in a public GitHub repository owned by a Comodo software developer allowed access to internal Comodo documents stored in OneDrive and

Re: Nation State MITM CA's ?

On 21/07/2019 03:21, My1 wrote: Hello everyone, I am new here but also want to share my opinion about some posts here, I know it's a lot of text but I hope it's not too bad. Am Freitag, 19. Juli 2019 23:42:47 UTC+2 schrieb dav...@gmail.com: Wouldn't it be easier to just decree that HTTPS is

Re: Nation State MITM CA's ?

On 20/07/2019 09:31, simc...@gmail.com wrote: I think it must be quickly blacklisted by Google, Mozilla and Microsoft all together, because it is known as a state scale MITM affecting citizen "real" life. The purpose of https is being defeated and such companies who tried to improve network

Re: Nation State MITM CA's ?

On 19/07/2019 21:13, andrey.at.as...@gmail.com wrote: I am confused. Since when Mozilla is under obligation to provide customized solutions for corporate MITM? IMHO, corporations, if needed, can hire someone else to develop their own forks of Chrome/Firefox to do snooping on HTTPS

Re: Nation State MITM CA's ?

On 19/07/2019 16:52, Troy Cauble wrote: On Thursday, July 18, 2019 at 8:26:43 PM UTC-4, wolfgan...@gmail.com wrote: Even on corporate hardware I would like at least a notification that this is happening. I like the consistency of a reminder in all cases, but this might lead to corporate

Re: Expired Root CA in certdata.txt

As Mozilla has stopped caring about code signatures, e-mails are much more relevant for checking old certificates as of a known date: Most e-mail systems provide the reader with a locally verified record of when exactly the mail contents reached a trusted mail server and/or a POP3 client. Thus

Re: Logotype extensions

On 14/06/2019 18:54, Ryan Sleevi wrote: > On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> In such a case, there are two obvious solutions: >> >> A. Trademark owner (prompted by applic

Re: Logotype extensions

On 14/06/2019 04:16, Corey Bonnell wrote: On Thursday, June 13, 2019 at 2:04:48 AM UTC-4, kirkhal...@gmail.com wrote: On Tuesday, June 11, 2019 at 2:49:31 PM UTC+3, Jeremy Rowley wrote: We wanted to experiment a bit with logotype extensions and trademarks, but we heard from the CAB Forum that

Re: Certinomis Issues

On 17/05/2019 07:21, Jakob Bohm wrote: > On 17/05/2019 01:39, Wayne Thayer wrote: >> On Thu, May 16, 2019 at 4:23 PM Wayne Thayer wrote: >> >> I will soon file a bug requesting removal of the “Certinomis - Root CA” >>> from NSS. >>> >> >> This is

Re: Certinomis Issues

On 17/05/2019 01:39, Wayne Thayer wrote: On Thu, May 16, 2019 at 4:23 PM Wayne Thayer wrote: I will soon file a bug requesting removal of the “Certinomis - Root CA” from NSS. This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374 To more accurately assess the impact of distrust,

Re: Certinomis Issues

On 10/05/2019 02:22, Wayne Thayer wrote: Thank you for this response Francois. I have added it to the issues list [1]. Because the response is not structures the same as the issues list, I did not attempt to associate parts of the response with specific issues. I added the complete response to

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

On 10/05/2019 05:25, Ryan Sleevi wrote: On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 09/05/2019 16:35, Ryan Sleevi wrote: Given that the remark is that such a desire is common, perhaps you can provide some ex

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

On 09/05/2019 16:35, Ryan Sleevi wrote: > On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> [ Note, I am arguing a neutral position on the specific proposal ] >> >> The common purpose of havi

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

On 08/05/2019 16:05, Ryan Sleevi wrote: > On Wed, May 8, 2019 at 6:42 AM Fotis Loukos wrote: > >> ... > ... > >> The scheme I'm proposing is the following: >> >> Org CA (serverAuth, emailProtection, and possibly others such as >> clientAuth) >>\- Org SSL CA (serverAuth and possibly

Re: Unretrievable CPS documents listed in CCADB

The issue of identifying the proper CPS for older certificates raises the important overall question of how this should be managed on an industry wide basis: Note: All examples use numerically invalid values, such as OIDs beginning with "5." or non-existent dates in the Gregorian calendar.

Re: Certinomis Issues

On 01/05/2019 22:29, mono.r...@gmail.com wrote: 2017 assessment report LSTI didn't issue to Certinomis any "audit attestation" for the browsers in 2017. The document Wayne references is a "Conformity Assessment Report" for the eIDAS regulation. I had a look at the 2017 report, and unless I

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

On 16/04/2019 08:56, Tadahiko Ito wrote: On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote: I agree the requirements are already clear. The problem is not the clarity of the requirements. Anybody can define a new EKU because EKUs are listed in the certificate by OIDs, and

Re: Arabtec Holding public key? [Weird Digicert issued cert]

19 6:57 PM, Jakob Bohm via dev-security-policy wrote: Thanks for the explanation. Is it possible that a significant percentage of less-skilled users simply pasted in the wrong certificates by mistake, then wondered why their new certificates newer worked? Pasting in the wrong certificate from an

Re: Arabtec Holding public key? [Weird Digicert issued cert]

at 6:57 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 11/04/2019 04:47, Santhan Raj wrote: On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: (Resending after I

Re: Arabtec Holding public key? [Weird Digicert issued cert]

On 11/04/2019 04:47, Santhan Raj wrote: On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: (Resending after I typo'd the ML address) At the risk of further embarrassing myself in the same week, while

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

On 04/04/2019 02:22, Wayne Thayer wrote: A number of ECC certificates that fail to meet the requirements of policy section 5.1 were recently reported [1]. There was a lack of awareness that Mozilla policy is more strict than the BRs in this regard. I've attempted to address that by adding this

Re: Apple: Non-Compliant Serial Numbers

On 30/03/2019 22:16, certification_author...@apple.com wrote: > On March 30, Apple submitted an update to the original incident report > (https://bugzilla.mozilla.org/show_bug.cgi?id=1533655), which is reposted > below. >

Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

On 28/03/2019 21:52, Wayne Thayer wrote: > Our current Root Store policy assigns two different meanings to the term > "technically constrained": > * in sections 1.1 and 3.1, it means 'limited by EKU' > * in section 5.3 it means 'limited by EKU and name constraints' > > The BRs already define a

Re: Applicability of SHA-1 Policy to Timestamping CAs

On 25/03/2019 23:42, Wayne Thayer wrote: > My general sense is that we should be doing more to discourage the use of > SHA-1 rather than less. I've just filed an issue [1] to consider a ban on > SHA-1 S/MIME certificates in the future. > > On Mon, Mar 25, 2019 at 10:54 AM Jak

Re: GRCA Incident: BR Compliance and Document Signing Certificates

On 25/03/2019 22:29, Matthew Hardeman wrote: On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: While it may be true that the certificates in question do not contain SANs, unfortunately, the certificates may still be trusted for

Re: Applicability of SHA-1 Policy to Timestamping CAs

On 23/03/2019 02:03, Wayne Thayer wrote: > On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen wrote: > >> >> >> On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> I've been asked if the section 5.1.1 restrictions on SHA-1

Re: CFCA certificate with invalid domain

On 18/03/2019 02:05, Nick Lamb wrote: On Fri, 15 Mar 2019 19:41:58 -0400 Jonathan Rudenberg via dev-security-policy wrote: I've noted this on a similar bug and asked for details: https://bugzilla.mozilla.org/show_bug.cgi?id=1524733 I can't say that this pattern gives me any confidence that

Re: A modest proposal for a better BR 7.1

On 09/03/2019 03:43, Matthew Hardeman wrote: > I know this isn't the place to bring a BR ballot, but I'm not presently a > participant there. > > I present alternative language along with notes and rationale which, I put > forth, would have resulted in a far better outcome for the ecosystem than

Re: The current and future role of national CAs in the root program

On 08/03/2019 06:27, Peter Bowen wrote: ... Mozilla has specifically chosen to not distinguish between "government CAs", "national CAs", "commercial CAs", "global CAs", etc. The same rules apply to every CA in the program. Therefore, the "national or other affiliation" is not something that

Re: The current and future role of national CAs in the root program

On 07/03/2019 23:02, Ryan Sleevi wrote: Do you believe there is new information or insight you’re providing from the last time this was discussed and decided? For example:

The current and future role of national CAs in the root program

Currently the Mozilla root program contains a large number of roots that are apparently single-nation CA programs serving their local community almost exclusively, including by providing certificates that they can use to serve content with the rest of the world. For purposes of this, I define

EJBCA defaulting to 63 bit serial numbers

In the cause of the other discussion it was revealed that EJBCA by PrimeKey has apparently: 1. Made serial numbers with 63 bits of entropy the default. Which is not in compliance with the BRs for globally trusted CAs and SubCAs. 2. Mislead CAs to believe this setting actually provided 64

General issues that came up in the DarkMatter discussion(s)

This thread is intended to be a catalog of general issues that come/came up at various points in the DarkMatter discussions, but which are not about DarkMatter specifically. Each response in this thread should have a subject line of the single issue it discusses and should not mention

Re: DarkMatter Concerns

On 05/03/2019 16:11, Benjamin Gabriel wrote: Message Body (2 of 2) [... continued ..] Dear Wayne > ... Yours sincerely, Benjamin Gabriel General Counsel DarkMatter Group As an outside member of this community (not employed by Mozilla or any public CA), I would like to state the

Re: Public CA:certs with unregistered FQDN mis-issuance

On 28/02/2019 17:48, lcchen.ci...@gmail.com wrote: 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. Ans:

Re: Possible DigiCert in-addr.arpa Mis-issuance

On 01/03/2019 01:04, Matthew Hardeman wrote: > In addition to the GDPR concerns over WHOIS and RDAP data, reliance upon > these data sources has a crucial differentiation from other domain > validation methods. > > Specifically, the WHOIS/RDAP data sources are entirely "off-path" with > respect

Re: T-Systems invalid SANs

On 27/02/2019 09:54, michel.lebihan2...@gmail.com wrote: I also found that certificates that were issued very recently have duplicate SANs: https://crt.sh/?id=1231853308=cablint,x509lint,zlint https://crt.sh/?id=1226557113=cablint,x509lint,zlint

Re: CA ownership checking [DarkMatter Concerns]

On 27/02/2019 01:31, Matthew Hardeman wrote: > I'd like to take a moment to point out that determination of the beneficial > ownership of business of various sorts (including CAs) can, in quite a > number of jurisdictions, be difficult to impossible (short of initiating > adverse legal

Re: Possible DigiCert in-addr.arpa Mis-issuance

On 27/02/2019 00:10, Matthew Hardeman wrote: Is it even proper to have a SAN dnsName in in-addr.arpa ever? While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it rarely has anything other than PTR and NS records defined. While there is no current use, and the test below was

Re: DarkMatter Concerns

On 25/02/2019 11:42, Scott Rea wrote: G’day Paul, I cannot speak for other CAs, I can only surmise what another CA that is as risk intolerant as we are might do. For us, we will collision test since there is some probability of a collision and the test is the only way to completely mitigate

Re: Firefox Revocation Documentation

On 20/02/2019 00:40, Wayne Thayer wrote: I have replaced some outdated information on Mozilla's wiki about revocation checking [1] [2] with a new page on the wiki describing how Firefox currently performs revocation checking on TLS certificates:

Re: Blog: Why Does Mozilla Maintain Our Own Root Certificate Store?

On 19/02/2019 04:04, Ryan Sleevi wrote: > On Mon, Feb 18, 2019 at 4:59 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 14/02/2019 23:31, Wayne Thayer wrote: >>> This may be of interest: >>> >>> >

Re: Blog: Why Does Mozilla Maintain Our Own Root Certificate Store?

On 14/02/2019 23:31, Wayne Thayer wrote: This may be of interest: https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ Nice write up. Two points only briefly covered: - Because many open source OS distributions use the Mozilla root store,

Re: Certificate issued with OU > 64

On 15/02/2019 19:33, Ryan Sleevi wrote: > On Fri, Feb 15, 2019 at 12:01 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Indeed, the report states that the bug was in the pre-issuance checking >> software. >> &g

Re: Certificate issued with OU > 64

On 15/02/2019 15:21, Ryan Sleevi wrote: (Sending from the right e-mail) On Fri, Feb 15, 2019 at 8:05 AM info--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Hi, this is the incident report: 1. How your CA first became aware of the problem (e.g. via a problem

Re: P-384 and ecdsa-with-SHA512: is it allowed?

On 10/02/2019 02:55, Corey Bonnell wrote: > Hello, > Section 5.1 of the Mozilla Root Store Policy > (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) > specifies the allowed set of key and signature algorithms for roots and > certificates that chain to roots

Re: GoDaddy Underscore Revocation Disclosure

On 09/02/2019 01:36, Santhan Raj wrote: On Friday, February 8, 2019 at 4:09:32 PM UTC-8, Joanna Fox wrote: I agree on the surface this bug appears to be the same, but the root cause is a different. The issue for bug 1462844 was a specific status not counting as active when it was. To mitigate

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

On 25/01/2019 19:23, Buschart, Rufus wrote: Hello Jakob! -Ursprüngliche Nachricht- Von: dev-security-policy Im Auftrag von Jakob Bohm via dev-security-policy Gesendet: Freitag, 25. Januar 2019 18:47 Example, if the subscriber fills out the human readable order form like

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

On 25/01/2019 16:06, Tim Hollebeek wrote: > >> 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

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

On 18/01/2019 19:21, piotr.grabow...@kir.pl wrote: W dniu piątek, 18 stycznia 2019 18:44:23 UTC+1 użytkownik Jakob Bohm napisał: On 17/01/2019 21:12, Wayne Thayer wrote: Hello Piotr, On Thu, Jan 17, 2019 at 6:23 AM Grabowski Piotr wrote: Hello Wayne, I am very sorry for the delay.

  1   2   3   4   5   >