Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Thu, Feb 23, 2017 at 01:55:40AM -0800, Nick Lamb via dev-security-policy wrote: > 1. Neither registries nor registrars in the DNS system would ordinarily > have control over the existence of sub-domains. In some cases the whole > _purpose_ of the registration is to create such sub-domains

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Fri, Feb 24, 2017 at 01:12:38AM +, Richard Wang via dev-security-policy wrote: > I am sure this site: https://www.microsoftonline.us.com/ is a phishing site > and a fade office 365 site that I wish LE can revoke this cert. Why? It works just fine over HTTP, too. - Matt

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Fri, Feb 24, 2017 at 03:09:10AM +, Richard Wang via dev-security-policy wrote: > Do you think this site is an authentic site from Microsoft? > If it is a fake site, then CA should revoke the issued certificate. Why? - Matt ___

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Thu, Feb 23, 2017 at 03:55:43AM +, Richard Wang via dev-security-policy wrote: > If "apple", "google", "Microsoft" is not a high risk domain, then I don’t > know which domain is high risk domain, maybe only "github". That's kinda the problem: you don't know, and neither does anyone else,

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Thu, Feb 23, 2017 at 01:08:49AM +, Richard Wang via dev-security-policy wrote: > I think "apple-id-2.com" is a high risk domain that must be blocked to issue > DV SSL to those domains. Why? > Here is the list of some high risk domains related to Microsoft and Google > that Let's

Re: GlobalSign BR violation

On Sat, Feb 25, 2017 at 11:22:18AM -0800, Roland Bracewell Shoemaker via dev-security-policy wrote: > It appears GlobalSign has issued an EV certificate containing dNSNames > which include spaces which are non-valid DNS characters. This is a > violation of CABF Baseline Regulations Sections

Re: Symantec Response R

On Mon, Apr 10, 2017 at 02:57:41PM +, Steve Medin via dev-security-policy wrote: > In April 2015, security consultant Chris Byrne responsibly disclosed two > potential vulnerabilities related to our Quick Invite feature, which > enables a reseller to invite pre-selected customers to enroll

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

On Thu, Apr 20, 2017 at 02:02:59PM +0100, Gervase Markham via dev-security-policy wrote: > I propose this section be removed from the document. My name is Matt Palmer, and I endorse this proposal. - Matt ___ dev-security-policy mailing list

Re: StartCom cross-signs disclosed by Certinomis

On Wed, Aug 02, 2017 at 06:38:44PM -0400, Jonathan Rudenberg via dev-security-policy wrote: > I think the correct response is to add both intermediates to OneCRL > immediately, especially given the historic issues with StartCom. +1. Also a strongly worded letter of "are you f%*king kidding

Re: StartCom cross-signs disclosed by Certinomis

On Thu, Aug 03, 2017 at 11:20:19AM +, Inigo Barreira via dev-security-policy wrote: > We´re revoking all those unrevoked certs to avoid any more problems. Revoking problematic certificates doesn't avoid any problems. The problems have already been created. > Regarding the pre-certs, yes, I

Re: StartCom cross-signs disclosed by Certinomis

On Thu, Aug 03, 2017 at 08:47:17AM +, Inigo Barreira via dev-security-policy wrote: > And what I don´t understand are those comments of "very sloppy isuance > practices" , "many non-BR compliants", "specially given the historic issues > with StartCom" and consider them very unfair. These are

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Thu, Aug 03, 2017 at 02:38:33PM +, Ben Wilson via dev-security-policy wrote: > Here is the response from Intesa Sanpaolo concerning the disruption that > revocation will cause to their banking operations: [...] > Concerning the CA revocation, first of all, I want to underline that for us

Re: StartCom cross-signs disclosed by Certinomis

On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via dev-security-policy wrote: > However, I think it is fine for Certinomis to cross-sign with new StartCom > subCA certs, as long as Certinomis ensures that Mozilla's Root Store > Policy is being followed. ... which they didn't. So

Re: StartCom cross-signs disclosed by Certinomis

