Re: Certificate for com and it

On 08/02/18 13:47, Hanno Böck wrote: > Is a revoked intermediate cert a license for operating a yolo CA that > signs everything? Given the fragility of revocation checking I'd find > that a problematic precedent. In this case, the certificates are revoked in Firefox via OneCRL and Chrome via

Re: Misissuance/non-compliance remediation timelines

On 07/02/18 15:14, Alex Gaynor wrote: > That said, given the issues Paul highlighted in his original mail (which I > wholeheartedly concur with), it seems the place to focus is the folks who > are getting Ds right now. Therefore I think the essential part of your > email is your agreement that CAs

Re: ccadb.org

On 30/01/18 00:48, James Burton wrote: > I was doing research on the ccadb.org site and was surprised to find that > the site is running only in HTTP and is not using HTTPS. Now, I understand > that GitHub pages don't support HTTPS for custom domains but you could > always use CloudFlare for HTTPS

Re: Summary of Responses to the November CA Communication

On 24/01/18 21:41, Wayne Thayer wrote: > First off, I question if we would really use lesser sanctions more often. I > think we would still want to coordinate their implementation with other > user agents, and that is a tedious process. I think it's important for root programs to make independent

Re: Summary of Responses to the November CA Communication

On 24/01/18 13:56, Ryan Sleevi wrote: >> more frequently when requirements change. I propose that we require CAs to >> update their CPS to comply with version 2.5 of the Mozilla root store >> policy no later than 15-April 2018. I think Ryan is right here; the deadline for complying with most of

Re: DRAFT January 2018 CA Communication

On 24/01/18 22:19, Jonathan Rudenberg wrote: > While these CAs might want six months, it’s not clear that a good > argument has been made for this. Let’s Encrypt stopped validating > using the TLS-SNI-01 method under two hours after learning that there > was a *potential* security vulnerability in

Re: GlobalSign certificate with far-future notBefore

On 24/01/18 18:02, Doug Beattie wrote: > Can we consider this case closed with the action that the VWG will > propose a ballot that addresses pre and postdating certificates? Yes. I don't believe anyone has suggested that Globalsign broke a formal rule, either in the BRs or Mozilla's

Re: Summary of Responses to the November CA Communication

On 24/01/18 16:44, Wayne Thayer wrote: > In the past, new policy versions have not had a clearly defined future > effective date. That seems to have led some CAs to interpret the timing for > making changes to be "whenever we get around to it" instead of the intent > of "the policy is effective

Re: GlobalSign certificate with far-future notBefore

Hi Doug, Thanks for the quick response. On 24/01/18 11:52, Doug Beattie wrote: > In the case below, the customer ordered a 39 month certificate and > set the notBefore date for 2 months into the future. Momentary 2017/2018 confusion in my brain had me thinking that this was further into the

Re: GlobalSign certificate with far-future notBefore

On 24/01/18 04:57, David E. Ross wrote: > I am not sure about prohibiting forward-dating the notBefore date. I > can picture a situation where an existing site certificate is going to > expire. The site's administration decides to obtain a new certificate > from a different certification

Re: GlobalSign certificate with far-future notBefore

Hi Jonathan, On 23/01/18 22:55, Jonathan Rudenberg wrote: > A certificate issued by GlobalSign showed up in CT today with a notBefore > date of March 21, 2018 and a notAfter date of April 23, 2021, a validity > period of ~1129 days (more than three years). Thank you for pointing this out. This

Re: Updating Root Inclusion Criteria (organizations)

On 19/01/18 13:20, Jakob Bohm wrote: > My suggestions are only meant to inspire formal rules written / chosen > by module leaders such as you. But the entire point of this discussion is that we are pointing out it's hard to make such rules in the way you have just made them without being

Re: Updating Root Inclusion Criteria (organizations)

On 19/01/18 01:05, Jakob Bohm wrote: > On 18/01/2018 11:01, Gervase Markham wrote: >> On 17/01/18 19:49, Jakob Bohm wrote: >>> 3. Major vertical CAs for high value business categories that issue >>>    publicly trusted certificates at better than EV level integrity.  For >> >> How do you define

Re: Updating Root Inclusion Criteria

