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

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. Please find below our answers to Ryan's questions. Regarding the question why we didn't report this misissuance of this 1 certificate

Re: Do we need multiple name constraints on one certificate chain?

On 14/01/2019 22:54, Wayne Thayer wrote: On Mon, Jan 14, 2019 at 9:57 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Mon, Jan 14, 2019 at 11:10 AM tadahiko.ito.public--- via dev-security-policy wrote: Hi I have question for following case of

Re: P-521 Certificates

On 11/01/2019 13:04, Peter Gutmann wrote: > Jason via dev-security-policy writes: > >> I would say that the problem here would be that a child certificate can't use >> a higher cryptography level than the issuer > > Why not? If the issuer uses strong-enough crypto, what difference does it >

Re: AlwaysOnSSL web security issues

On 10/01/2019 19:00, Jeremy Rowley wrote: > A couple of thoughts: > 1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted > and operated by DigiCert. All validation, issuance, and linting is performed > by DigiCert prior to issuance. > 2) Lots of cert customers have

Re: P-521 Certificates

On 10/01/2019 15:38, Jason wrote: I would say that the problem here would be that a child certificate can't use a higher cryptography level than the issuer, this is agains good practices and, AFAIK, agains the Webtrust audit criteria. Jason Note that the only one of all these certificates

Re: P-521 Certificates

Adding some data points for use by future readers of this thread. On 08/01/2019 03:26, Corey Bonnell wrote: > (Posting in a personal capacity as I am no longer employed by Trustwave) > > Mozilla Root Store Policy section 5.1 >

Re: Yet more undisclosed intermediates

On 03/01/2019 16:46, Kurt Roeckx wrote: 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

Re: Yet more undisclosed intermediates

On 02/01/2019 23:40, Wayne Thayer wrote: > On Wed, Jan 2, 2019 at 11:32 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 02/01/2019 17:17, Wayne Thayer wrote: >>> The options to consider are: >>> 1. Conti

Re: Use cases of publicly-trusted certificates

On 30/12/2018 14:18, Nick Lamb wrote: On Thu, 27 Dec 2018 22:43:19 +0100 Jakob Bohm via dev-security-policy wrote: You must be traveling in a rather limited bubble of PKIX experts, all of whom live and breathe the reading of RFC5280. Technical people outside that bubble may have easily

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

Happy new year, On 30/12/2018 01:32, Peter Bowen wrote: > > > On Thu, Dec 27, 2018 at 8:43 PM Jakob Bohm via dev-security-policy > <mailto:dev-security-policy@lists.mozilla.org>> wrote: > > So absent a bad CA, I wonder where there is a rule that subscr

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

On 29/12/2018 15:32, Ryan Sleevi wrote: > On Fri, Dec 28, 2018 at 11:21 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >>> My guess is all CAs have something like >>> https://www.digicert.com/certificate-term

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

On 28/12/2018 19:44, Lee wrote: > On 12/27/18, Jakob Bohm via dev-security-policy > wrote: >> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead >> to fast revocation fall into a few categories / groups: > <.. snip ..> >> So absent a bad C

When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