On Thu, Aug 03, 2017 at 05:27:03PM -0700, Kathleen Wilson via dev-security-policy wrote: > Along this line of discussion, I have not felt comfortable with StartCom's > current root inclusion request (bug #1381406), because Hanno raised a > concern about the private key used by the new root is

Re: Certificates with invalidly long serial numbers

On Wed, Aug 09, 2017 at 04:21:19PM +0200, Jakob Bohm via dev-security-policy wrote: > On 08/08/2017 20:46, Alex Gaynor wrote: > > It's from the BRs 4.9.1.1: > > > > The CA SHALL revoke a Certificate within 24 hours if one or more of > > the following occurs: > > > > It's also not a

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Fri, Aug 11, 2017 at 06:32:11PM +0200, Kurt Roeckx via dev-security-policy wrote: > 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>

Re: WoSign new system passed Cure 53 system security audit

On Fri, Jul 07, 2017 at 06:12:58AM +, Danny 吴熠 via dev-security-policy wrote: > As per requirements, WoSign new issuing infrastructure has been completed > and passed the Cure 53 white box security audit successfully in June 27. > Cure53 is approved by Mozilla. The full audit report has

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

On Fri, Apr 21, 2017 at 02:12:51AM -0700, Nick Lamb via dev-security-policy wrote: > On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham wrote: > > I propose this section be removed from the document. > > I am not so sure the section ought to be removed. Wildcard DV is > potentially

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

On Fri, Apr 21, 2017 at 04:09:57AM -0700, Nick Lamb via dev-security-policy wrote: > Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate for > verifying that the applicant controls the entire domain and thus > *.example.com, whereas say 3.2.2.4.6 proves only that the applicant >

Re: Certificates with less than 64 bits of entropy

On Fri, Aug 18, 2017 at 04:04:48PM +, Stephen Davidson via dev-security-policy wrote: > Siemens has previously indicated that the affected certificates are > installed on high profile websites and infrastructure for Siemen’s group > companies around the world, and that a rushed revocation

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via dev-security-policy wrote: > If you should find such an issue again in a Cisco owned domain, please > report it to ps...@cisco.com and we will ensure that prompt and proper > actions are taken. I don't know, this way seems to have

Re: On remedies for CAs behaving badly

On Mon, Jun 05, 2017 at 08:25:22PM -0500, Peter Kurrasch via dev-security-policy wrote: >Consider, too, that removing trust from a CA has an economic sanction >built-in: loss of business. For many CA's I imagine that serves as >motivation enough for good behavior but others...possibly

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 02, 2017 at 09:54:55AM -0400, Ryan Sleevi via dev-security-policy wrote: > The general principle I was trying to capture was one of "Only sign these > defined structures, and only do so in a manner conforming to their > appropriate encoding, and only do so after validating all the

Re: New undisclosed intermediates

On Tue, Jun 06, 2017 at 10:13:20AM +0100, Gervase Markham via dev-security-policy wrote: > Aside from taking a note of how often this happens and it perhaps > appearing in a future CA investigation as part of evidence of > incompetence, does anyone else have ideas about how we can further >

Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

On Mon, Oct 16, 2017 at 09:14:29PM +0100, Rob Stradling via dev-security-policy wrote: > On 16/10/17 20:01, Matthew Hardeman via dev-security-policy wrote: > > The authors of the paper on the weak RSA keys generated by Infineon TPMs > > and smart cards have published code in multiple languages /

Re: On the value of EV

On Fri, Dec 15, 2017 at 10:30:41PM +, Tim Shirley via dev-security-policy wrote: > I’m saying “can” be spoofed is different than “is” being spoofed. How do you know your bank's EV UI element has never been spoofed? Have you, every single time you've made an HTTPS request to your bank's

Re: On the value of EV

On Fri, Dec 15, 2017 at 02:40:30PM -0800, Matthew Hardeman via dev-security-policy wrote: > On Friday, December 15, 2017 at 3:51:48 PM UTC-6, Ryan Sleevi wrote: > > Yes, we can say correlated variables are correlated. > > No, we cannot imply or infer from correlated variables that there is a > >

Re: On the value of EV

