On 01/03/2017 12:43, 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 popular intermediate?
Suggestions
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 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 popular intermediate?
> Suggestions welcome.
Reviewing the discussion, I
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
On 14/02/2017 22:03, Nick Lamb wrote:
On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote:
Unfortunately, for these not-quite-web-server things (printers, routers
etc.), automating use of the current ACME Let's encrypt protocol with
or without hardcoding the Let's Encrypt URL is a
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,
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 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
Jakob Bohm via dev-security-policy
writes:
>Unfortunately, for these not-quite-web-server things (printers, routers
>etc.), automating use of the current ACME Let's encrypt protocol with or
>without hardcoding the Let's Encrypt URL is a non-starter for
On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote:
> Unfortunately, for these not-quite-web-server things (printers, routers
> etc.), automating use of the current ACME Let's encrypt protocol with
> or without hardcoding the Let's Encrypt URL is a non-starter for anyone
> using these
On Tue, Feb 14, 2017 at 10:13 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I mention P7 because IIS inhales them in one click and ensures that the
> intermediate gets installed.
Yes, but that's not because of PKCS#7, as I tried to explain and
.org
> Subject: Re: Intermediates Supporting Many EE Certs
>
> On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote:
> > - PKCS#7 chains are indeed not a requirement, but see point 1. It’s
> probably no coincidence that IIS supports it given awareness of the dema
On 14/02/2017 18:14, Nick Lamb wrote:
On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote:
- PKCS#7 chains are indeed not a requirement, but see point 1. It’s
probably no coincidence that IIS supports it given awareness of the demands
placed on enterprise IT admins.
I
On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote:
> - PKCS#7 chains are indeed not a requirement, but see point 1. It’s
> probably no coincidence that IIS supports it given awareness of the demands
> placed on enterprise IT admins.
I don't see how PKCS#7 offers any
On Tue, Feb 14, 2017 at 5:47 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> - The caching I’m talking about is not header directives, I mean
> how CAPI and NSS retain discovered path for the life of the intermediate.
> One fetch, per person,
rg>
Subject: Re: Intermediates Supporting Many EE Certs
On Mon, Feb 13, 2017 at 2:39 PM, Steve Medin <steve_me...@symantec.com
<mailto:steve_me...@symantec.com> > wrote:
With de facto use of AIA, there is no issuer installation on the server that
could be improper. P
.org
> Subject: Re: Intermediates Supporting Many EE Certs
>
> On Monday, 13 February 2017 22:40:45 UTC, Steve Medin wrote:
> > With de facto use of AIA, there is no issuer installation on the server
that
> could be improper. Proper is defined at the moment, either by cache
On Monday, 13 February 2017 22:40:45 UTC, Steve Medin wrote:
> With de facto use of AIA, there is no issuer installation on the server that
> could be improper. Proper is defined at the moment, either by cache or
> discovery hints.
Much as I should like ubiquitous ambient Internet to be a
On Mon, Feb 13, 2017 at 11:56 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Patrick, thanks, it appears my attempt at brevity produced density.
>
> - No amount of mantra, training, email notification, blinking text and
> certificate installation
; bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Patrick Figel via dev-security-policy
> Sent: Monday, February 13, 2017 2:10 PM
> To: r...@sleevi.com
> Cc: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: Inte
On Monday, 13 February 2017 16:18:46 UTC, 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
On 2/13/2017 8:17 AM, 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
@lists.mozilla.org
> Subject: Intermediates Supporting Many EE Certs
>
>
> What can be done about the potential future issue (which might happen with
> any large CA) of the need to untrust a popular intermediate?
> Suggestions welcome.
>
> Gerv
>
Either timespan or total certi
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
24 matches
Mail list logo