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 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
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 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 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
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 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
|
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 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 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 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
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
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
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
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 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
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 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
[ 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 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
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
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
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
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 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 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 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
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
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.
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
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
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 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 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 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 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 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
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 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
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 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 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.
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 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
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 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 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
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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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
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 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 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 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
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 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 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 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 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 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 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 09/02/17 14:32, Gijs Kruitbosch wrote:
> Would Mozilla's root program consider changing this requirement so that
> it *does* require public disclosure, or are there convincing reasons not
> to? At first glance, it seems like 'guiding' CAs towards additional
> transparency in the CA market/indust
On 10/02/17 06:15, Richard Wang wrote:
> I think Mozilla should have a very clear policy for:
> (1) If a company that not a public trusted CA acquired a trusted root key,
> what the company must do?
> (2) If a company is a public trusted CA that acquired a trusted root key,
> what the company m
On 10/02/17 05:10, Peter Bowen wrote:
> On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via
>> A) The date Google took control of the GlobalSign roots
>> B) The date Google publicly announced GTS
>>
>> you will see there's quite a big delta. If you assume Google told
>> Mozilla about event A) befor
Hi Ryan,
On 09/02/17 19:55, Ryan Hurst wrote:
> - The EV OID associated with this permission is associated with GlobalSign
> and not Google and,
Which EV OID are you referring to, precisely?
> - GlobalSign is active member in good standing with the respective root
> programs and,
> - Google wi
On 11/02/17 12:13, Peter Gutmann wrote:
> Is no-one at Mozilla able to explain why they did this? It's a nontrivial
> piece of code to implement, surely someone must know what the thinking was
> behind doing it this way?
Peter: you are going to have to re-summarise your question. And then, if
you
Hi Inigo.
On 10/02/17 12:40, Inigo Barreira wrote:
> I see many "should" in this link. Basically those indicating "should notify
> Mozilla" and "should follow the physical relocation section".
It may be that this document does need redoing in formal policy
language. In the mean time, anyone unce
As members of the group will be aware, last month GoDaddy filed an
incident report concerning a problem with their domain validation system.
Domain validation is the most important task a CA can undertake, any any
flaws in it are serious. This is why the CAB Forum has been working for
some time on
The GoDaddy situation raises an additional issue.
Mozilla is neither adding any of the 8951 revoked certificates to
OneCRL, nor untrusting any GoDaddy intermediates. However, a more
serious incident might have led us to consider that course of action. In
that regard, the following information is w
Hi Steve,
On 12/02/17 15:27, Steve Medin wrote:
> A response is now available in Bugzilla 1334377 and directly at:
> https://bugzilla.mozilla.org/attachment.cgi?id=8836487
Thank you for this timely response. Mozilla continues to expect answers
to all reasonable and polite questions posed in our f
On 13/02/17 14:34, Nick Lamb wrote:
> I don't think Ballot 169 represents best practices per se. Instead as
> with the rest of the Baseline Requirements what we have here are
> _minimums_, we aren't asking that CAs should do no more than what is
> described, but that they must do at least what is d
On 13/02/17 16:41, Nick Lamb wrote:
> GoDaddy came up with). Thus, even though some of the methods from
> Ballot 169 are not included in the Baseline Requirements today,
> Mozilla intends to oblige root programme members to pick from those
> ten methods.
Yes. And this is permitted by the BRs becau
On 13/02/17 14:34, Doug Beattie wrote:
> This was for GlobalSign account used for testing, so it was a
> GlobalSIgn employee. Customers are not, nor have they ever been,
> permitted to add domains without GlobalSign enforcing the domain
> verification process.
OK, then I'm a bit confused. You sa
On 13/02/17 16:18, Peter Bowen wrote:
> In addition to updating it to follow formal policy language, I would
> suggest adding it directly to the policy. As it stands today there
> are 79 pages in the wiki starting with "CA:". It simply isn't
> possible to know which ones are effectively part of t
On 13/02/17 23:13, Santhan Raj wrote:
> One thing to highlight here is that the WebTrust audits are performed
> against the BRs and not against the root program requirements.
This is true, although (apart from the relative importance of domain
validation) this is similarly true of many items in t
On 13/02/17 14:34, Doug Beattie wrote:
> This was for GlobalSign account used for testing, so it was a
> GlobalSIgn employee. Customers are not, nor have they ever been,
> permitted to add domains without GlobalSign enforcing the domain
> verification process.
But currently GlobalSign employees
On 13/02/17 16:17, Steve Medin wrote:
> Getting all user agents with interest is issuance limits to implement
> the CA Issuers form of AIA for dynamic path discovery and educating
> server operators to get out of the practice of static chain
> installation on servers would make CA rollovers fairly
On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote:
> Isn't this mostly something that CAs should keep in mind when they
> setup "shop"?
>
> I mean it would be nice to have a way of avoiding that kind of impact
> of course, but if they think it's best to put all their eggs in one
> basket...
On 13/02/17 19:22, Jeremy Rowley wrote:
> As we tied the intermediate to a specific set of companies (which correlated
> roughly to a specific volume of certificates), renewal and pinning were
> non-issues. As long as each company was identified under the same umbrella,
> an entity renewing, orderi
401 - 500 of 500 matches
Mail list logo