On Fri, Dec 15, 2017 at 08:34:37AM +0100, Jakob Bohm via dev-security-policy wrote: > YOU in particularly have kept insisting that it is a "myth" that > phishing sites don't use EV certificates, yet keep pointing to articles > about non-EV failures. As the Wikipedians say, "Citation Needed". I

Re: On the value of EV

On Thu, Dec 14, 2017 at 12:21:12AM +, Tim Hollebeek via dev-security-policy wrote: > If you look at the phishing data feeds and correlate them with EV > certificates, > you'll find out that Tim's "speculation" is right. Ladies and gentlemen, this evening, for your viewing pleasure, the

Re: On the value of EV

On Wed, Dec 13, 2017 at 05:58:38PM +, Tim Shirley via dev-security-policy wrote: > So many of the arguments made here, such as this one, as well as the > recent demonstrations that helped start this thread, focus on edge cases. > And while those are certainly valuable to consider, they

Re: On the value of EV

On Wed, Dec 13, 2017 at 01:40:35PM -0800, Matthew Hardeman via dev-security-policy wrote: > I'm not sure we need namespace separation for EV versus non-EV subresouces. > > The cause for this is simple: > > It is the main page resource at the root of the document which causes each > sub-resource

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

On Wed, Jan 10, 2018 at 05:24:41PM +, Gervase Markham via dev-security-policy wrote: > On 10/01/18 17:04, Matthew Hardeman wrote: > > That seems remarkably deficient. No other validation mechanism which is > > accepted by the community relies upon specific preventative behavior by any > >

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

On Fri, Jan 12, 2018 at 02:52:54PM +, Doug Beattie via dev-security-policy wrote: > I’d like to follow up on our investigation and provide the community with > some more information about how we use Method 9. > > 1) Client requests a test certificate for a domain (only one FQDN) Does

Re: DEFCON Talk - Lost and Found Certificates

On Mon, Aug 20, 2018 at 05:28:15PM -0700, Michael Casadevall via dev-security-policy wrote: > On 08/19/2018 12:56 PM, Eric Mill via dev-security-policy wrote: > > The trend is away from manual replacement, not towards it -- and that's > > true for individual people, for large enterprises, and for

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

On Tue, Sep 11, 2018 at 12:34:34AM -0700, josselin.allemandou--- via dev-security-policy wrote: > This failure is related to our old practices that led to a control of the > DNS CAA records with automatic alerts for the Registration Officers, but > the blocking of the certificate request was not

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

On Tue, Sep 11, 2018 at 07:22:18AM -0700, josselin.allemandou--- via dev-security-policy wrote: > It is important to remember that our CA is also subject to compliance with > national standards (e.g. RGS) which are more stringent for some controls > than ETSI standards or BRs. These standards

Re: Process of including ca root in mozilla

On Thu, Mar 08, 2018 at 12:42:13PM -0800, Anis via dev-security-policy wrote: > why not put a single recognition platform for all this will save time What did Microsoft and Apple say when you pitched this obviously very well thought-out and detailed proposal to them? If you want a single

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

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: > > > > Following the discussion

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

On Thu, Apr 12, 2018 at 02:15:02PM -0500, Matthew Hardeman via dev-security-policy wrote: > On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill wrote: > > But he did not deceive users. Demonstrating that this is possible is not > > itself an act of deception. > > Except that if he

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

On Fri, Apr 13, 2018 at 12:39:27AM +, Tim Hollebeek via dev-security-policy wrote: > > Independent of EV, the BRs require that a CA maintain a High Risk > Certificate > > Request policy such that certificate requests are scrubbed against an > internal > > database or other resources of the

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

On Fri, Apr 20, 2018 at 01:30:49PM +, Tim Shirley via dev-security-policy wrote: > This is why I'm not a fan of such precise enforcements of date-related > compliance. There are a lot of different ways to interpret dates/times, > but none of the readings materially change the net effect of

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

On Tue, Apr 03, 2018 at 05:19:32AM -0700, ramirommunoz--- via dev-security-policy wrote: > Completely agree with you about that a new root by itself do not solve the > problem. The phrase you're looking for is "necessary but not sufficient". That is, it is necessary to create new roots to

