Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

On Thu, October 24, 2013 2:47 pm, Michael Ströder wrote: Kathleen Wilson wrote: In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI is not provided. Which CRL? Where does it come from? Though, I believe the plan is to stop checking CRL in the future...

RE: DigiCert Request to Include Renewed Roots

On Wed, January 29, 2014 10:50 am, Jeremy Rowley wrote: As outlined in the root inclusion request, we need to embed all five for fully support our community. Here's why: 1) These root certificates are used in many different systems, not just Mozilla. If Mozilla doesn't embed all of

Re: Super CAs

On Thu, February 20, 2014 9:37 am, Ruy Ramos wrote: On 02/18/2014 08:28 PM, Ryan Sleevi wrote: On Tue, February 18, 2014 5:28 am, Ruy Ramos wrote: On 02/15/2014 04:42 PM, David E. Ross wrote: I noticed in the open bug reports for adding new root certificates that several national

Re: Regarding Mozilla auditors choosen standards

On Mon, July 28, 2014 6:39 am, Wallas Smith wrote: [Please note that it has been the second time that I am trying to send this mail to the mozilla.dev.security.policy mailing list. I didn't noticed it appearing in the mailing list the first time, I guess it failed, I hope it will work this

Re: Dynamic Path Resolution in AIA CA Issuers

On Thu, July 31, 2014 4:31 pm, Ondrej Mikle wrote: This is interesting. I checked TLS 1.2 RFC 5246 whether Finished message should work this way, but I'm not sure. I think you mean that Hash(handshake_messages) should detect this, right? But it's still just hash, thus again not

Re: New wiki page on certificate revocation plans

On Fri, August 1, 2014 3:11 am, simon.zer...@gmail.com wrote: Hi, I would really like to see some hard metrics on OSCP failures and SSL/TLS setup speed issues. I use FF a lot with OSCP hard fail enabled and I don't seem to see any hard fails. In addition my SSL/TLS sessions seems to be

Re: CFCA Root Inclusion Request

On Tue, August 5, 2014 10:26 am, Kathleen Wilson wrote: On 7/29/14, 2:00 PM, Kathleen Wilson wrote: All, Thank you to those of you who have reviewed and commented on this inclusion request from CFCA. I will appreciate your opinions in response to my questions below regarding how to

Re: WebTrust BR Audit Procedures

On Wed, August 6, 2014 11:48 am, Kathleen Wilson wrote: Let's please discuss the auditor questions a little more... The auditor's statement (http://www.cfca.com.cn/file/PwC_CFCA(en).rar) says that the auditor performed the procedures according to the WebTrust for Certification Authorities

Re: New wiki page on certificate revocation plans

On Wed, August 6, 2014 11:14 pm, Sebastian Wiesinger wrote: * Richard Barnes rbar...@mozilla.com [2014-08-01 04:09]: Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and

Re: Proposal: Switch generic icon to negative feedback for non-https sites

On Sat, August 9, 2014 4:53 pm, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read

Re: Proposal: Switch generic icon to negative feedback for non-https sites

On Sun, August 10, 2014 4:06 pm, Matt Palmer wrote: On Sat, Aug 09, 2014 at 11:52:16PM -0700, Ryan Sleevi wrote: At the risk of engaging what may be trolling behaviour (non-attributable email addresses and all that good jazz), and while a point-by-point takedown is not particularly worthy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

On Sun, August 10, 2014 8:16 pm, David E. Ross wrote: I was a computer systems integrator for over 30 years. I fully understand what integrator means. In my career, sopftware integration often included dealing with secure systems and how they were made secure. That's a very... liberal...

Chromium, EV, and CT

I just wanted to alert members of this list of a discussion that has been started on Chromium's ct-policy@ mailing list regarding Chromium's policies for requiring EV certificates be logged in Certificate Transparency Logs. Ben Laurie has started a discussion at

Re: Chromium, EV, and CT

On Tue, August 12, 2014 6:49 pm, fhw...@gmail.com wrote: Does Mozilla have a stated plan to include CT in its products?  This is a separate discussion, and doesn't affect the ability of Mozilla using of CT logs to detect violations of Mozilla's inclusion policy. Obviously, CT in the client

Re: Audits of CA conformance to the BRs

On Wed, August 13, 2014 12:41 pm, Peter Bowen wrote: On Wed, Aug 13, 2014 at 11:16 AM, Kathleen Wilson kwil...@mozilla.com wrote: 2) BR point-in-time audits may not be sufficient. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

On Wed, August 13, 2014 6:14 pm, Peter Gutmann wrote: Chris Palmer pal...@google.com writes: FWIW, that's a misquote; I didn't write that. Ooops, sorry, it was posted by Patrick McManus pmcma...@mozilla.com (I used a script to try and resurrect the lost emails for re-send, I suspect

Re: Q: mixed http/https content

On Tue, August 19, 2014 3:41 pm, fhw...@gmail.com wrote: htmlheadmeta http-equiv=Content-Type content=text/plain;style body { font-family: Calibri,Slate Pro,sans-serif; color:#262626 }/style /head body data-blackberry-caret-color=#00a8dfdivWhat are the current rules or algorithms in place

Re: Wildcard cert, no intermediate

On Wed, August 20, 2014 3:18 pm, fhw...@gmail.com wrote: Hmmm... I'll just assume that all the prior to Effective Date conditions are satisfied but both the end and root certs are 2048-bit. I can't speak to how actively or widely used the cert is nor how costly it would be to replace

Re: Audits of CA conformance to the BRs

On Wed, August 20, 2014 5:17 pm, Kathleen Wilson wrote: On 8/19/14, 5:37 PM, Kathleen Wilson wrote: All, I started a new wiki page to document Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs.

Re: Wildcard cert, no intermediate

On Tue, August 26, 2014 8:09 am, fhw...@gmail.com wrote: In your rush to judgment you arrived at the wrong conclusions, Ryan. No, I really just disagree with you. No problem, though, as I'll recap my points in a bit. But first: The cert in question has as its root the

RE: Code Signing Draft

On Fri, August 29, 2014 8:04 am, Jeremy Rowley wrote: Good point. I don't think we spell it out, but I don't think anyone wants people using the same keys for both SSL and code signing. CAs are prohibited from using the same intermediate for both SSL and code signing, but we should also

Re: Short-lived certs

On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote: Some constraints: 1) Any new scheme has to work equally well with legacy browsers and enabled browsers. Sure. However, this requires a definition of legacy. 2) Ditto for legacy servers and this is actually a harder problem

Re: Indicators for high-security features

On Mon, September 22, 2014 11:23 am, Chris Palmer wrote: On Sat, Sep 20, 2014 at 1:10 AM, Anne van Kesteren ann...@annevk.nl wrote: ** Could the TACK key be the origin key? Is TACK still going anywhere? The mailing list suggests it's dead. But one could imagine it being resuscitated,

Re: Client certs

On Fri, September 26, 2014 2:39 am, Erwann Abalea wrote: Le jeudi 25 septembre 2014 14:29:04 UTC+2, Gervase Markham a écrit : A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence

Re: Client certs

On Fri, September 26, 2014 2:06 am, Gervase Markham wrote: On 25/09/14 22:33, Matt Palmer wrote: * Client certs can be invisibly stolen if a machine is compromised Well, the cert is quasi-public information, so it doesn't matter if they get stolen, invisibly or otherwise. The private

Re: Client certs

On Thu, September 25, 2014 11:18 pm, Henri Sivonen wrote: On Fri, Sep 26, 2014 at 12:33 AM, Matt Palmer mpal...@hezmatt.org wrote: On Thu, Sep 25, 2014 at 01:29:04PM +0100, Gervase Markham wrote: A question which occurred to me, and I thought I'd put before an audience of the wise: *

Re: Client certs

On Tue, September 30, 2014 5:47 pm, fhw...@gmail.com wrote: FIDO has its shortcomings, too, ‎and its users can be victims of phishing just as much as anyone else. While a discussion of FIDO is best suited for the FIDO-specific groups, I would just highlight that you're mistaken in this. You

Re: Trusted PEM distribution of Mozilla's CA bundle

On Mon, October 20, 2014 7:17 am, Anne van Kesteren wrote: On Mon, Oct 20, 2014 at 3:41 PM, Gervase Markham g...@mozilla.org wrote: Perhaps we just need to jump that gap and accept what is /de facto/ true. Yeah, as with publicsuffix.org we should own this up. I would, in fact, argue

Re: Cert spam, or certs with huge numbers of hosts.

On Thu, October 23, 2014 1:08 pm, John Nagle wrote: Examine the cert of https://www.sevendays.co;. Here's one of those certs with a huge number of unrelated hosts. This seems to be a Cloudflare legacy setup from the pre-TLS era. Unfortunately, this cert became valid on 10/09/2014. It's

Re: Organization info in certs not being properly recognized by Firefox

On Mon, October 27, 2014 12:14 am, John Nagle wrote: (Resend, after error The message could not be delivered to the following recipient:) Here's a nice example of Mozilla not fully understanding Organization information in certificates: www.facebook.com. Firefox says, for

Re: Clarification about WebTrust BR and WebTrust EV audits

On Fri, November 7, 2014 1:26 pm, Kathleen Wilson wrote: On 11/7/14, 2:07 AM, Chema López wrote: If the WebTrust EV audit criteria includes the Baseline Requirements audit criteria and, In other words, the WebTrust EV audit statement will also suffice as the WebTrust BR audit

Re: Clarification about WebTrust BR and WebTrust EV audits

On Tue, November 11, 2014 2:12 pm, Kathleen Wilson wrote: On 11/7/14, 2:51 PM, Ryan Sleevi wrote: In order for Mozilla to recognize a root as EV, it must first be recognized as a root for SSL certificate issuance. If a certificate is issued by that root as non-EV, it will still

Re: DSA certificates?

On Mon, December 22, 2014 10:00 am, Kathleen Wilson wrote: All, Should NSS and mozilla::pkix support DSA certificates? Should we add support for DSA to Mozilla's CA Certificate Policy? Background: * Currently there are no DSA roots in the NSS root store.

Re: DSA certificates?

On Mon, December 22, 2014 3:16 pm, Peter Gutmann wrote: Ryan Sleevi ryan-mozdevsecpol...@sleevi.com writes: DSA certificates are complicated due to parameter inheritance through the chain - which few get right, but which add ambiguity for path building and processing. DSA certificates

Re: Automated Audit Reminder Email Templates

On Thu, January 22, 2015 1:43 pm, Kathleen Wilson wrote: All, As you know, we've moved the CA Program data from spreadsheets into SalesForce. We are now creating a program that will be run once per month to automatically send email to CAs when audit statements are past due; meaning

Re: DSA certificates?

On Fri, January 9, 2015 12:28 pm, rashmi_tab...@symantec.com wrote: Symantec supports customer choice in algorithm selection and we have customers that take advantage of that choice today. Whether to support organizational policies that require the use of DSA or to provide an alternative

Re: Propose Removal of E-Guven root

On Thu, March 19, 2015 4:49 pm, Peter Bowen wrote: For example, based on what you reported and what I saw, the audit report should at a minimum say: E-Guven complies with the Baseline Requirements with the following qualifications: - Some certificates issued do not conform to 9.2.1 -

Re: Second Discussion of KIR S.A. Root Inclusion Request

On Tue, March 3, 2015 12:32 pm, Kathleen Wilson wrote: All, I have confirmed that KIR has made the changes listed below to their CPS and CP. CPS: http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf CP:

Re: Name Constraints

On Fri, March 6, 2015 4:26 pm, Richard Barnes wrote: Hey all, I've been doing some research on the potential benefits of adding name constraints into the Mozilla root program. I've drafted an initial proposal and put it on a wiki page: https://wiki.mozilla.org/CA:NameConstraints

Re: Name Constraints

On Mon, March 9, 2015 8:38 am, Michael Ströder wrote: Any clients which already make use of CAA RRs in DNS? Or did you mean something else with the acronym CAA? Ciao, Michael. CAA (RFC 6844) is not for clients. It's for CAs, as another way of restricting CAs authorized to issue for a

Re: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 11:26 am, Kai Engert wrote: Thoughts? I don't believe this is reasonable/responsible. For example, is it your intent to prevent Let's Encrypt from becoming cross-certified? That's the effect of this proposal. For example, is your intent to prevent Google from running

Re: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 2:50 pm, Daniel Micay wrote: There's no service disruption caused by not trusting any certs from the CA created after say, 3 weeks from now. They utterly failed to comply with numerous rules and if those policies have any real teeth behind them their time as a

Re: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 3:11 pm, Daniel Micay wrote: That's not a zero tolerance policy. It's an example of compromise where in exchange for more lenience, the CAs have to do something. You have to demonstrate that they have something to gain by showing that the policies have teeth though.

Re: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 4:44 pm, Daniel Micay wrote: They're willing to set the security standards *really low* because all that matters is market share. I can't really understand how they ended up in the position of having the dominant trust store used by FOSS projects. Debian and other

Re: 答复: Consequences of mis-issuance under CNNIC

On Wed, March 25, 2015 10:18 am, Peter Bowen wrote: E) Enable existing CNNIC-issued certificates to continue to work but block new ones. Two possible ways this could be done: 1) Code a cutoff date, and treat any certificate with a not_before date after the cutoff date as untrusted. 2)

