I did not consider it useful to say it, so I didn't. But I was certainly
thinking that "try... over the heads of people who make the decision" bit, when
the "appeal" got posted. ;-)
Is there such a thing as a right to be trusted? Interesting question... I would
say there isn't, trust cannot be
On Friday, 10 May 2019 19:00:11 UTC+2, Wayne Thayer wrote:
...
> I share the concern that option #2 sends a confusing message. As Jonathan
> stated, why should we distrust a CA for all but the most important websites
> they secure?
I'd say that both "too big to fail" and "too important to
On Saturday, 9 March 2019 03:44:12 UTC+1, Matthew Hardeman wrote:
> I know this isn't the place to bring a BR ballot, but I'm not presently a
> participant there.
>
> I present alternative language along with notes and rationale which, I put
> forth, would have resulted in a far better outcome
On Friday, 8 March 2019 17:07:57 UTC+1, Wayne Thayer wrote:
> I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track
> this issue.
>
> Apple has also submitted the following bug for this issue listing a large
> number of impacted certificates:
>
On Friday, 8 March 2019 04:28:17 UTC+1, Matt Palmer wrote:
> On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via
> dev-security-policy wrote:
> > On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > > But BRs are not to be
We will miss him.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
"... don't START inventing and applying any unwritten new rules..."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On Thursday, 12 April 2018 21:28:49 UTC+2, Alex Gaynor wrote:
> All that proves is the entire EV model cannot possibly accomplish what CAs
> claims (with respect to phishing and other similar concerns). To whit:
>
> - Two companies can validly possess trademarks for the same name in the
> United
On Tuesday, 10 April 2018 01:06:36 UTC+2, Peter Bachman wrote:
> https://groups.google.com/forum/#!forum/cus-policy-layer
Can you give us a few words, with the links you drop here? It would be nice.
Especially when in order to see what the link is about you must first become a
member of the
On Tuesday, 3 April 2018 14:19:43 UTC+2, ramiro...@gmail.com wrote:
> El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com
> escribió:
> > On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com wrote:
> > > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince
On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com wrote:
> El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió:
> > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > I fully understand the proposed solution about 2018 roots but as I
> > >
On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com wrote:
> Dear Wayne,
> Based on the long discussion regarding our request, I would appreciate having
> your opinion on the following:
> Move to a new root based on EJBCA (Enterprise License) and conduct a new
> audit with a new
On Monday, 5 March 2018 18:10:17 UTC+1, okaphone.e...@gmail.com wrote:
> On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill wrote:
> > I think it probably makes more sense to focus on sensitive key material
> > than non-sensitive CSRs.
> >
> > As a starting point, how reasonable would it be for
On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill wrote:
> I think it probably makes more sense to focus on sensitive key material
> than non-sensitive CSRs.
>
> As a starting point, how reasonable would it be for CAs to question their
> resellers, or to disseminate additional language to add to
On Sunday, 4 March 2018 22:44:26 UTC+1, Paul Kehrer wrote:
> On March 4, 2018 at 5:06:41 PM, Eric Mill via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
>
>
>
> It's also clear from the experience that rules of the road for resellers
> are unclear, and that
On Wednesday, 27 September 2017 18:56:27 UTC+2, Kathleen Wilson wrote:
> In past incidents, we have provided a list of action items that the CA must
> complete before they can be re-included in Mozilla's root store.
>
> What action items do you all think PROCERT should complete before they can
The answers from CAs we typically see in this group are more along the lines of
not thinking it necessary to revoke at all than needing more time, I'd say. So
I don't really see what this idea that 24 hours would be too short is based on.
I think relaxing the revocation time limit may in fact
On Friday, 4 August 2017 03:16:45 UTC+2, Matt Palmer wrote:
> On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via
> dev-security-policy wrote:
> > However, I think it is fine for Certinomis to cross-sign with new StartCom
> > subCA certs, as long as Certinomis ensures that Mozilla's
On Thursday, 3 August 2017 02:12:18 UTC+2, Matt Palmer wrote:
> On Wed, Aug 02, 2017 at 06:38:44PM -0400, Jonathan Rudenberg via
> dev-security-policy wrote:
> > I think the correct response is to add both intermediates to OneCRL
> > immediately, especially given the historic issues with
On Friday, 28 July 2017 08:15:43 UTC+2, Gervase Markham wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates
On Friday, 14 July 2017 04:44:39 UTC+2, Richard Wang wrote:
> Hi Peter,
>
> Thanks for your guesses.
> Buy no those issues in our system.
>
>
> Best Regards,
>
> Richard
That's what you say. But you've lied before. :-( So sorry, but that won't go
anywhere near regaining trust. You'll have
On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
>
> Please note this email topic is just for releasing the news that WoSign new
> system passed the security audit, just for demonstration that we finished
> item 5:
> " 5. Provide auditor[3] attestation that a full security audit of
On Thursday, 11 May 2017 19:08:06 UTC+2, Gervase Markham wrote:
> On 11/05/17 13:02, wiz...@ida.net wrote:
> > That said, it is fair point that the plan should spell out what happens if
> > symantec does not cooperate.
>
> I think we should cross that bridge when we come to it, which I hope we
On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham wrote:
> On 09/05/17 16:51, Gervase Markham wrote:
> > * Editing the proposal to withdraw the "alternative" option, leaving
> > only the "new PKI" option.
>
> This has now been done:
>
>
Hi Rick,
I don't see a "May 4th post". Where was it posted? Not here it seems.
Also it's reasonable that Symantec wants to "address impact to their customers"
but what about impact to all of the browsers users? It may be a good idea to
try and address (in your proposals) that to.
So far I
On Thursday, 27 April 2017 00:42:20 UTC+2, Ryan Sleevi wrote:
> On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> >
> > If this is about the possible consequences of compromise, then I'
On Wednesday, 26 April 2017 22:43:19 UTC+2, Ryan Sleevi wrote:
> On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika wrote:
>
> > I think this is getting weird.
> >
> > At first (some other thread) it get's explained that e.g. LetsEncrypt does
> > not do anything beyond domain validation and
I think this is getting weird.
At first (some other thread) it get's explained that e.g. LetsEncrypt does not
do anything beyond domain validation and possibly on notification take down a
few certificates of phishing site. And that was "... all OK because we want SSL
to be used everywhere, and
On Wed, Mar 29, 2017 at 3:22 AM, okaphone.elektronika--- via
> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
>
> > Weird.
> >
> > I expect there are no requirements for a CA to keep other people's private
> > keys safe. After all
Weird.
I expect there are no requirements for a CA to keep other people's private keys
safe. After all handling those is definitely not part of being a CA. ;-)
CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
It's probably my ignorance in these matters, but how does purchasing a root
certificate affect revocation?
Will that remain the responsibility of GlobalSign for any existing certificates
that have been signed with these roots? (Those would be intermediate
certificates, if I understand
On Friday, 17 March 2017 17:28:12 UTC+1, douglas...@gmail.com wrote:
> On Friday, March 17, 2017 at 5:37:38 AM UTC-4, Gervase Markham wrote:
> > On 16/03/17 17:20, douglas beattie wrote:
> > > Yes, RAs (trusted role employees) need to have the technical ability
> > > to manually add domains to
On Wednesday, 1 March 2017 12:44:16 UTC+1, Gervase Markham wrote:
> On 13/02/17 12:23, Gervase Markham wrote:
> > The GoDaddy situation raises an additional issue.
>
> > What can be done about the potential future issue (which might happen
> > with any large CA) of the need to untrust a
On Wednesday, 15 February 2017 18:27:28 UTC+1, Gervase Markham wrote:
> 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
34 matches
Mail list logo