Re: 825 days success and future progress!

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 workaround for the browsers

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

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: > > Following the discussion on > > https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394 > > > > What is the position of Mozilla about the

Re: Mis-issuance of certificate with https in CN/SAN

On Fri, Mar 16, 2018 at 04:28:10AM +, Ben Wilson via dev-security-policy wrote: > 7. List of steps your CA is taking to resolve the situation and ensure > such issuance will not be repeated in the future, accompanied with a > timeline of when your CA expects to accomplish these things. > >

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

On Thu, Oct 11, 2018 at 01:06:46PM -0700, Wayne Thayer via dev-security-policy wrote: > * The CPS allows “external issuing CAs” but does not clearly state that the > requirements of BR section 1.3.2 will be met. emSign made the following > comment in response to this concern: “In the CP/CPS,

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

On Thu, Oct 11, 2018 at 02:36:18PM -0700, Wayne Thayer via dev-security-policy wrote: > Nick - I expect an emSign representative to respond to all of your > questions, but their information request indicates that they have been > operating the Indian Government Root for more than 10 years and

Re: Violation report - Comodo CA certificates revocation delays

On Thu, Oct 11, 2018 at 11:19:18PM +, please please via dev-security-policy wrote: > I was under the impression that CAs were allowed to remove CRL entries and > OCSP support for expired certificates for some reason. Good to know! CT logs are not CRLs or OCSP responders, nor do they track

Re: Identrust Commercial Root CA 1 EV Request

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 certificate contained internal

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

On Thu, Oct 18, 2018 at 03:44:44PM -0700, Kathleen Wilson via dev-security-policy wrote: > I think that a blank section means the same thing as "No stipulation". > Should we require that sections not be left blank? I think that for the avoidance of any sort of doubt or confusion, it would be

Re: Identrust Commercial Root CA 1 EV Request

On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via dev-security-policy wrote: > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, 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

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

On Wed, Sep 26, 2018 at 07:36:57AM -0700, josselin.allemandou--- via dev-security-policy wrote: > Thank you for your exchanges. We hope that the additions below will answer > your questions. It appears that your response has removed most indications of what parts of your message are my

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

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: > > Thank you for this clear statement of your validation interface design. > > Unfortu

Re: Underscore characters

On Thu, Dec 27, 2018 at 11:56:41PM +, Jeremy Rowley via dev-security-policy wrote: > The risk is primarily outages of major sites across the web, including > certs used in Google wallet. We’re thinking that is a less than desirable > result, but we weren’t sure how the Mozilla community

Re: Underscore characters

On Thu, Dec 27, 2018 at 01:19:26PM -0800, Peter Bowen via dev-security-policy wrote: > I don't see how this follows. DigiCert has made it clear they are able to > technically revoke these certificates and presumably are contractually able > to revoke them as well. What is being said is that

Re: Underscore characters

On Fri, Dec 28, 2018 at 03:19:19AM +, Jeremy Rowley via dev-security-policy wrote: > > I'm not sure I'd call it "leniency", but I think you're definitely asking > > for "special treatment" -- pre-judgment on a potential incident so you can > > decide whether or not it's worth it (to

Re: Underscore characters

On Fri, Dec 28, 2018 at 12:12:03AM +, Jeremy Rowley via dev-security-policy wrote: > This is very helpful. If I had those two options, we'd just revoke all the > certs, screw outages. Unfortunately, the options are much broader than that. > If I could know what the risk v. benefit is, then

Re: Underscore domains?

On Sat, Dec 29, 2018 at 02:40:10PM -0800, Lewis Resmond via dev-security-policy wrote: > I am not 100% sure, but I have read that underscores can exist in domain > names: > https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it Correct, but irrelevant

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

On Sat, Dec 29, 2018 at 06:26:09PM -0500, Lee via dev-security-policy wrote: > On 12/29/18, Ryan Sleevi wrote: > > On Sat, Dec 29, 2018 at 10:24 AM Lee wrote: > > > >> > It does not seem like a productive discussion will emerge if the > >> > ontology > >> > is going to be honest/dishonest

Re: Request to Include Hongkong Post Root CA 3

On Mon, Jan 14, 2019 at 05:18:18PM -0700, Wayne Thayer via dev-security-policy wrote: > * Fairly recent misissuance under the currently included Hong Kong Post > Root CA 1: O and OU fields too long [4]. These certificates have all been > revoked, but no incident report was ever filed. I think

Online exposed keys database

Hi all, I'd like to make everyone aware of a service I've just stood up, called pwnedkeys.com. It's intended to serve as a clearinghouse of known-exposed private keys, so that services that accept public keys from external entities (such as -- relevant to mdsp's interests -- CAs) can make one