Re: address prefixes allowed for domain control validation

On Sun, March 22, 2015 4:18 pm, Kathleen Wilson wrote: After reading this: https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html I'm thinking we need to update our wiki page:

Re: address prefixes allowed for domain control validation

On Mon, March 23, 2015 8:36 am, Kathleen Wilson wrote: Just to be clear... This is the wording copied as-is from the wiki page. I have not proposed any changes yet -- I'm looking for your input on how to update this wiki page, and I appreciate the input you all have provided so far.

Re: Consequences of mis-issuance under CNNIC

On Mon, March 23, 2015 3:47 pm, Richard Barnes wrote: Dear dev.security.policy, It has been discovered that an intermediate CA under the CNNIC root has mis-issued certificates for some Google domains. Full details can be found in blog posts by Google [0] and Mozilla [1]. We would like

Re: Consequences of mis-issuance under CNNIC

On Wed, March 25, 2015 7:52 pm, Peter Kurrasch wrote: I'm not suggesting I have a firm answer in mind, but I am saying that while we're focusing on CNNIC it doesn't seem right that the actual perpetrator suffers no consequence.  Peter, Hopefully my first reply to Kathleen's message has

Re: Policy about root cert transfers

On Fri, April 24, 2015 6:34 am, Moudrick M. Dadashov wrote: Kathleen, wouldn't be it easier to apply the transferred CA the same requirements as to any other? That means the new CA must have its operations audited under its ***fully completed transfer*** operations. The root and all

