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 CRLSe
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
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
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
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 th
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
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 requirements.
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 imm
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 futu
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 authorit
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
On 24/01/18 00:47, Wayne Thayer 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 we should have a more general stipulation that Mozilla does not
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
arbitrary
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 "ma
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 "strength
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 m
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 happen
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 too-bit-to
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 t
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
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 th
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 glob
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 of
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
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 d
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"
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 provi
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 fo
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 thi
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 more
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 numbe
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 message
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 r
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,
> Wh
On 15/12/17 15:50, Tim Shirley wrote:
> I don’t see how you can argue that the EV “seatbelt” breaks 100% of
> the time. I know my bank uses an EV cert. Any time I come across a
> site claiming to be my bank but lacking an EV cert, and my browser
> shows me that distinction, is a time when the sea
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 t
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 mai
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 certifi
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.
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 po
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
https://lists.mozilla.org
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 certifica
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 certifica
Hi Quirin,
Thank you for your work on this topic. I would be grateful if you could
file Bugzilla bugs in the Misissuance component as follows, giving your
evidence of misissuance:
On 22/11/17 23:50, Quirin Scheitle wrote:
> 1) Mix of wildcard and non-wildcard DNS names in SAN
> Batch: https
On 22/11/17 21:15, uri...@gmail.com wrote:
> In particular, why would QiHoo 360 shut down efforts by Startcom, run
> by a relatively trusted member of the community, Inigo Barreira, to
> be accepted as a CA; and instead favor WoTrus, run by Richard Wang,
> an explicitly UN-trusted member of the com
On 22/11/17 18:00, Ryan Sleevi wrote:
> I think an important part of this discussion is trying to understand to
> what side of Hanlon's razor did WoSign's actions fall (or, to that matter,
> of any CA). If it was incompetence, is there sufficient explanation for how
> such incompetence happened? If
On 22/11/17 17:03, Matthew Hardeman wrote:
> approval in terms of community buy-in. The downside, of course, is that
> while this alternative pre-discussion allows for discussion of the nebulous
> concept of "trust" and integrity, it actually denies the community those
> matters which can be most
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 poli
On 22/11/17 11:39, Hanno Böck wrote:
> In any case: I agree these are legitimate questions, if past CA
> incidents happen the documents describing them shold be properly
> archived. I think having a rule that one copy of them has to be stored
> on mozilla infrastructure is wise.
Having been burned
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&CTO"
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, a
On 22/11/17 10:54, Jakob Bohm wrote:
> Some notes about previously discussed items:
Mozilla is not suggesting that WoSign has completed all of the steps.
The entire point is that we want to have this pre-discussion before they
make the effort to do so.
> Although not listed in the Action plan in
Hi Arkadiusz,
On 17/11/17 19:28, Arkadiusz Ławniczak wrote:
> Thanks Gerv
>
> We have a situation in which our last WT audit is for the period
> ending on April 14,2017. As we know the audit is valid until the next
> audit is started. That is, that the next WT audit must be for period
> starting
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:
https://bugzilla.
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 v
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, th
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 downlo
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 f
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
On 02/11/17 10: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.
The policy
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-applicat
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
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 publi
[ Also at
https://blog.mozilla.org/security/2017/10/31/statement-digicerts-proposed-purchase-symantec/
]
Mozilla’s Root Store Program has taken the position that trust is not
automatically transferable between organizations. This is specifically
stated in section 8 of our Root Store Policy v2.5[0]
On 31/10/17 00:13, Kathleen Wilson wrote:
> Yes, that meets our requirement regarding stating the audit period
> and if it is a period-of-time/full audit. The problem is that most
> ETSI audit statements that we get do not say this. And it has been an
> uphill battle for me to get ETSI audit statem
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
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
https://lists.mozilla.org/listinfo/dev-security-pol
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
https://lists.mozil
On 25/10/17 12:15, Kai Engert wrote:
> Will these changes be implemented in the ESR 59.x releases, which will
> be released in parallel to the above releases?
That's a really good question.
I am told that the code implementing the console warning is going to be
there before ESR branches, so we sh
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
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, bu
On 16/10/17 18:32, Gervase Markham wrote:
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
This is now https://bugzilla.mozilla.org/show_bug.cgi?id=1409257 .
Gerv
___
dev-security-policy mailing li
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
___
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 p
On 16/10/17 20:22, Peter Bowen wrote:
> Will the new managed CAs, which will operated by DigiCert under
> CP/CPS/Audit independent from the current Symantec ones, also be
> included on the list of subCAs that will continue to function?
AIUI we are still working out the exact configuration of the n
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
|
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):
* January
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):
* January
On 11/10/17 11:50, Gervase Markham wrote:
> Kathleen now says she would prefer to email the Primary POCs and CC the
> email aliases. Handily, this allows for what you suggest. So consider
> the proposal changed to that.
Or rather, email the primary POCs and CC the first email alias.
Gerv
On 13/10/17 15:41, Gervase Markham wrote:
> Er, we should fix that...
Well, actually it's scoped as being inside the original EV cert request,
so there's probably no harm in practice. If any CAB Forum member wants
to fix this small error, great, but I've got too many other ballot ideas
to juggle.
On 13/10/17 06:01, Peter Bowen wrote:
> This is taken directly from the EV Guidelines section 14.2.2. The
> EVGs don't use the PSL, they specify third or higher.
Er, we should fix that...
Gerv
___
dev-security-policy mailing list
dev-security-policy@li
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
The CCADB stores a couple of different types of "contact" records:
* Primary POC (1 or more): someone who is "authorized to speak for and
to bind the CA that they represent."
* POC (0 or more): Another contact at that CA.
* Email Alias (1 or 2): defined as "more likely to continue working as
perso
On 29/09/17 20:08, Jakob Bohm wrote:
> 1. Title should also reflect that this is now about various kinds of
> incidents.
The page is now called:
https://wiki.mozilla.org/CA/Responding_To_An_Incident
I've also made the other changes. Thank you for your feedback.
Gerv
___
On 06/10/17 19:41, Doug Beattie wrote:
> We could provide you with the non-SSL SHA-1 CAs and have them added to OneCRL
> as long as we're sure that would not impact their use for client
> authentication and secure email. Would that suffice?
Yes. File a Bugzilla bug.
While we don't have a manda
On 04/10/17 23:38, Nick Lamb wrote:
> However if I understand the situation correctly, this situation is
> already very low risk anyway with no reasonable expectation that it
> could be exploited against a competent SSL/TLS client which for some
> reason still accepts SHA1 and of course no risk for
On 05/10/17 20:00, Inigo Barreira wrote:
> Has this been asked ever? Has any other CA published it? It´s just to know.
> And, is there a "default" scope for this kind of security audits?
Well, you indicated your willingness to publish them in an email to me,
if I remember correctly. And it would
On 05/10/17 15:32, Inigo Barreira wrote:
> I know this reply is not related to the email thread but wouldn´t like to
> leave the feeling that the code we are using is bad, or not secure, etc.
Perhaps now might be a good time to publish the security audits that
were done on the code, then?
Gerv
_
On 05/10/17 05:57, Kathleen Wilson wrote:
> Bug Filed regarding PROCERT Action Items:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1405862
Hi Kathleen,
I know you have already filed the bug, but I think that perhaps the list
of action items might need to be a bit more detailed and/or rigorous
t
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
On 29/09/17 13:21, Peter Bachman wrote:
> Can I have a pointer to the current up to date discussion on the S/MIME trust
> bit?
What sort of discussion? Mozilla's root store still includes an S/MIME
trust bit and we have no plans to remove it.
Gerv
___
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 de
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 sit
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 ec
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 tha
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
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 decisi
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 capture
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 cl
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 oth
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 o
1 - 100 of 500 matches
Mail list logo