Re: Underscore characters

On Thu, Dec 20, 2018 at 10:34:21PM +, Jeremy Rowley via dev-security-policy wrote: > Here’s the first of the companies. Figured I’d do one and see if it has the > information you want. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1515788 Complete side-note: when the customer said you

Re: Underscore domains?

On Fri, Dec 21, 2018 at 06:14:19PM -0800, Lewis Resmond via dev-security-policy wrote: > I have read the debate about the underscores and I understand that they were > never intended in the RFC. > But I wonder, does it now mean that people who have a domain name with > underscore will never be

Re: Underscore characters

On Wed, Dec 26, 2018 at 04:13:40PM +, Jeremy Rowley via dev-security-policy wrote: > The trust stores are always free to ignore the CAB Forum mandates and make > their own rules. Mozilla has in the past (see the Mozilla audit > criteria). Whilst the trust stores *can* make their own rules,

Re: Underscore characters

On Wed, Dec 26, 2018 at 06:02:57PM +, Jeremy Rowley via dev-security-policy wrote: > Much better to treat this question as “We know X is going to happen. > What’s the best way to mitigate the concerns of the community?” Exception > was the wrong word in my original post. I should have used

Re: Online exposed keys database

Hmm, Rob's reply never made it to my inbox. I'll reply to that separately now I know it's a thing. On Thu, Dec 27, 2018 at 05:56:08PM +0900, Hector Martin 'marcan' via dev-security-policy wrote: > On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote: > > I'm wondering how I might

Re: Online exposed keys database

On Wed, 19 Dec 2018 05:09:11 -0600, Rob Stradling wrote: > How do you handle malformed SPKIs? (e.g., the algorithm parameters > field for an RSA public key is missing, whereas it should be present and > should contain an ASN.1 NULL). > > Presumably your server/database only deals with

Re: SSL private key for *.alipcsec.com embedded in PC client executables

On Tue, Dec 11, 2018 at 05:37:41AM +, Xiaoyin Liu via dev-security-policy wrote: > It’s clear that the private key for *.alipcsec.com is embedded in the > executable, There are ways of implementing SSL such that the private key doesn't *have* to be stored locally. They all require the TLS

Re: SSL private key for *.alipcsec.com embedded in PC client executables

On Tue, Dec 11, 2018 at 08:00:59AM +, Jeremy Rowley via dev-security-policy wrote: > I think pretty much every ca will accept a signed file in lieu of an > actual key. You'd rather hope so. If there are any CAs out there who *wouldn't* accept a signature from the private key as proof of

Re: CA Communication: Underscores in dNSNames

On Fri, Dec 07, 2018 at 08:13:24AM -0800, pilgrim2223--- via dev-security-policy wrote: > As a retail organization we are in a moratorium till 1/2/2019 this happens > every year. So nothing is being done that may jeopardize selling of > widgets! Choosing to not do something is, itself, doing

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

On Sun, Sep 16, 2018 at 03:07:44PM -0700, josselin.allemandou--- via dev-security-policy wrote: > > 1. Can you explain in more detail the user experience of the RA interface > > which was used to misissue this certificate? Specifically, did approval > > of the issuance in the face of a CAA

Re: Online exposed keys database

Hi Ryan, On Tue, Dec 18, 2018 at 08:24:48PM -0800, Ryan Hurst via dev-security-policy wrote: > My first thought is by using SPKI you have limited the service > unnecessarily to X.509 related keys, I imagined something like this > covering PGP, JWT as well as other formats. It would be nice to

Re: Online exposed keys database