Re: Policy about root cert transfers

On Fri, April 24, 2015 8:20 am, David E. Ross wrote: 2. If the new owner is a certification authority whose root certificates already exist in the NSS database, that root will continued to be considered trusted. However, trust bits and EV status of the transferred root cannot exceed the

Re: Policy about root cert transfers

On Fri, April 24, 2015 7:52 pm, David E. Ross wrote: If a root has already been added to the NSS database, we must assume that it has undergone the Mozilla process for that inclusion. The process involves looking not only at the root but also at the certification authority; at least that

Re: LuxTrust Root Inclusion Request

On Fri, April 24, 2015 4:58 pm, kwil...@mozilla.com wrote: Other than the concerns that have been raised about CRL and OCSP, are there any further questions or comments about this request from LuxTrust to include the LuxTrust Global Root root certificate, turn on the Websites and Code

Re: Certinomis Request to Include Renewed Root

On Fri, April 24, 2015 4:45 pm, kwil...@mozilla.com wrote: The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=937589 Does anyone have questions or comments about this root renewal request from Certinomis? If not, I will close this discussion

Re: Name-constraining government CAs, or not

On Sun, May 17, 2015 6:06 pm, Peter Bowen wrote: I was assuming this discussion was based on the concept that Government CAs did not need to meet all the audit criteria. Otherwise why are we having it? Why indeed ;) As I mentioned in my reply to Eric, my own suspicion is that this