On 18/01/18 14:24, Ryan Sleevi wrote: > Or, conversely, that we cannot discuss inclusion policies in isolation from > discussion root policies - we cannot simultaneously work to strengthen > inclusion without acknowledging the elephant in the room of the extant CAs. We aren't necessarily

Re: Updating Root Inclusion Criteria

Hi Ryan, On 18/01/18 13:55, Ryan Sleevi wrote: > I do want to point out that you are substantially changing the goals from > what Wayne posited. That is, you have moved the goalpost from being > 'objective' to being what is 'fair', and 'fair' will inherently be a > subjective evaluation. One of

Re: Updating Root Inclusion Criteria

On 18/01/18 13:53, Ryan Sleevi wrote: > But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at > the detriment to both user security and the ecosystem. If your goal is for > policies that do not favor incumbents, then it seems a significantly > different discussion should

Re: Updating Root Inclusion Criteria (organizations)

On 17/01/18 19:49, Jakob Bohm wrote: > 3. Major vertical CAs for high value business categories that issue >   publicly trusted certificates at better than EV level integrity.  For How do you define "major"? And "high value business category"? > 4. Selected company CAs for a handful of

Re: Updating Root Inclusion Criteria

On 17/01/18 19:14, Ryan Hurst wrote: > Since Google's PKI was mentioned as an example, I can publicly state > that the plan is for Google to utilize the Google Trust Services > infrastructure to satisfy its SSL certificate needs. While I can not > announce specific product roadmaps I can say that

Re: Updating Root Inclusion Criteria

On 17/01/18 15:41, Peter Bowen wrote: > In the interest of transparency, I would like to add one more example > to your list: > > * Amazon Trust Services is a current program member. Amazon applied > independently but then subsequently bought a root from Go Daddy > (obvious disclosure: Wayne was

Re: Updating Root Inclusion Criteria

On 17/01/18 15:13, Jonathan Rudenberg wrote: > I like this concept a lot. Some concrete ideas in this space: > > - Limit the validity period of root certificates to a few years, so that the > criteria can be re-evaluated, updated, and re-applied on a rolling basis. Are you saying we should do

Re: Updating Root Inclusion Criteria

On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should focus less on the questions of whether a CA > is "appropriate" or "deserving" of participation in the Mozilla Root > Program, and more on whether they are willing and able to fulfill the > expectations of them as a steward of

Re: CCADB disclosure of id-kp-emailProtection intermediates

On 17/01/18 10:25, Rob Stradling wrote: > However, the Stable version of the Mozilla Root Store Policy [2] still > says 15th January 2018. > > Surely the Stable version of the Policy is in force and the Draft > version is not yet in force? > > Perhaps Mozilla could consider publishing a v2.5.1

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

On 14/01/18 21:32, jacob.hoffmanandr...@gmail.com wrote: > We discussed a similar approach (using CAA) on our community forum, > and concluded we don't want to pursue it at this time: > https://community.letsencrypt.org/t/tls-sni-via-caa/50172. The TXT > record would probably work more widely than

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

On 12/01/18 14:52, Doug Beattie wrote: > For shared IP address environments, it may be possible to receive a > certificate for a domain you don’t actually control, but a number of > things need to happen in order for this to be successful. What can > go wrong? Doug: what do you see as the exact

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

On 10/01/18 17:39, Matthew Hardeman wrote: > Here again, I think we have a problem. It's regarded as normal and > acceptable at many web host infrastructures to pre-stage sites for > domain-labels not yet in use to allow for development and test deployment. I agree that "no unknown domain names"

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

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 > number of random hosting companies on the internet. I don't think that's true. If your hosting

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

On 10/01/18 14:34, Jakob Bohm wrote: > Enforcement on shared hosting systems would be easier if the TLS-SNI-01 > ACME mechanism used names such as >   1234556-24356476._acme.requested.domain.example.com > since that would allow hosting providers to restrict certificate uploads > that claim to be

Re: Changes to CA Program - Q1 2018

On 10/01/18 00:23, Kathleen Wilson wrote: > I would like to thank Aaron Wu for all of his help on our CA Program, > and am sorry to say that his last day at Mozilla will be January 12. I > have appreciated all of Aaron’s work, and it has been a pleasure to work > with him. Seconded. > I think

Re: Potential problem with ACME TLS-SNI-01 validation

On 10/01/18 02:26, j...@letsencrypt.org wrote: > We've received a credible report of a problem with ACME TLS-SNI-01 validation > which could allow people to get certificates they should not be able to get. > While we investigate further we have disabled tls-sni-01 validation. > > We'll post

Re: Serial number length

Hi, On 29/12/17 06:24, Jakob Bohm wrote: > 1. Do all recently issued certificates have to contain at least 64 bits >   of randomness in their serial numbers? Yes. (References given by others.) > 2. Is it acceptable for a CA to satisfy this requirement by generating >   random 64 bit serial

Re: Dashboard and Study on CAA Adoption

Hi Quirin, On 15/12/17 15:09, Quirin Scheitle wrote: > The results, paper, and a dashboard tracking CAA adoption are available under > > https://caastudy.github.io/ Belatedly, thank you and your colleagues for doing this excellent work. It is interesting that you have received no iodef

Mozilla CA Team availability

The Mozilla CA team will have limited availability over the Christmas and New Year period, and so you should not expect us to engage substantively in complex debates, make controversial decisions, or otherwise act as if we were functioning at full strength :-) We hope that normal service will be