On Wed, Dec 19, 2018 at 11:30:47AM +0100, Kurt Roeckx via dev-security-policy wrote: > I'm not sure how you feel about listing keys where you don't have the > private key for, but are known to be compromised anyway. One potential > source for such information might be CRLs where the reason for

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 times. > > I'm also

Re: Underscore characters

On Wed, Dec 19, 2018 at 05:20:59PM +, Jeremy Rowley via dev-security-policy wrote: > One of the big factors should be the risk to the industry/community if the > certificates aren’t revoked. Perhaps we can identify what the risk to the > community is in revocation delays first? There’s no

Re: CFCA certificate with invalid domain

On Mon, Mar 25, 2019 at 12:05:44AM -0700, jonathansshn--- via dev-security-policy wrote: > 在 2019年2月27日星期三 UTC+8下午11:28:00，michel.le...@gmail.com写道： > > I noticed this certificate > > https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an > > invalid domain `mail.xinhua08.con` in SANs.

Re: DarkMatter Concerns

On Mon, Feb 25, 2019 at 02:11:40AM +, Scott Rea via dev-security-policy wrote: > My anticipation is that what happens is that CSPRNG process is repeated > until a positive INTEGER is returned. In which case a 64-bit output from > a CSPRNG is contained in the serialNumber as is required.

Re: DarkMatter Concerns

On Thu, Mar 07, 2019 at 05:17:07AM +, Benjamin Gabriel via dev-security-policy wrote: > On Wednesday, March 6, 2019 7:51 PM, Ryan Sleevi wrote:> > >DarkMatter response to the serial number issue has demonstrated > >that DarkMatter did not do the expected due diligence to investigate >

Re: A modest proposal for a better BR 7.1

On Fri, Mar 08, 2019 at 08:43:49PM -0600, Matthew Hardeman via dev-security-policy wrote: > I know this isn't the place to bring a BR ballot, but I'm not presently a > participant there. My understanding is that discussing potential BR changes here is actively counter-productive, because of

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

On Fri, Mar 08, 2019 at 09:35:21PM +, Jeremy Rowley via > dev-security-policy wrote: If they need some help with large scale > replacement, I know some people who did that recently. Joking of > course, but really - with Godaddy, Google, and Apple reporting a large > number of certs that have

Re: EJBCA defaulting to 63 bit serial numbers

On Thu, Mar 07, 2019 at 08:47:46PM -0600, Matthew Hardeman via dev-security-policy wrote: > On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > Past analysis and discussion have shown the interpretation is hardly > > specific to

Re: DarkMatter Concerns

On Wed, Mar 06, 2019 at 08:56:47PM -0800, astronut--- via dev-security-policy wrote: > Setting aside the discussion about DarkMatter specifically, here are some > ways in which having a CA in a new jurisdiction that isn't currently > represented in the ecosystem can bring value: > > * Allow users

Re: DarkMatter Concerns

On Thu, Mar 07, 2019 at 10:20:34AM -0600, Matthew Hardeman wrote: > Let's Encrypt does not quite provide certificates to everyone around the > world. They do prevent issuance to and revoke prior certificates for those > on the United States various SDN (specially designated nationals) lists. >

Re: CAA records on a CNAME

On Fri, Mar 15, 2019 at 05:40:29PM -0400, Jan Schaumann via dev-security-policy wrote: > Ryan Sleevi wrote: > > That is, an issue/issuewild parameter tag with a CA-specific property > > defined by the CA/Browser Forum (or by IETF) that detailed specific > > provisions for certain CNAMEs

Re: DarkMatter Concerns

On Thu, Mar 07, 2019 at 05:30:24PM -0600, Matthew Hardeman wrote: > On Thu, Mar 7, 2019 at 5:14 PM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > Whilst those are all good points, I don't see how any of them require the >

Re: EJBCA defaulting to 63 bit serial numbers

On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via dev-security-policy wrote: > On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > But BRs are not to be interpreted, just to be applied to the letter, > > whether it makes

Re: Extension KeyUsage in Subscriber's Certificate

On Wed, Apr 10, 2019 at 08:55:27AM +0200, Lijun Liao via dev-security-policy wrote: > Let us consider the case that the CA unsets the critical flag unintendedly, > e.g. using the default configuration. Which means there are no explizit > reasons. Is it required that the CA to create an incident

