On Fri, Aug 16, 2019 at 10:03:53PM -0700, Leo Grove via dev-security-policy
wrote:
> However, as a user I support EV SSL. I personally have never come across
> a scam site that displayed an EV SSL (I'm not saying they don't exist).
> Has anyone else come across a "scam site" displaying EV that's
On Fri, Aug 16, 2019 at 03:15:39PM -0700, Daniel Marschall via
dev-security-policy wrote:
> (2) I am a pro EV person, and I do not have any financial benefit from EV
> certificates. I do not own EV certificates, instead my own websites use
> Let's Encrypt DV certificates. But when I visit import
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
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
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
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 C
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
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, ex
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
> >> requ
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.
If
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 is
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 ext
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 ar
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
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&opt=cablint,x509lint,zlint that has an
> > invalid domain `mail.xinhua08.con` in SAN
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 children.
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 intel
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 w
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
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 sen
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
&
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.
> For
On Thu, Mar 07, 2019 at 04:59:16PM +, Scott Rea via dev-security-policy
wrote:
> I am committed to a respectful dialogue, and I too (as others have already
> suggested here) would appreciate clear and definitive criteria in respect
> to what Mozilla requires to enable DM Trust Services to demo
On Thu, Mar 07, 2019 at 03:39:46AM -0800, nadim--- via dev-security-policy
wrote:
> I think we're all choosing to kid ourselves here if we continue to say
> that the underlying impetus for this discussion isn't primarily
> sociopolitical.
You're free to think whatever you like. You're *wrong*, b
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
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
>
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.
That
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 tha
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 partici
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 for
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 DigiCert
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 would
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 you
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 thei
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 correctly
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 add
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, m
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
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 a
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 c
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 ne
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 rev
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 d
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 se
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 cal
On Thu, Dec 13, 2018 at 09:50:21AM -0800, pedro.wisekey--- via
dev-security-policy wrote:
> For S/MIME capability itself, we are required to ensure that "the entity
> submitting the request controls the email account associated with the
> email address referenced in the certificate", so by merely
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 comp
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 te
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 som
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 best
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 mist
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 doma
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
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 have
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, there
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.
> > Unfortuna
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 questions
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 val
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
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 a
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
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 th
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 can't maintain a working
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 CAs
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 o
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 submission
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
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 resto
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.
>
> A
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 platform
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 t
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
> > num
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
> > c
On Fri, Dec 15, 2017 at 02:38:09PM -0800, Matthew Hardeman via
dev-security-policy wrote:
> On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote:
> > Removing it will make some users sad. Those users are relying upon the UI
> > to guarantee the things the UI does not guarantee. Remo
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 websi
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 d
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 music
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
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 obscur
On Thu, Nov 23, 2017 at 06:43:42AM +,
=?utf-8?q?Michael_von_Niederh=C3=A4usern_via_dev-security-policy_=3Cd?=@lists.mozilla.org
wrote:
> - 2.2(3) says: " The CA's CP/CPS must clearly specify the procedure(s) that
> the CA employs, and each documented procedure should state which subsection
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 /
On Thu, Oct 05, 2017 at 11:05:07AM +0800, Gervase Markham via
dev-security-policy wrote:
> In addition, we do need to address the question of how we can ascertain
> that the organization has acquired the technical competence and
> management rigour which seems to be lacking. I know you have placed
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 woul
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> wrote:
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 penalty
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 s
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
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 there
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 also
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
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 me?!?
On Thu, Jul 13, 2017 at 02:24:39AM +, Richard Wang via dev-security-policy
wrote:
> We got confirmation from Cure 53 that new system passed the full security
> audit. Please contact Cure 53 directly to verify this, thanks.
Who should we contact at Cure 53? Or should we just use the "busines
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 been
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 work
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
> incent
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
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 nece
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 probl
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
> con
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
dev-secu
101 - 200 of 210 matches
Mail list logo