Looking at the BRs, specifically BR 4.9.1, the reasons that can lead to fast revocation fall into a few categories / groups: (I will reference the numbered items with 24 hour limit as A#, the numbered items with 120 hour limit as B# and the numbered items in 4.9.1.2 as C#). (Some of the

Re: Use cases of publicly-trusted certificates

On 27/12/2018 18:03, Nick Lamb wrote: > On Thu, 27 Dec 2018 15:30:01 +0100 > Jakob Bohm via dev-security-policy > wrote: > >> The problem here is that the prohibition lies in a complex legal >> reading of multiple documents, similar to a situation where a court >>

Re: Use cases of publicly-trusted certificates

On 27/12/2018 17:28, Ryan Sleevi wrote: On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Yes, you are consistently mischaracterizing everything I post. My question was a refinement of the original question to the on

Re: Use cases of publicly-trusted certificates

On 27/12/2018 17:13, Jakob Bohm wrote: On 27/12/2018 17:02, Rob Stradling wrote: On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote: For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- browserWwwServerAuth" .  WWW is mentioned only in a c

Re: Use cases of publicly-trusted certificates

On 27/12/2018 17:02, Rob Stradling wrote: On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote: For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- browserWwwServerAuth" .  WWW is mentioned only in a comment under the OID definition. Hi Jakob.

Re: Use cases of publicly-trusted certificates

On 27/12/2018 16:55, Ryan Sleevi wrote: On Thu, Dec 27, 2018 at 10:41 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: He described three combined conditions to be met. You've described a situation "What if you meet two, but not three&

Re: Use cases of publicly-trusted certificates

On 27/12/2018 16:24, Ryan Sleevi wrote: > On Thu, Dec 27, 2018 at 9:34 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 26/12/2018 22:42, Peter Bowen wrote: >>> In the discussion of how to handle certain certificates

Re: Use cases of publicly-trusted certificates

On 27/12/2018 16:16, Ryan Sleevi wrote: On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not confined to Web Browsers surfing online

Re: Use cases of publicly-trusted certificates

On 26/12/2018 22:42, Peter Bowen wrote: > In the discussion of how to handle certain certificates that no longer meet > CA/Browser Forum baseline requirements, Wayne asked for the "Reason that > publicly-trusted certificates are in use" by the customers. This seems to > imply that Mozilla has an

Re: Use cases of publicly-trusted certificates

On 27/12/2018 13:39, Nick Lamb wrote: > As a relying party I read this in the context of the fact that we're > talking about names that are anyway prohibited. > The problem here is that the prohibition lies in a complex legal reading of multiple documents, similar to a situation where a court

Re: Underscore characters

On 19/12/2018 04:14, Peter Bowen wrote: > On Tue, Dec 18, 2018 at 6:52 PM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Ballot 202 failed. I’m not sure how it’s relevant other than to indicate >> there was definite disagreement about whether

Re: CA Communication: Underscores in dNSNames

On 18/12/2018 18:15, Ryan Sleevi wrote: > On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 10/12/2018 18:09, Ryan Sleevi wrote: >>> On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via

Re: CA Communication: Underscores in dNSNames

On 10/12/2018 18:09, Ryan Sleevi wrote: > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Hello! >> >> It would be helpful, if the CA/B or Mozilla could publish a document on >> its web pages to which we can redirect

Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

On 06/12/2018 12:37, Sándor dr. Szőke wrote: > 2018. december 5., szerda 20:45:25 UTC+1 időpontban Wayne Thayer a következőt > írta: >> .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>> 1./ >>> How your CA first

Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

On 05/12/2018 20:45, Wayne Thayer wrote: .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: ... > Further actions made:  Microsec modified the CISCO VPN server policy to issue the certificates only for two years in

Re: Incident report D-TRUST: syntax error in one tls certificate

On 05/12/2018 01:05, Nick Lamb wrote: > On Tue, 4 Dec 2018 14:55:47 +0100 > Jakob Bohm via dev-security-policy > wrote: > >> Oh, so you meant "CA issuance systems and protocols with explicit >> automation features" (as opposed to e.g. web server systems or >

Re: CA disclosure of revocations that exceed 5 days [Was: Re: Incident report D-TRUST: syntax error in one tls certificate]

Hello to you too. It seems that you are both misunderstanding what the proposal was. The proposal was apparently to further restrict the ability of CAs to make exceptions on their own, by requiring all such exceptions to go through the public forums where the root programs can challenge or

Re: Incident report D-TRUST: syntax error in one tls certificate

On 04/12/2018 13:36, Nick Lamb wrote: On Tue, 4 Dec 2018 07:56:12 +0100 Jakob Bohm via dev-security-policy wrote: Which systems? As far as I'm aware, any of the automated certificate issuance technologies can be used here, ACME is the one I'm most familiar with because it is going through

Re: Incident report D-TRUST: syntax error in one tls certificate

On 04/12/2018 05:38, Nick Lamb wrote: > On Tue, 4 Dec 2018 01:39:05 +0100 > Jakob Bohm via dev-security-policy > wrote: > >> A few clarifications below >> Interesting. What is that hole? > > I had assumed that you weren't aware that you could just use these >

Re: Incident report D-TRUST: syntax error in one tls certificate

A few clarifications below On 30/11/2018 10:48, Nick Lamb wrote: > On Wed, 28 Nov 2018 22:41:37 +0100 > Jakob Bohm via dev-security-policy > wrote: > >> I blame those standards for forcing every site to choose between two >> unfortunate risks, in this case either the

Re: Incident report Certum CA: Corrupted certificates

On 03/12/2018 12:06, Wojciech Trapczyński wrote: > Please find our incident report below. > > This post links to https://bugzilla.mozilla.org/show_bug.cgi?id=1511459. > > --- > > 1. How your CA first became aware of the problem (e.g. via a problem > report submitted to your Problem Reporting

Re: Incident report D-TRUST: syntax error in one tls certificate

On 27/11/2018 00:54, Ryan Sleevi wrote: > On Mon, Nov 26, 2018 at 12:12 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> 1. Having a spare certificate ready (if done with proper security, e.g. >> a separate key) from a dif

Re: Incident report D-TRUST: syntax error in one tls certificate

On 23/11/2018 16:24, Enrico Entschew wrote: > This post links to https://bugzilla.mozilla.org/show_bug.cgi?id=1509512 > > syntax error in one tls certificate > > 1. How your CA first became aware of the problem (e.g. via a problem report > submitted to your Problem Reporting Mechanism, a

Re: Incident report D-TRUST: syntax error in one tls certificate

On 26/11/2018 16:31, Nick Lamb wrote: In common with others who've responded to this report I am very skeptical about the contrast between the supposed importance of this customer's systems versus their, frankly, lackadaisical technical response. This might all seem harmless but it ends up as

Re: Questions regarding the qualifications and competency of TUVIT

Once again, you snipped most of what I wrote. Also not sure why your post has double reply marking. On 13/11/2018 18:20, Ryan Sleevi wrote: >> >> >> >> On Tue, Nov 13, 2018 at 11:26 AM Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozil

Re: Questions regarding the qualifications and competency of TUVIT

Unfortunately, you seem to be be ignoring what I wrote and talking about something else. On 13/11/2018 14:31, Ryan Sleevi wrote: > I suppose I had unreasonably hoped it would be self-evident, particularly > for someone who claims to follow the issues, to understand how directly > that issue was

Re: Questions regarding the qualifications and competency of TUVIT

On 13/11/2018 04:08, Ryan Sleevi wrote: > Jakob, > In the following, I have added a new subject category: Subject U: [T-Systems local] Issues at T-Systems, rather than issues in TUVIT's auditing of T-Systems. I will use the following number: U1: T-Systems misencoded the qc-statement

Re: Questions regarding the qualifications and competency of TUVIT

Ryan, Could you please provide, in a single message, a list of all the supposedly multiple failures by TUVIT, clearly marking each if it is: Subject O: [Other] A failure outside the specific subjects below. Subject D: [Discussion] A failure by TUVIT to satisfactorily answer your questions

Re: How harsh (in general) should Mozilla be towards CAs?

On 09/11/2018 15:52, Hanno Böck wrote: On Fri, 9 Nov 2018 14:56:41 +0100 Jakob Bohm via dev-security-policy wrote: However there are also some very harsh punishments handed out, such as distrusting some CAs (most notably happened to Symantec and WoSign, but others are also teetering

Re: How harsh (in general) should Mozilla be towards CAs?

On 09/11/2018 12:44, westmai...@gmail.com wrote: I think that punishments of the CAs for already exists in Mozilla Root Store are very mild, and some CAs often do not pay any attention to this... However there are also some very harsh punishments handed out, such as distrusting some CAs

Re: How harsh (in general) should Mozilla be towards CAs?

On 09/11/2018 07:21, Ryan Sleevi wrote: On Thu, Nov 8, 2018 at 5:51 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: This thread is for the general principles, it takes no stance on any particular cases, as that would quickly derail the discussion.

How harsh (in general) should Mozilla be towards CAs?

This thread is for the general principles, it takes no stance on any particular cases, as that would quickly derail the discussion. Over the years, there has been some variation among participants in how harshly individual mistakes by CAs should be judged, ranging from "just file a satisfactory

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

On 25/10/2018 23:10, Wayne Thayer wrote: On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Questions about blank sections, thinking of a potential future requirement. Sections such as 1.INTRODUCTION would remain blank as they

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

On 24/10/2018 00:08, Tim Hollebeek wrote: I agree with you, but December 31 is a particularly horrible compliance deadline. Perhaps January 31? Note that the requirement applies only to CP/CPS dated after that date. So it is really Dec 31 + the time until the CP/CPS is updated for some

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

On 15/10/2018 20:01, Kathleen Wilson wrote: I have added the following section to the Required Practices wiki page: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS I will continue to appreciate feedback on this update. Thanks,

Re: Identrust Commercial Root CA 1 EV Request

On 17/10/2018 01:18, Matt Palmer wrote: On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via dev-security-policy wrote: 5.Explanation about how and why the mistakes were made, and not caught and fixed earlier. IdenTrust: The certificate was generated for a server within IdenTrust. The

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

On 15/10/2018 20:01, Kathleen Wilson wrote: I have added the following section to the Required Practices wiki page: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS

Re: Violation report - Comodo CA certificates revocation delays

On 12/10/2018 20:01, Rob Stradling wrote: On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote: On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie wrote: This is one of the reasons we also need revocation transparency. As tempting as the buzzword is, and as much as we love motherhood and

Re: Violation report - Comodo CA certificates revocation delays

On 12/10/2018 14:33, Ben Laurie wrote: On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I believe that may be misunderstanding the concern. Once these certificates expire, there's not a good way to check whether or not they were

Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

Another interpretation, which would result in this situation being not a Mozilla/BR violation is this (I am /not/ saying this is a a better interpretation, just a possible one). Mozilla and BR policy requires only that: 1. The DER encoding is technically correct as if no ASN.1 module was

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

On 09/10/2018 23:15, Wayne Thayer wrote: On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Oh, so rather than trying to define what "No Stipulation" means and when it can be used, we could take a different approach -- list

Re: Yet more undisclosed intermediates [Telia]

[ Please reply to list, Mozilla NNTP<->mail gateway seems to insert wrong Reply-To ] Telia is a notable case as this seems to be a brand new Intermediary created but not disclosed 1 month ago. On 09/10/2018 12:43, Rob Stradling wrote: "ACTION 6" of Mozilla's September 2018 CA Communication [1]

Re: Yet more undisclosed intermediates [SwissSign]

[ Please reply to list, Mozilla NNTP<->mail gateway seems to insert wrong Reply-To ] It appears from the data that SwissSign has reacted to the requirement by starting to log some of their existing intermediaries in CT, instead of in CCADB. At least at a cursory glance. On 09/10/2018 12:43,

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

On 04/10/2018 19:40, Wayne Thayer wrote: On Thu, Oct 4, 2018 at 9:48 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: (In reply to Matt Palmer in message-id mailman.78.1538620059.2924.dev-security-pol...@lists.mozilla.org) I seem to recall that t

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

On 04/10/2018 04:27, Matt Palmer wrote: On Wed, Oct 03, 2018 at 09:31:08AM -0700, Wayne Thayer wrote: On Mon, Oct 1, 2018 at 4:49 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: ... ... ... Alternately, if the BRs *are*, in fact, sufficiently clear in

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

On 12/09/2018 14:51, RS Tyler Schroder wrote: On Tuesday, September 11, 2018 at 3:34:45 AM UTC-4, josselin@gmail.com wrote: The audit of our previous CAA check practices ensured that the CA/B Forum requirements were met except for a single certificate for which the CA was not authorized

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

I have numbered the new questions from 13 and up and added 7 more questions at the end. On 12/09/2018 05:11, Matt Palmer wrote: On Tue, Sep 11, 2018 at 07:22:18AM -0700, josselin.allemandou--- via dev-security-policy wrote: Snipped the 12 questions that assumed this was an RA mistake

Re: DRAFT September 2018 CA Communication

On 07/09/2018 15:55, Bruce wrote: On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer wrote: All, I've drafted a new email and survey that I hope to send to all CAs in the Mozilla program next week. it focuses on compliance with the new (2.6.1) version of our Root Store Policy. I

Re: Telia CA - problem in E validation

On 21/08/2018 16:54, Tim Hollebeek wrote: There are lots of useful ways to publish unverified and potentially inaccurate information. Putting that information into a certificate signed by a public Certificate Authority is not one of them. By the way, OUs need to be accurate as well, not just

Re: Telia CA - problem in E validation

On 20/08/2018 10:06, pekka.lahtiha...@teliasonera.com wrote: In our implementation E value in our certificates was "true" if it passed our technical and visual verification. If the BR requirement is to do "any" verification for E then the verification techniques we used should be OK. We think

Re: A vision of an entirely different WebPKI of the future...

On 16/08/2018 21:51, Matthew Hardeman wrote: Of late, there seems to be an ever increasing number of misissuances of various forms arising. Despite certificate transparency, increased use of linters, etc, it's virtually impossible to find any CA issuing in volume that hasn't committed some

Re: DEFCON Talk - Lost and Found Certificates

On 16/08/2018 16:24, Eric Mill wrote: On Wed, Aug 15, 2018 at 6:36 AM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I'd like to call this presentation to everyone's attention: Title: Lost and Found Certificates: dealing with residual certificates for

Re: DEFCON Talk - Lost and Found Certificates

On 14/08/2018 02:10, Wayne Thayer wrote: I'd like to call this presentation to everyone's attention: Title: Lost and Found Certificates: dealing with residual certificates for pre-owned domains Slide deck:

Re: Telia CA - problem in E validation

On 10/08/2018 13:02, pekka.lahtiha...@teliasonera.com wrote: On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy wrote: I want to emphasize that each and every value of certificate Subject have always been verified. It's wrong to say that those values are unverified.

Re: Possible violation of CAA by nazwa.pl

On 27/07/2018 08:46, Jakob Bohm wrote: On 26/07/2018 23:04, Matthew Hardeman wrote: On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The party actually running the authoritative DNS servers is in control of the domain. I'm

Re: Possible violation of CAA by nazwa.pl

On 26/07/2018 23:04, Matthew Hardeman wrote: On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The party actually running the authoritative DNS servers is in control of the domain. I'm not sure I agree. They can control the

Re: TeletexString

On 09/07/2018 03:31, Peter Gutmann wrote: ​Ryan Sleevi writes: Is that because you believe it forbidden by spec, or simply unwise? The spec allows almost anything, and in particular because there isn't any one definitive "spec" you can have ten incompatible interpretations that are all

Re: Namecheap refused to revoke certificate despite domain owner changed

On 01/06/2018 21:01, Wayne Thayer wrote: On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Please contact the CA again, and inform them that BR 4.9.1.1 #6 requires the CA (not some reseller) to revoke the certificate wit

Re: Namecheap refused to revoke certificate despite domain owner changed

On 01/06/2018 22:39, Joanna Fox wrote: In light of the limited visibility of WHOIS, Wayne's suggestion of "... allow anyone to revoke by proving that they control the domain name using one of the BR 3.2.2.4 methods" is preferable as it is a bit more encompassing rather than restricting to to

Re: Namecheap refused to revoke certificate despite domain owner changed

On 01/06/2018 06:22, Richard S. Leung wrote: I'm not sure if this is the appropriate place to post this topic, but I felt like this is important. I bought myself a new domain this month, and found out that there is a 3-year SSL certificate valid for my domain via crt.sh. Naturally I

Re: question about DNS CAA and S/MIME certificates

on the nature of the e-mail system involved. A company postmaster has obvious supremacy over company e-mail accounts. But a common carrier ISP postmaster should not have supremacy over their users. On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy < dev-security-pol

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

On 14/05/2018 22:53, Wayne Thayer wrote: On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??? - We can’t permit user generated passwords (at least

Re: question about DNS CAA and S/MIME certificates

Another approach could be to have something akin to the (non-ICANN) public suffix list, but for e-mail. This would list e-mail domains where the e-mail address holders are not the subordinates (employees, students, etc.) of the domain holder. Such a list would have multiple uses (just like the

Re: Unrevoked/unexpired certificate with Debian Weak Key

On 14/05/2018 10:42, Hanno Böck wrote: Hi, Yesterday was the 10y anniversary of the Debian OpenSSL random number generator bug. A few days ago I did a re-check of the CT logs for vulnerable keys. I found one unexpired, unrevoked certificate issued by a CA called "QuoVadis". I reported it and

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

On 04/05/2018 20:58, Wayne Thayer wrote: The optimist in me thinks we might be getting close to resolving this issue (the last one remaining for the 2.6 policy update). Here is another proposal that attempts to account for most of the input we've received: Add the following to section 5.2

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On 30/04/2018 18:47, Wayne Thayer wrote: On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi wrote: On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer wrote: On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi wrote: I'm not sure I underestand the

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On 25/04/2018 18:01, Quirin Scheitle wrote: Hi Jakob, As someone who has actually /removed/ DNSSEC from some domains after it caused serious ripling failures, the brokenness of DNSSEC does not come from how often DNSSEC fails to validate valid requests but from how easily DNSSEC can crash a

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On 25/04/2018 17:06, Quirin Scheitle wrote: On 25. Apr 2018, at 16:11, Matthew Hardeman via dev-security-policy wrote: With the right combination of DNSSEC validation, CAA records as utilized today, […] Hi all, I have advertised making DNSSEC

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On 20/04/2018 21:59, Wayne Thayer wrote: On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I believe the wording "insecure electronic channels" leaves a lot of space for interpretation. In corporate PKIs for email

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On 17/04/2018 20:24, Wayne Thayer wrote: This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or id-kp-emailProtection EKUs would be

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On 17/04/2018 00:13, Ryan Sleevi wrote: On Mon, Apr 16, 2018 at 3:22 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: If that CA has a practice that they actually do something about high risk names, it would still be expected (in the normal, not

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

GoDaddy has made such a claim, and we ought not put words in their mouths. Alex On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 13/04/2018 18:07, Ryan Sleevi wrote: Indeed, it was a public demonstration that they'll h

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On 13/04/2018 19:18, Ryan Sleevi wrote: On Fri, Apr 13, 2018 at 1:13 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Possible outcomes of such an investigation: 1. That CA does not consider paypal to be a high risk name. This is within their

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On 13/04/2018 18:05, Ryan Sleevi wrote: On Fri, Apr 13, 2018 at 11:53 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 13/04/2018 05:56, Ryan Sleevi wrote: On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via dev-security-policy < dev

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

emely low. There are tons more ways of using EV certs for bad purposes. James On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/04/2018 21:20, James Burton wrote: Both mine and Ian's demonstrations

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On 12/04/2018 21:20, James Burton wrote: Both mine and Ian's demonstrations never harmed or deceived anyone as they were proof of concept. The EV certs were properly validated to the EV guidelines. Both companies are legitimate. So what's the issue? None. In the security space, blocking a

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

On 06/04/2018 03:04, Matt Palmer wrote: On Thu, Apr 05, 2018 at 09:05:07PM +0200, Jakob Bohm via dev-security-policy wrote: On 04/04/2018 04:27, Matt Palmer wrote: On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via dev-security-policy wrote: On 02/04/2018 18:26, Tom Delmas wrote

Re: 825 days success and future progress!

On 04/04/2018 04:16, Matt Palmer wrote: On Tue, Apr 03, 2018 at 03:16:53AM +0200, Jakob Bohm via dev-security-policy wrote: On 03/04/2018 02:35, Kurt Roeckx wrote: 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

Re: Audits for new subCAs

On 04/04/2018 16:01, Ryan Sleevi wrote: On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 03/04/2018 14:57, Ryan Sleevi wrote: On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy < dev-securi

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On 05/04/2018 18:55, Wayne Thayer wrote: On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos wrote: My proposal is "CAs MUST NOT distribute or transfer private keys and associated certificates in PKCS#12 form through insecure physical or electronic channels " and remove

Re: Audits for new subCAs

On 03/04/2018 14:57, Ryan Sleevi wrote: On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 03/04/2018 02:15, Wayne Thayer wrote: On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < dev-securi

Re: 825 days success and future progress!

On 03/04/2018 02:35, Kurt Roeckx wrote: 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

Re: Audits for new subCAs

On 03/04/2018 02:15, Wayne Thayer wrote: On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: While Entrust happens to do this, as a relying party, I dislike frequent updates to CP/CPS documents just for such formal c

Re: 825 days success and future progress!

Furthermore in IT departments of smaller companies, setting up new automations or upgrading otherwise functioning systems to ones that include automation is much harder than it is for a mastodon like Siemens. The main arguing for ever shorter validity periods seems to come from very few

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

On 02/04/2018 18:26, Tom Delmas wrote: Following the discussion on https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394 What is the position of Mozilla about the submission to ct-logs of the final certificate when there is already a pre-certificate? As it helps

Re: Audits for new subCAs

On 29/03/2018 20:46, Wayne Thayer wrote: Thanks everyone for your input on this topic. I'm hearing consensus that we should not require a newly issued subordinate CA certificate to appear on an audit statement prior to being used to sign end-entity certificates. This is something that could be

Re: Audits for new subCAs

On 02/04/2018 17:12, Julian Inza wrote: El sábado, 31 de marzo de 2018, 3:01:29 (UTC+2), Wayne Thayer escribió: On Thu, Mar 29, 2018 at 12:55 PM, Ryan Sleevi wrote: I think, for new CAs, the KGC report and the stated CP/CPS, combined with ensuring that the next audit that

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

On 26/03/2018 22:41, Wayne Thayer wrote: Mozilla policy section 3.1.2.2 states: ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods ending in July 2017 or earlier. Now that we are past this deadline, I propose that we remove all references to ETSI TS 102 042 and 101

<    1   2   3   4   5   >