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 > >

Re: Revoking Trust in one ANSSI Certificate

On Mon, December 9, 2013 1:03 pm, Eddy Nigg wrote: > On 12/09/2013 08:09 PM, From Kathleen Wilson: > > On 12/9/13 9:42 AM, Kathleen Wilson wrote: > >> Mozilla Security Blog post: > >> > >> https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/ > >> > >> > >> > >> Goo

Re: Please Advise: What is the preferred source for 3rd parties to pull certdata.txt?

On Tue, December 17, 2013 4:13 pm, Leif W wrote: > On Tuesday, December 17, 2013 6:02:32 PM UTC-5, Michael Shuler wrote: > > Attached is my little check script that I run from cron to check for new > > Thank you! My context for pulling the certdata.txt is from within the > mk-ca-bundle.pl (or .

Re: Stop using SHA1 in certificates

On Fri, January 3, 2014 10:15 am, Kurt Roeckx wrote: > Hi, > > Microsoft has proposed to stop issueing new certificates using > SHA1 by 2016 in certificates. > > (http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx). > > Mozilla also has a bug that even suggest to s

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 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 certification authorities are actually acting as super > > CAs without complete accountability for the

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 ne

Re: Question about disclosing subCA certs

On Wed, May 21, 2014 12:12 pm, Kathleen Wilson wrote: > On 5/20/14, 9:53 AM, Rick Andrews wrote: > > Ryan, they're not, but the root is not trusted for SSL (via meta-data). > > AFAIK, Firefox won't trust any SSL cert chaining to it. Will Chrome? > > > > -Rick > > > > --

Re: Question about disclosing subCA certs

On Thu, May 22, 2014 10:44 am, Kathleen Wilson wrote: > On 5/22/14, 9:38 AM, Kurt Roeckx wrote: > > On Thu, May 22, 2014 at 08:50:02AM -0700, Kathleen Wilson wrote: > >> > >> But really, since the websites and code signing trust bits are not > >> enabled, > >> the hierarchy is already essentially

Re: Checking certificate requirements

On Wed, May 28, 2014 3:19 pm, Kathleen Wilson wrote: > On 5/25/14, 9:53 AM, Kurt Roeckx wrote: > > On Tue, May 20, 2014 at 11:23:54AM -0700, Kathleen Wilson wrote: > >> Maybe we should re-visit the idea of a "wall of shame", and publicly > >> list > >> the CAs who are still issuing certificates wi

Re: CFCA Root Inclusion Request

On Tue, June 24, 2014 3:33 am, Erwann Abalea wrote: > Le vendredi 20 juin 2014 01:20:56 UTC+2, Kathleen Wilson a écrit : > > China Financial Certification Authority (CFCA) has applied to include > > the "CFCA GT CA" and "CFCA EV ROOT" root certificates, turn on all three > > trust bits for the "CF

Re: CFCA Root Inclusion Request

On Tue, June 24, 2014 10:39 am, Kurt Roeckx wrote: > > Should we mandate that the audit should also audit the procedures? > > In my opinion the audit should: > - Check that the CPS complies with all the requirements > - Check that the CPS is being followed. Well, "Check that the CPS is being f

Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

On Thu, July 24, 2014 8:59 pm, nick.l...@lugatech.com wrote: > So, based off of the comments that have been made, please can Mozilla > support such a change? > > If not, what would Mozilla's objections be that are in scope to the > question/issue? Presently, none appear to have been articulated

RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

On Fri, July 25, 2014 10:25 am, Robin Alden wrote: > That sounds like rot to me. > > You've portrayed the suggestion that Mozilla support a change so that a > CA would be required to more distinctly express it's policy (in the > matter of whether it considered the certificate DV, OV, EV) as an

RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

On Sun, July 27, 2014 7:41 pm, Jeremy Rowley wrote: > You can tell which BR version > the cert complies with by looking at the issuance date, No. You can't. Surely you don't mean to tell me that if I go find a cert DigiCert issued last week that I can safely assume it's going to conform to BR 1

Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

On Sun, July 27, 2014 10:03 pm, nick.l...@lugatech.com wrote: > So, why not modify the BRs so that section 9.3.1 also encodes the revision > of the BRs in the OID? This is not a proliferation of OIDs and is easily > handled programmatically. Because that's now how certificate policies work. See

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 t

Re: Regarding Mozilla auditors choosen standards

On Tue, July 29, 2014 2:01 am, Wallas Smith wrote: > Thank you very much for your precise answers. This helped me to come to > new questions : Which you will find already answered at https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ , as I suspected. > > 1) Accordin

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

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

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 Author