Re: CA generated keys

On 15/12/17 16:02, Ryan Hurst wrote: > So I have read this thread in its entirety now and I think it makes sense for > it to reset to first principles, specifically: > > What are the technological and business goals trying to be achieved, > What are the requirements derived from those goals, >

Re: On the value of EV

On 13/12/17 11:58, Tim Shirley 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 obscure the fact that “Green > Bar” adds value in

Re: On the value of EV

On 11/12/17 17:00, Ryan Sleevi wrote: > Fundamentally, I think this is misleading. It presumes that, upon > something bad happening, someone can link it back to that certificate > to link it back to that identity. If I was phished, and entered my > credentials, there's no reason to believe I've

Re: CA generated keys

Hi Tim, The more I think about it, the more I see this is actually a interesting question :-) I suspect the first thing Mozilla allowing this would do would be to make it much more common. (Let's assume there are no other policy barriers.) I suspect there are several simpler workflows for

Re: Possible future re-application from WoSign (now WoTrus)

On 22/11/17 09:05, Gervase Markham wrote: > We understand that WoTrus (WoSign changed their name some months ago) > are working towards a re-application to join the Mozilla Root Program. > Richard Wang recently asked us to approve a particular auditor as being > suitable to audit their operations.

Re: Anomalous Certificate Issuances based on historic CAA records

On 30/11/17 14:52, Ryan Sleevi wrote: > I think that, as CAA deployment becomes common, this pattern will be > not-uncommon. I would hope we don't sound false alarms when it does. After a little time (as it does seem some bugs are still being shaken out), I am considering having Mozilla adopt a

Re: Firefox Mobile - Which Trust Store?

On 27/11/17 19:50, Myers, Kenneth (10421) wrote: > Does Firefox mobile use the NSS trust store? Yes, on Android. It uses the OS trust store on iOS. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On 24/11/17 11:37, Rob Stradling wrote: > When issuing a "single domain" certificate to (for example) > www.example.com or *.example.com, it's fairly common practice for CAs to > also include in the certificate a SAN.dNSName for the "base domain" > (e.g., example.com).  (Similarly, if the

Re: Forbidden Practices: Subscriber key generation

On 14/11/17 21:53, Doug Beattie wrote > The question is, if we issue Code Signing certificates via P12 files > in compliance with the Code Signing standard, are we out of > compliance with the Mozilla policy? How do you recommend we respond > to this checklist question? Mozilla does not have

Re: Possible future re-application from WoSign (now WoTrus)

On 22/11/17 11:41, Tom wrote: > https://www.wosign.com/english/about.htm has been updated with the new > name, WoTrus, and currently says "Richard Wang, CEO" Richard stated to me at one point (I can't remember whether in person or by email) that at the time of speaking, he was no longer CEO, and

Possible future re-application from WoSign (now WoTrus)

We understand that WoTrus (WoSign changed their name some months ago) are working towards a re-application to join the Mozilla Root Program. Richard Wang recently asked us to approve a particular auditor as being suitable to audit their operations. In the WoSign Action Items bug:

Warning about posting via Google Groups

Dear m.d.s.p., We appear to again have a problem with messages posted via the Google Groups web UI making it to all subscribers on the list: https://bugzilla.mozilla.org/show_bug.cgi?id=1412993 Until that problem is resolved, if you wish to post to the list, please subscribe to the mailing list

Re: November 2017 CA Communication ACTION 1 April 15 2018 date question

On 17/11/17 00:26, Arkadiusz Ławniczak wrote: > [...] I do not see such requirement in the Policy or even by > searching m.d.s list.. Maybe I missed something. Does anybody know > where did it come from? https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md section 5.3.1. However,

Re: Third party use of OneCRL

On 07/11/17 14:08, niklas.bachma...@googlemail.com wrote: > I'm working for a big managed security provider. We would like to > benefit from OneCRL as a means of improving our certificate > revocation checking. As in, you'd like to download one copy per day, or you'd like 100,000 clients to

Re: Estonia e-residency instructing users not to update Firefox (on Mac)

On 02/11/17 11:39, Henri Sivonen wrote: > A Medium post claiming[1] to represent Estonia e-residency > https://medium.com/e-residency-blog/estonia-is-enhancing-the-security-of-its-digital-identities-361b9a3c9c52 > instructs Mac users not to update Firefox from December 15 2017 onwards. Thank you

Re: Incident Report : GlobalSign certificates with ROCA Fingerprint

On 03/11/17 18:16, douglas.beat...@gmail.com wrote: > Here is the final incident report Thanks, Doug :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom inclusion request: next steps

Dear Inigo, On 14/09/17 09:49, Gervase Markham wrote: > The Mozilla CA Certificates team has been considering what the > appropriate next steps are for the inclusion request from the CA > "StartCom".[0] As readers will know, this CA has previously been removed > from trust[1], and so a

Re: Mozilla’s Plan for Symantec Roots

Hi Peter, Ryan is the chain-building expert, and others have deeper knowledge of how the new Symantec/DigiCert PKI is going to work than I do, but here's an attempt to answer your question. On 27/10/17 16:51, Peter Bowen wrote: > If DigiCert generates a new online issuing CA on 20 March 2018 and

Re: Francisco Partners acquires Comodo certificate authority business

On 31/10/17 13:21, Kyle Hamilton wrote: > http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business Comodo notified Mozilla of this impending acquisition privately in advance, and requested confidentiality, which we granted. Now that the acquisition is

Re: ETSI audits not listing audit periods

Hi Arno, On 31/10/17 08:46, Arno Fiedler wrote: > there is a problem with the auditor qualification and the national > accreditation of some auditing bodies. Can you help us understand what about the discussion so far leads you to that conclusion? It seems to me that the problem being raised is

Re: Mozilla’s Plan for Symantec Roots

On 18/10/17 13:49, Gervase Markham wrote: > Apple have confirmed that their list is complete and correct. As have Google. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: DRAFT November 2017 CA Communication

On 27/10/17 00:23, Kathleen Wilson wrote: > Looking forward to further discussion about which errata should be allowed. Those are the correct two errata. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Proposed policy change: require private pre-notification of 3rd party subCAs

Hi Doug, On 24/10/17 16:43, Doug Beattie wrote: > I assume this applies equally to cross signing, Yes. > but not to "Vanity" CAs that are set up and run by the CA on behalf of a > customer. If you have physical control of the intermediate and control of issuance, it doesn't apply. Gerv

Proposed policy change: require private pre-notification of 3rd party subCAs

One of the ways in which the number of organizations trusted to issue for the WebPKI is extended is by an existing CA bestowing the power of issuance upon a third party in the form of control of a non-technically-constrained subCA. Examples of such are the Google and Apple subCAs under GeoTrust,

Re: Mozilla’s Plan for Symantec Roots

On 17/10/17 10:01, Gervase Markham wrote: > Here's an informal list created by me examining the CCADB. Note that the > CCADB links won't work for anyone except Root Store operators. Apple have confirmed that their list is complete and correct. Gerv

Re: Mozilla’s Plan for Symantec Roots

On 17/10/17 15:50, Ryan Sleevi wrote: > That doesn't seem to line up with the discussion in > https://groups.google.com/d/topic/mozilla.dev.security.policy/_EnH2IeuZtw/discussion > to date. Do you have any additional information to share? > > Note that the path you just described is the one that

Re: Mozilla’s Plan for Symantec Roots

On 16/10/17 20:19, Daniel Cater wrote: > Could we have a list of the subCAs that are being considered for exemption > for the distrust? Here's an informal list created by me examining the CCADB. Note that the CCADB links won't work for anyone except Root Store operators. GeoTrust Global CA |

Mozilla’s Plan for Symantec Roots

As per previous discussions and https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was reached among multiple browser makers for a graduated distrust of Symantec roots. Here is Mozilla’s planned timeline for the graduated distrust of Symantec roots (subject to change): *

Mozilla’s Plan for Symantec Roots

As per previous discussions and https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was reached among multiple browser makers for a graduated distrust of Symantec roots. Here is Mozilla’s planned timeline for the graduated distrust of Symantec roots (subject to change): *

Re: Proposed change to CA contact policy

On 09/10/17 18:04, Matthew Hardeman wrote: > Echoing Mr. Lamb's concern, I would think that defining two > "important notice role/mailing list recipient addresses" and always > sending important notices to both. This would allow for a mailing > list on CA internal infrastructure as well as one on

Re: Issuing and using SHA-1 OCSP signing certificates

On 03/10/17 18:35, Doug Beattie wrote: > The specific issue is that these client certificate CAs don't have > the EKU extension even though we have no intent of issuing SSL > certificates (they are WT audited and verified to not issue any SSL > certificates per the BRs). Would it be an acceptable

Re: CAA reporting support and tests?

On 26/09/17 00:03, Andrew wrote: > is that the reports should only be sent in a situation where a > certificate _would_ have been issued if not for the CAA records. I'd say that's right. I'd think that by far the more common use case would be internal policy enforcement at a company rather than

Re: DigiCert-Symantec Announcement

On 26/09/17 03:17, Ryan Sleevi wrote: > update in a year, are arguably outside of the scope of ‘reasonable’ use > cases - the ecosystem itself has shown itself to change on at least that > frequency. Is "1 year" not a relatively common (for some value of "common") setting for HPKP timeouts for

Re: PROCERT decision

On 22/09/17 00:33, Andrew wrote:> Will there be any sort of deprecation period for PROCERT certificates > as with StartCom/Wosign & Symantec? Or is PROCERT small enough that > you believe it's feasible to just immediately distrust them without > any significant negative impact on the overall web

Re: Old roots to new roots best practice?

On 20/09/17 03:49, userwithuid wrote: >> I agree, Gerv's remarks are a bit confusing with respect to the concern. Ryan is polite. :-) > Wrt to the StartCom bulletpoint, I guess this was a mistake on Mozilla's part > then and should probably be acknowledged as such, @Gerv. Yes, I acknowledge

Re: DigiCert mis-issuance report: rekeyed certificates

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1401407 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: PROCERT issues

On 27/09/17 18:54, Matthew Hardeman wrote: > In the case of StartCom, I can not help but feel that they are being > held to an especially high standard (higher than other prior adds to > the program) in this new PKI because of who they are -- despite the > fact that management and day-to-day

Re: Incident Report format

On 22/09/17 00:12, Ryan Sleevi wrote: > Based on the number of reports reviewed recently, I suspect we've got > opportunities for improvement, but I'm not quite sure yet what the concrete > suggestions on that should look like. A few thoughts below: Here's a set of changes which attempt to

PROCERT decision

The CA Certificates module owner and peers have come to a decision regarding our investigations into the activities of the CA "PROCERT". A large number of issues were raised regarding the operations and practices of this CA: https://wiki.mozilla.org/CA:PROCERT_Issues Considering them, it seems

Incident Report format

It seems like the list of topics to cover on the Responding to a Misissuance page: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report has become a de facto template for incident reports. We've now had quite a few CAs use this outline to respond to issues. If people (CAs or

Re: Public trust of VISA's CA

Additionally, 13 days ago it was reported to VISA that their OCSP responder was misconfigured to return "good" responses for non-existent certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=1398261 As far as I can see, this is the case for their end-entity certificates, not just some roots

Re: Public trust of VISA's CA

On 19/09/17 16:27, Peter Bowen wrote: > I think your statement is a little broad. Every CA only issues > certificates to themselves and their own customers (or as the BRs call > them "Subscribers"). Yes, you are right. "Customers" was the wrong word. Perhaps I rather meant they only issue to

Re: FW: StartCom inclusion request: next steps

Hi Inigo, On 15/09/17 17:30, Inigo Barreira wrote: > There wasn´t a lack of integrity and monitoring, of course not. All PKI logs > were and are signed, it´s just the auditors wanted to add the integrity to > other systems which is not so clear that should have this enabled. For > example, if

Re: CAs not compliant with CAA CP/CPS requirement

On 15/09/17 09:38, richmoor...@gmail.com wrote: > I suspect many smaller CAs are non-compliant too, for example gandi's CPS > hasn't changed since 2009 according to its changelog. > > https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf Thank you for bringing this to

Re: CAA Certificate Problem Report

On 13/09/17 23:57, Matthew Hardeman wrote: > This is especially the case for CAA records, which have an explicit security > function: controlling, at a minimum, who may issue publicly trusted > certificates for a given FQDN. I'd be interested in your engagement on my brief threat modelling; it

Re: CAA Certificate Problem Report

Hi Nick, On 13/09/17 20:39, Nick Lamb wrote: > Gerv, rather than start by digging into the specific technical details, let > me ask a high level question. > > Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA > record saying to only permit the non-existent Gotham

Re: FW: StartCom inclusion request: next steps

Hi Franck, On 18/09/17 15:49, Franck Leroy wrote: > Our understanding in April was that as long as StartCom is not > allowed by Certinomis to issue EE certs, the disclosure was not > mandated immediately. I think that we need to establish a timeline of the exact events involved here. But I

Re: FW: StartCom inclusion request: next steps

On 15/09/17 15:35, Inigo Barreira wrote: > No, those weren´t tests. We allowed the use of curves permitted by the BRs > but this issue came up in the mozilla policy (I think Arkadiusz posted) and I > also asked about it in the last CABF F2F (I asked Ryan about it) and then, > with that outcome

Re: PROCERT issues

On 11/09/17 12:03, Gervase Markham wrote: > Thank you for this initial response. It is, however, far less detailed > than we would like to see. I have not had any further updates from PROCERT. I have tried to reflect their responses from this email here:

Re: Permission to use Errata CAA Algorithm

On 15/09/17 20:24, j...@letsencrypt.org wrote: > We would like to ask the Mozilla and Google root programs on this list to > immediately grant at least temporary dispensation for CAs to implement the > CAA checking algorithm as described in this errata: > >

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

On 15/09/17 13:55, cornelia.enk...@gmail.com wrote: > technically the CA now is disabled to sign certificates using SHA1 But presumably you thought that was true before this incident? (And if not, why not?) Gerv ___ dev-security-policy mailing list

Re: FW: StartCom inclusion request: next steps

On 15/09/17 09:24, Inigo Barreira wrote: > AFAIK, Certinomis only disclosed in the CCADB That means it's published and available. As noted in my other reply, information as to exactly what this cross-sign enables trust for would be most helpful, as I may have misunderstood previous statements on

Re: FW: StartCom inclusion request: next steps

Hi Inigo, On 14/09/17 16:05, Inigo Barreira wrote: > Those tests were done to check the CT behaviour, there was any other testing > of the new systems, just for the CT. Is there any reason those tests could not have been done using a parallel testing hierarchy (other than the fact that you

Re: CAA Certificate Problem Report

On 11/09/17 22:28, Jeremy Rowley wrote: > I would support that. I can't recall why it's in there. As the drafter of the section :-), my intent was to make it so that if a site owner were concerned about the possibility that their CAA record or DNS could be spoofed, they could use DNSSEC to solve

Re: CAA Certificate Problem Report

On 09/09/17 10:21, Jeremy Rowley wrote: > Certificate 1 contains a single DNS identifier for > big.basic.caatestsuite.com . This DNS > name has a CAA resource record set that is too large to fit within a single > DNS UDP packet, but small enough to fit within a

Re: StartCom cross-signs disclosed by Certinomis

Hi Franck, On 03/08/17 08:59, Franck Leroy wrote: > On end of June the audit report form PwC was available but with still some > minor issues. I asked StartCom to correct them. > > On July 14th the audit report and the policy were updated and published on > StartCom website. The audit reports

Re: CAs not compliant with CAA CP/CPS requirement

Hi Ben and Jeremy, On 09/09/17 01:25, Ben Wilson wrote: > Those are typos. See section 4.2.1 of our CPS posted here: > https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf This reads: "The Certification Authority CAA identifying domains for CAs within DigiCert’s

Re: PROCERT issues

Hi Alejandro, Thank you for this initial response. It is, however, far less detailed than we would like to see. In the email I sent to you letting you know that we were looking at PROCERT, I wrote: "You may wish to review a similar issue list we created for Symantec:

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

Hi Connie, On 06/09/17 20:38, cornelia.enk...@gmail.com wrote: > SwissSign has identified the following incident: > two Certificate signed with SHA1: Violation BR 7.3.1 Thank you for this report. There have been a couple of reasonable follow-up questions here in the m.d.s.p. group; could you

Re: StartCom cross-signs disclosed by Certinomis

Getting back to this very late... I am studying this situation today. On 07/08/17 10:21, Franck Leroy wrote: > Then in November 2016 I contacted Kathleen and Gerv to know if there was some > stoppers to work with Inigo to help StartCom to be back in the business. > There was no opposition as

Re: SHA-1 OCSP responder certificates

On 07/09/17 00:41, Ben Wilson wrote: > We immediately contacted the operators of the issuing CAs and > requested that they replace their OCSP responder certificates with > ones signed with SHA2, and most have done so. However, in drafting > this post I reviewed the Baseline Requirements, section

Re: PROCERT issues

On 07/09/17 22:27, Ryan Sleevi wrote: > Do you have an anticipated time period for discussion? That is, what > represents a time for which PROCERT may submit feedback to have it > considered, and at what point you will consider discussion closed? I don't want to place a hard limit on it because

PROCERT issues

Mozilla has decided that there is sufficient concern about the activities and operations of the CA "PROCERT" to collect together our list of current concerns. That list can be found here: https://wiki.mozilla.org/CA:PROCERT_Issues Note that this list may expand or reduce over time as issues are

Re: Per-intermediate CAA/problem reporting info

On 28/08/17 18:40, Andrew Ayer wrote: > However, externally-operated sub-CAs generally have their own CAA > identifiers and problem reporting information, and this information > is not currently collected. Would it be possible to collect this > information on a per-intermediate basis and to

Re: Remove old WoSign root certs from NSS

On 30/08/17 18:50, Kathleen Wilson wrote: > https://blog.mozilla.org/security/2017/08/30/removing-disabled-wosign-startcom-certificates-firefox-58/ > > I will look into getting this translated and published in China. Here are the links to the post in Chinese, kindly supplied by our colleagues:

Re: Adding a subCA to OneCRL when email-signing users may be impacted

On 01/09/17 04:47, Víctor wrote: > But I find an issue here. The root has both websites and email trust > bits. The subCA cert is not constrained. The representative of the CA > want to add the subCA to OneCRL because this subCA doesn't issue TLS > certificates. OneCRL and the CA program acts on

Re: Responding to a misissuance

On 18/08/17 04:37, Gervase Markham wrote: > I've started a wiki page giving Mozilla expectations and best practices > for CAs responding to a misissuance report. (No idea why I decided to > write that now...) > > https://wiki.mozilla.org/CA/Responding_To_A_Misissuance I have now removed the

Re: BR compliance of legacy certs at root inclusion time

On 22/08/17 11:02, Ryan Sleevi wrote: > I think it'd be useful if we knew of reasons why standing up (and > migrating) to a new infrastructure was not desirable? It is true that in the case of a legacy root, creating a new root with a cross-sign is not technically all that complex (although it

  1   2   3   4   5   >