Re: CAA record checking issue

On Sat, May 11, 2019 at 08:37:53AM -0700, Han Yuwei via dev-security-policy wrote: > This raised a question: > How can CA prove they have done CAA checks or not at the time of issue? They can't, just as they can't prove they have or haven't done domain-control validation. It's up to audits,

Re: Does Heartbleed count for the purposes of BR 4.9.1.1 point 11? ("proven or demonstrated method")

On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy wrote: > If malloc() is correctly implemented, private keys are secure from > Heartbleed. So > I think it doesn't meet the criteria. Just to make sure I'm understanding you correctly, you're saying that being vulnerable

Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")

Hi everyone, In pondering ways of getting yet more keys for pwnedkeys.com, my mind turned to everyone's favourite bug, Heartbleed. Whilst hitting all the vulnerable servers and pulling their keys is eminently possible (see, as just one example, https://github.com/robertdavidgraham/heartleech), I

Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")

On Mon, May 27, 2019 at 06:06:42AM +0300, Ryan Sleevi wrote: > On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > That sounds an *awful* lot like Heartbleed: "a [...] proven method that > > exposes

Re: Certinomis Issues

On Fri, May 10, 2019 at 09:59:48AM -0700, Wayne Thayer via dev-security-policy wrote: > > On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > >> To continue to participate in the Mozilla CA program, I recommend that we > >>

Re: CAA record checking issue

On Mon, May 13, 2019 at 01:35:09AM -0700, Mike Kushner via dev-security-policy wrote: > On Monday, May 13, 2019 at 1:39:32 AM UTC+2, Matt Palmer wrote: > > On Sat, May 11, 2019 at 08:37:53AM -0700, Han Yuwei via dev-security-policy > > wrote: > > > This raised a question: > > > How can CA prove

Re: Certinomis Issues

On Mon, May 13, 2019 at 02:35:51PM -0700, fchassery--- via dev-security-policy wrote: > Issue A found its source in the good relationships between Franck and > Iñigo, who both are no more in charge; Is the only change to address Issue A the removal of Franck from a position of leadership within

Re: Certinomis Issues

On Thu, Apr 18, 2019 at 12:29:05PM -0700, Wayne Thayer via dev-security-policy wrote: > Yesterday, Andrew Ayer reported two additional misissued certificates: > > * Space in SAN, issued yesterday: > https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 I'm starting to think Certnomis really

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

On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via dev-security-policy wrote: > Okay, then I propose adding the following to section 5.2 "Forbidden and > Required Practices": > > Effective for certificates issued on or after April 1, 2020, end-entity > certificates MUST include an EKU

Re: Unretrievable CPS documents listed in CCADB

On Sat, May 04, 2019 at 11:11:43AM +, Man Ho via dev-security-policy wrote: > I could be wrong, but some browsers (IE/Chrome) seems to cache > downloaded PDF file and display the cache file if the filename is the > same. If it's true, end user may be actually reading an outdated PDF file.

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

On Wed, Apr 24, 2019 at 09:13:31AM +0300, Dimitris Zacharopoulos via dev-security-policy wrote: > I support this update but I am not sure if this is somehow linked with the > scope of the Mozilla Policy. Does this change mean that after April 1, 2020, > any Certificate that does not have an EKU

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

On Sun, Aug 18, 2019 at 09:14:52AM +0200, Paul van Brouwershaven wrote: > On Sun, 18 Aug 2019, 07:18 Matt Palmer via dev-security-policy, < > dev-security-policy@lists.mozilla.org> wrote: > > On Thu, Aug 15, 2019 at 05:58:56PM +, Doug Beattie via > > dev-security-polic

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

On Sun, Aug 18, 2019 at 01:35:55PM -0700, Daniel Marschall via dev-security-policy wrote: > Am Sonntag, 18. August 2019 07:18:56 UTC+2 schrieb Matt Palmer: > > [...] From what I can see so far, > > browser vendors aren't "ending" EV certificates, a couple of them are merely > > modifying their

  1   2   >