Re: Name-constraining government CAs, or not

On Mon, May 18, 2015 10:39 pm, Eric Mill wrote: You said: I disagree that we, the browsers and standards bodies of the Internet have very different leverage [over governments than corporations]. My description above wasn't to lay out the ills of the world, but to describe why the kind of

Re: Name-constraining government CAs, or not

On Fri, May 15, 2015 1:52 am, Gervase Markham wrote: On 15/05/15 00:01, Ryan Sleevi wrote: I think there's also the broader consideration of whether Mozilla's policy interests are served by promoting borders on the Internet, which David's proposal certainly does, but the broader question

Re: ODP: Re: Second Discussion of KIR S.A. Root Inclusion Request

On Fri, March 20, 2015 8:10 am, Certificates wrote: Hello, Thank you for your detailed second review. Please, find our answers below. Kathleen pointed out my original message was unclear, but I think it's fine to progress on this inclusion. While nothing prohibits OCSP nonces, I do hope

Re: Requirements for CNNIC re-application

On Tue, April 7, 2015 5:31 pm, Richard Barnes wrote: E. Require a certain amount of time to pass before CNNIC's re-inclusion request will be considered. I think this remains to be determined in relation to how Mozilla implements their stated policy of a date-based check - e.g. whether this is

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

On Fri, June 19, 2015 11:10 am, Brian Smith wrote: The current set of roots is already too big for small devices to reasonably manage, and that problem will get worse as more roots are added. Thus, small devices have to take a subset of Mozilla's/Microsoft's/Apple's roots. Without