Re: New wiki page on certificate revocation plans

On Wed, August 6, 2014 11:14 pm, Sebastian Wiesinger wrote: > * Richard Barnes [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 some may

Re: DANE (was Re: Proposal: Switch generic icon to negative feedback for non-https sites)

On Thu, August 7, 2014 4:29 pm, Phillip Hallam-Baker wrote: > That is only the case for DV certs. And it is a situation that is > hardly acceptable. > > It isn't really the case that its a permanent vulnerability either. If > a DNS registry was ever discovered to have acted as you suggest then

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 > > takedow

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 https://groups.google.com/a/chromiu

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 wo

Re: Audits of CA conformance to the BRs

On Wed, August 13, 2014 12:02 pm, David E. Ross wrote: > On 8/13/2014 11:16 AM, Kathleen Wilson wrote [in part]: > > All, > > > > As the CFCA discussion showed, there are a few things still to figure > > out regarding the audits of CA conformance to the BRs. > > > > Here are my proposals. > >

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 > 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 > > "Any Ce

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 writes: > > >FWIW, that's a misquote; I didn't write that. > > Ooops, sorry, it was posted by Patrick McManus (I > used > a script to try and resurrect the lost emails for re-send, I suspect > something > got mangled somew

Re: Q: mixed http/https content

On Tue, August 19, 2014 3:41 pm, fhw...@gmail.com wrote: > > body { font-family: "Calibri","Slate Pro","sans-serif"; color:#262626 > } What > are the current rules or algorithms in place when dealing with some > mixture of http and https content in > Firefox? A case I'm thinking about is a

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 > rep

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. > > > > https://wiki.mozilla.org/CA:Basel

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 utn-userfirst-har

Re: Allow Redaction of issues detailed in BR Audit statements?

On Tue, August 26, 2014 11:35 am, Kathleen Wilson wrote: > All, > > I am running into a problem with BR audit statements that list details > about issues that have been found. > > https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements > "...The first BR audit for each CA and s

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 al

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 pr

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 > 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, if it

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-sequenc

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. T

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 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: > >> > >> * What a

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. Yo

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 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 strongly aga

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. I

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 "http

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 a

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 ro

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. > > https://www.moz

Re: DSA certificates?

On Mon, December 22, 2014 1:09 pm, Richard Barnes wrote: > > To be clear: The current "policy" was established by the two bugs above > being landed, without discussion beyond the bugzilla thread. The point of > this thread is to verify that that policy is OK, given the potential > compat > im

Re: DSA certificates?

On Mon, December 22, 2014 3:16 pm, Peter Gutmann wrote: > Ryan Sleevi 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 c

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 > alternativ

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; > me

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

On Mon, February 9, 2015 1:08 pm, Kathleen Wilson wrote: > Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the "SZAFIR > ROOT CA" root certificate and enable all three trust bits. > > The first discussion is here: > > https://groups.google.com/d/msg/mozilla.dev.security.policy/aNb

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 Sun, March 8, 2015 11:53 am, Eric Mill wrote: > That comes down to how this program is implemented. The intent seems > pretty clearly to identify the space CAs are already issuing in. > Perhaps newer gTLDs merit some unrestrained time in the wild before > they're constrained in this way -- o

Re: Name Constraints

On Sun, March 8, 2015 2:12 pm, Eric Mill wrote: > TLDs and public suffixes like *.gov.uk, *.gouv.fr, *.gov, or *.mil -- > these are not operated openly. I know that at least in the case of > .gov, the registration process itself is centrally managed and is > effectively "organizationally valida

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: Name Constraints

On Tue, March 10, 2015 1:11 am, Martin Rublik wrote: > On 9. 3. 2015 18:11, Ryan Sleevi wrote: > > Since Ballot 125 in the CA/Browser Forum ( > > https://cabforum.org/2014/10/14/ballot-125-caa-records/ ) CAs are > > required > > to disclose how they use/process CAA

Re: Name Constraints

On Tue, March 10, 2015 11:33 am, Gervase Markham wrote: > The idea of forcibly constraining government CAs to issue for their own > TLDs is, to me, a lot more plausible. For one thing, many government CAs > don't have the same audits that non-governmental CAs do. > > The difficulty here is defi

RE: Certificate Profiles

On Mon, March 16, 2015 10:55 am, Jeremy Rowley wrote: > Not to mention, that the lack of a required OCSP URI (with a stapled > response) is something that the forum has talked about correcting a few > times. It's likely going to be required (hopefully with an exception for > short lived certs).

Re: LuxTrust Root Inclusion Request

On Thu, March 19, 2015 1:35 am, LuxTrust CA wrote: > Regarding issue #2 : OCSP responds "good" to a non-issued certificate > (serials and 00) (BR Section > 13.2.6) : > LuxTrust’s OCSP application currently does not support this feature > (technical li

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: http://elektronicznypodpis.pl/files/doc/certificat

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: Propose Removal of E-Guven root

On Thu, March 19, 2015 3:53 pm, Peter Kurrasch wrote: > There are 2 differences. First, in > the event HSTS was activated on the site there will be no chance to > override. Second, a user in that region may want to or need to activate > that root because he or she relies on the impacted websites

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: > > > https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Pr

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

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

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 it

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 tru

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 thoug

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

On Tue, March 24, 2015 3:27 pm, Kai Engert wrote: > Couldn't you get an intermediate that's constrained to the list of > domains that Google controls? And this was the part that has been repeatedly discussed on this list and in the CA/Browser Forum, and which the answer for Google (and for a lar

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. >

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: 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 h

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 i

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 a

RE: Policy about root cert transfers

On Fri, April 24, 2015 7:25 am, Ben Wilson wrote: > Kathleen, > I think we need to drill down into what is meant by "audit". Also, I > don't > think a CA who is under ongoing audit obligations should have a special > "audit" just for a root transfer. Neither should the current CA that is >

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 t

Re: Policy about root cert transfers

On Fri, April 24, 2015 8:39 am, Moudrick M. Dadashov wrote: > So I thought everybody "standing under the umbrella" is treated the same > way. My point is that they aren't, and they never have. > Cross-signing scenarios may or may not result in creation of a new CA, > probably this is the most

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 th

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 discu

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: Name-constraining government CAs, or not

On Thu, May 14, 2015 9:02 am, David E. Ross wrote: > With "cyberwarfare" constantly discussed in the news, U.S. Congress, and > other venues, it appears to me that government CAs should indeed be > restricted to the TLDs of their respective jurisdictions. > > Furthermore, since governments can

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 > >

Re: Name-constraining government CAs, or not

On Sat, May 16, 2015 4:45 pm, Eric Mill wrote: > Another factor is _why_ the government CA is applying to the trusted root > program. If the government CA only intends to issue certs for its own > properties, and its properties can reasonably be concluded to fall under a > clear name jurisdicti

Re: Name-constraining government CAs, or not

On Sun, May 17, 2015 3:28 pm, Peter Bowen wrote: > What if Mozilla puts a simple rule in place? > > All CAs must either: > - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a > assessor who meets the requirements of BR 8.2 or > - Be named constrained > > "Government CAs" (w

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 conve

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

Re: Requirements for CNNIC re-application

On Fri, May 22, 2015 3:11 pm, Eric Mill wrote: > On Fri, May 22, 2015 at 5:15 PM, Kathleen Wilson > wrote: > > > On 4/7/15 5:31 PM, Richard Barnes wrote: > > > >> > >> 5. April 1, 2016 is the earliest date at which CNNIC may apply for full > > inclusion, so SSL certificates issued after Apr 1 20

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 certif

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: 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 w

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 rai

Re: SECOM Request for EV Treatment

On Wed, August 5, 2015 2:51 pm, Kathleen Wilson wrote: > SECOM has applied to enable EV treatment for the "Security Communication > RootCA2" root certificate that was included in NSS via Bugzilla Bug > #527419. > > SECOM is a Japanese commercial CA that provides SSL and client > certificates f

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 includ

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

  1   2   3   4   5   6   7   8   9   10   >