Re: Requirements for CNNIC re-application

On Tue, May 26, 2015 10:56 pm, Matt Palmer wrote: On Tue, May 26, 2015 at 02:26:33PM -0700, Kathleen Wilson wrote: But this raises the question of whether their re-application can be for the same (currently-included) root certificates, or if it has to be for a new root certificate. In

Re: Name-constraining government CAs, or not

On Sat, May 30, 2015 2:47 pm, Brian Smith wrote: It seems reasonable to assume that governments that have publicly-trusted roots will provide essential government services from websites secured using certificates that depend on those roots staying publicly-trusted. Further, it is likely

Re: WoSign Root Renewal Request

This was explored in the past (several Japanese CAs collaborated and translated the documents), but it ended up working badly when the translations weren't following the canonical English version, and member CAs thus weren't adhering to the appropriate standards. I'll note that the issue being

Re: Question: BR requirement about structuring CPS according to RFC 3647

On Wed, October 28, 2015 1:55 am, mycho...@gmail.com wrote: > > Dear Sleevi > > First of all, I appreciate your detailed opinios and suggestions > > In terms of option B (application to only be for that of your SSL/website > CA rather than your root CA) > All CAs in CA hierarchy (including

Re: Clarify that a ccTLD is not acceptable in permittedSubtrees

On Tue, November 10, 2015 12:15 pm, Richard Barnes wrote: > I understand the impulse here, but technically, ccTLDs are under the > control of specific administrators per country: > > """ > The country code domains (for example, FR, NL, KR, > US) are each organized by an administrator

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

On Thu, November 5, 2015 12:51 pm, Charles Reiss wrote: > My impression is that Mozilla need not be explicitly notified of new > subCAs; the > disclosure may take the form of an update on the CA's website (perhaps > even just > a new version of the CPS). If so, this would seem to make it

Re: [FORGED] Name issues in public certificates

On Wed, November 18, 2015 8:56 am, Peter Bowen wrote: > On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling > wrote: > > I would also like to get clarification on if/when the underscore > > character > > may be used in each of the name types. Your report seems to flag > >

Re: Remove Roots used for only Email and CodeSigning?

On Mon, August 31, 2015 4:02 pm, Kathleen Wilson wrote: > I have always viewed my job as running the NSS root store, which has > many consumers, including (but not limited to) Mozilla Firefox. So, to > remove something like root certs that only have the email trust bit > enabled requires input

Re: Remove Roots used for only Email and CodeSigning?

On Mon, August 31, 2015 5:48 pm, Moudrick M. Dadashov wrote: > I'm afraid there seems to be a bit misinterpretation of ETSI policies: > EVCP, EVCP+, DVCP, OVCP are based on the same general requirements and > have cumulative effect: higher level (e.g. EVCP) conformance assessment > assumes

Re: Remove Roots used for only Email and CodeSigning?

On Mon, September 7, 2015 5:58 am, Gervase Markham wrote: > On 04/09/15 14:09, Phillip Hallam-Baker wrote: > > Has Mozilla stopped supporting Thunderbird? > > No. Mozilla-the-project still develops and supports Thunderbird. > > I had thought this was about code signing only, but reading back, I

Re: Remove Roots used for only Email and CodeSigning?

On Tue, September 8, 2015 11:04 am, Kurt Roeckx wrote: > As already pointed out, this is probably at least used by java on > most Linux distributions. When you say "Java", it would be helpful to clarify. Oracle/Sun operate their own root store for Java, so this presumably would be

Re: Remove Roots used for only Email and CodeSigning?

On Tue, September 8, 2015 9:13 am, Jürgen Brauckmann wrote: > Ryan, > > sorry, I don't understand you. You cannot pass an Webtrust for CAs audit > when you do the things you mentioned. There is no difference between > email/codesigning certs and TLS server certs. Juergen, The unfortunate

Re: Remove Roots used for only Email and CodeSigning?

On Tue, September 8, 2015 12:10 am, Jürgen Brauckmann wrote: > No, they would not abide to mozillas policies, because they would > violate the requirements set forth by the audit schemes. > > Juergen Hi Juergen, I fear that others using the store for S/MIME or code-signing would think the

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On Fri, October 2, 2015 11:53 am, Peter Kurrasch wrote: >One final comment: in terms of the embedded space, without publicly > vetted roots I think it's safe to say that most products will include > whatever root is necessary just to make the product work and that security > concerns might not

Re: WISeKey Root Renewal Request

On Wed, August 5, 2015 10:53 am, Kathleen Wilson wrote: WISeKey has applied to include the OISTE WISeKey Global Root GB CA root certificate, turn all all three trust bits, and enable EV treatment. This SHA-256 root cert will eventually replace WISeKey's SHA-1 root cert that was included in

Re: SSC Root Inclusion Request

On Wed, July 29, 2015 1:34 pm, Kathleen Wilson wrote: SSC has applied to include three root certificates as follows: enable the email trust bit for the “SSC GDL CA VS Root” certificate; enable the code signing and email trust bits for the “SSC GDL CA Root A” certificate; and

Re: Job: Is it OK to post a job listing in this forum?

On Friday, May 27, 2016 at 7:23:03 AM UTC-7, Peter Kurrasch wrote: > I'm opposed to allowing job postings in this forum. The focus should be > policy as that is the reason we have gathered here. > > Job postings generally are intended for people in a particular country ‎with > a particular

Re: When good certs do bad things

On Thu, May 26, 2016 at 7:40 AM, Peter Kurrasch wrote: > My suggestion is to frame the issue‎ as: What is reasonable to expect of a > CA if somebody sees bad stuff going on? How should CA's be notified? What > sort of a response is warranted and in what timeframe? What

Re: SSL Certs for Malicious Websites

On Wed, May 25, 2016 at 6:50 AM, wrote: > If I understand you correctly, you are saying that CAs should not be doing > any "internet policing" or "content policing" when they receive credible > reports their certs are being used by phishers, malware providers, etc. -- >

Re: When good certs do bad things

On Thu, May 26, 2016 at 1:58 PM, Phillip Hallam-Baker wrote: > What has encryption got to do with it? The "bad" raised was unrelated to certificates, publicly trusted or otherwise. As Nick also pointed out, a number of the "bad" is just as accomplish through other means

Re: Intermediate certificate disclosure deadline in 2 weeks

On Wed, Jun 22, 2016 at 8:21 AM, Ben Wilson wrote: > It seems to me that requiring the registration of these subordinate CAs > bloats the Salesforce database unnecessarily. We've historically been at a chronic lack of data, rather than a chronic glut. I think we should

Re: Update to phasing out SHA-1 Certs

On Mon, January 18, 2016 12:26 pm, Eric Mill wrote: > On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes > wrote: > > > ... > > > > One thing that has been proposed is to have an exception for local > > roots, > > i.e., to let non-default trust anchors continue to use SHA-1

Re: SHA-1 with 'notAfter >= 2017-1-1'

On Tue, January 19, 2016 2:56 pm, s...@gmx.ch wrote: > Hi > > We're already having some discussions about SHA-1, but I'll split this > up into a new thread. > > The initial goal of bug 942515 was to mark certs as insecure, that are > valid 'notBefore >= 2016-01-01' (means issued to use in

Re: Policy Update Proposal: Require full CP/CPS in English

On Tuesday, March 1, 2016 at 1:34:49 PM UTC-8, Varga Viktor wrote: > I just want to ask you, is not the PDS is enough for this? > > 119411-1 (319411-1) says you need publish PKI Disclosure Staetement (PDS) > 119411-2 (319411-2) refences for certificate profiles the 119412-5 > > The 119412-5

Re: More SHA-1 certs

On Thursday, March 10, 2016 at 11:07:51 PM UTC-8, Jakob Bohm wrote: > - DNS name (for https?) in CN, but not repeated as a SAN (as per PKIX). Not PKIX. It's the Baseline Requirements. > - SAN present but does not include the server name from the CN, this > might make some PKIX-based clients

Re: More SHA-1 certs

On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote: > It's also troubling that a CA may be allowed to continue issuing > non-serverAuth certs with SHA-1 from an issuer that is also used for > serverAuth certs. Again, a collision attack could be used to forge a > trusted serverAuth

[Crosspost/FYI] Name redaction in CT logs

Given the broad interests and community here, I just wanted to let everyone know that we on the Chrome team are soliciting feedback and thoughts on policies regarding name redaction (aka "hiding the DNS name") in certificates when logged via Certificate Transparency. This discussion has

Re: SSL Certs for Malicious Websites

On Friday, May 20, 2016 at 10:24:56 AM UTC-7, Andrew Ayer wrote: > In fact, Kathleen asked explicitly for what the answers "should be" in > addition to what they are, so my email was not unrelated. To be more > explicit, I think the answers to questions 3-5 should be no. The > reason why is

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Thursday, May 5, 2016 at 6:57:21 AM UTC-7, Peter Bowen wrote: > Nope, not acyclic. Already seen proof of that. Correct - the Web PKI is a distributed, directed, cyclic graph. > Consider the inverse. > > A root CA issues a CA certificate that is technically constrained > (KP=serverAuth,

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote: > Right, if the monitors are trying to identify all the valid certs, then > it's very important for them to have a full list of intermediates. Maybe > this is yet another positive use of this data set. Right, but I think the

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

On Wednesday, April 20, 2016 at 7:16:12 AM UTC-7, Kurt Roeckx wrote: > So the RFC seems to allow it to me, but a client can obviously decide > not to do it. I didn't say it wasn't allowed, merely that it was against the material advice of RFC 6125

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote: > It seems fairly dysfunctional if a single member of the CA/B Forum can > prevent a ballot from going ahead. To be clear: That is not the same as what I said. No single member can prevent a ballot going forward - but it can be

Re: SSL Certs for Malicious Websites

On Tue, May 24, 2016 at 10:25 AM, wrote: > Here's my question -- what do Google and Microsoft do with such reports? Do > they investigate and then put a site on the "bad" list, eg, for injecting > malware? If not, then no one will stop the malware site. If yes -- what

Re: Dealing with SubCAs with many nameConstraints

On Monday, August 8, 2016 at 12:47:26 PM UTC-7, S Davidson wrote: > However, I am interested in feedback from the Mozilla community, including > any experience on handling subCAs with large numbers of nameConstraints. My biggest concern relates to the re-use of the issuer name and key across

Re: Incomplete Intermediate Cert Records

On Friday, August 5, 2016 at 4:32:52 PM UTC-7, Kathleen Wilson wrote: > I am planning to have Salesforce automatically send the following email on > the second and fourth Tuesday of each month to the Primary POC for each CA > owner in the report, and have it CC the CA's email alias. Kathleen,

Re: Incomplete Intermediate Cert Records

On Saturday, August 6, 2016 at 1:21:29 AM UTC-7, Kurt Roeckx wrote: > I guess the same could go for e-mails about reminders that their > audit period is over and should put up a new audit report, at > least if they're really late. Yes, that is precisely why I mentioned it generically. I was

Re: ISRG Root Inclusion Request

On Fri, Jul 1, 2016 at 12:31 PM, Peter Kurrasch wrote: > I'm not sure I follow. Why should the inclusion process proceed before the > updates are complete? Because the concerns you have raised are not requirements of the Mozilla CA Inclusion Policy, nor do they appear to be

Re: Server certificate domain validation bug

On Monday, August 15, 2016 at 5:21:44 AM UTC-7, Hanno Böck wrote: > Would you be interested in working on a proposal on that for the > CA/B-Forum? (I'm not allowed to post there, so I can't directly > have that disucssion.) https://twitter.com/sleevi_/status/573520611139440641

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Tuesday, August 16, 2016 at 11:53:24 AM UTC-7, Kathleen Wilson wrote: > Our understanding: "The real problem here is that the issuing > certificate is using sha-1 with predictable serial numbers. ... If a > chosen-prefix attack on sha-1 were discovered... an attacker could use > this CA to

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Wednesday, August 17, 2016 at 2:53:38 AM UTC-7, ma...@certizen.com wrote: > Through our effort of sunsetting the "Hongkong Post e-Cert CA 1 - 10" for SSL > certificate, majority of SHA-1 SSL certificates will be expired by 31 Dec > 2016, remaining only a few SHA-1 SSL certificates that are

  1   2   3   4   5   6   7   8   9   10   >