On 2017-05-17 13:23, Michael Casadevall wrote:
On 05/17/2017 05:04 AM, Kurt Roeckx wrote:
If the key is compromised, you can't rely on any date information
anymore, you need to revoke it completely and break things.
Won't that only be true in certificates without SCTs? Once you have a
SCT, yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/17/2017 05:04 AM, Kurt Roeckx wrote:
> If the key is compromised, you can't rely on any date information
> anymore, you need to revoke it completely and break things.
>
Won't that only be true in certificates without SCTs? Once you have a
SC
On 2017-05-16 14:24, Michael Casadevall wrote:
Maybe a bit out there, but an interesting thought none the less. It
would definitely go a good way at preventing one root certificate from
underpinning a large chunk of the internet. My thought here is if a
large "Too Big to Fail" CA's private key wa
On 16/05/17 19:53, Ryan Sleevi via dev-security-policy wrote:
What is the advantage of that, given that PKCS#7 involves
BER, it introduces C/C2/C3, and you're still supplying the same number of
certs?
I don't think there is any notable advantage.
I asked the question because I thought it wou
On Tue, May 16, 2017 at 2:12 PM, Rob Stradling
wrote:
>
> Regarding AIA->caIssuers, RFC5280 says:
> 'Conforming applications that support HTTP or FTP for accessing
>certificates MUST be able to accept individual DER encoded
>certificates and SHOULD be able to accept "certs-only" CMS mess
On 16/05/17 16:11, Ryan Sleevi via dev-security-policy wrote:
On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
The important point in this is that there should
On Tue, May 16, 2017 at 11:12 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Fewer round trips, if you can include everything in a single response.
>
So fewer round-trips if same-size, or bigger data set if you're anything
newer than 6 years (potentially
Fewer round trips, if you can include everything in a single response.
Alex
On Tue, May 16, 2017 at 11:11 AM, Ryan Sleevi wrote:
>
>
> On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 16/05/17 15:41, Ryan Sleevi vi
On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
>
>
>> The important point in this is that there should not be a non-linear path
>> of trust (which is implied, I
On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
The important point in this is that there should not be a non-linear path
of trust (which is implied, I think, by the reading of "group of
cross-certs"). But yes, there would be a linearized path.
If you *rely* on AIA, then why not
On Tue, May 16, 2017 at 10:34 AM, Doug Beattie
wrote:
> Thanks Rob and Ryan for pointing that out. Will the web servers need to
> send down a group of cross certs and then let the client use the ones they
> need in order to chain up to a root in their local trust store since the
> web server mig
On Tue, May 16, 2017 at 10:31 AM, Alex Gaynor wrote:
> While the internet is moderately good at handling a single cross-sign
> (modulo the challenges we had with 1024-bit root deprecation due to a bug
> in OpenSSL's path building -- now fixed), as we extend the chains, it seems
> evident to me th
On Tue, May 16, 2017 at 10:27 AM, Rob Stradling
wrote:
> On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
>
>> Ryan,
>>
>> If you look at the wide range of user agents accessing google.com today
>> you'd see many legacy applications and older versions of browsers and
>> custom brows
[mailto:agay...@mozilla.com]
Sent: Tuesday, May 16, 2017 10:31 AM
To: Rob Stradling
Cc: Doug Beattie ; r...@sleevi.com; Peter Gutmann
; Gervase Markham ; Nick Lamb
; MozPol ;
Cory Benfield
Subject: Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser
Consumption
While the internet is
On Tue, May 16, 2017 at 10:24 AM, Alex Gaynor wrote:
> Hi Ryan,
>
> I've lost the thread on how this addresses Cory's original problem
> statement, if you could spell that out that'd be very helpful.
>
Sure, the original problem statement arises from the fact that CAs have
'limited trust' applie
While the internet is moderately good at handling a single cross-sign
(modulo the challenges we had with 1024-bit root deprecation due to a bug
in OpenSSL's path building -- now fixed), as we extend the chains, it seems
evident to me that server operators are unlikely to configure their servers
to
On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
Ryan,
If you look at the wide range of user agents accessing google.com today you'd
see many legacy applications and older versions of browsers and custom browsers
built from variants of the commercial browsers. By the time all/mo
On Tue, May 16, 2017 at 9:45 AM, Doug Beattie
wrote:
> Ryan,
>
> If you look at the wide range of user agents accessing google.com today
> you'd see many legacy applications and older versions of browsers and
> custom browsers built from variants of the commercial browsers. By the
> time all/mos
Hi Ryan,
I've lost the thread on how this addresses Cory's original problem
statement, if you could spell that out that'd be very helpful.
Alex
On Tue, May 16, 2017 at 10:22 AM, Ryan Sleevi wrote:
>
>
> On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann
> wrote:
>
>> Ryan Sleevi writes:
>>
>> >I
On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann
wrote:
> Ryan Sleevi writes:
>
> >I can't help but feel you're raising concerns that aren't relevant.
>
> CAs issue roots with effectively infinite (20 to 40-year) lifetimes because
> it's too painful to do otherwise. You're proposing instead:
>
T
gn@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Tuesday, May 16, 2017 7:48 AM
> To: Peter Gutmann
> Cc: Nick Lamb ; MozPol pol...@lists.mozilla.org>; Alex Gaynor ; Cory Benfield
> ; Ryan Sleevi ; Gervase Markham
>
> Subject: Re: [FOR
Michael Casadevall via dev-security-policy
writes:
>I learned something new today. I'm about to run out the door right now so I
>can't read the RFCs but do you know off the top of your head why that was
>removed?
>From the PKIX RFC? There was never any coherent reason given, it just got
turned
On 05/16/2017 08:40 AM, Rob Stradling wrote:
> On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
>
>> Just spitballing ideas here, but in Alex's case, part of me would be
>> tempted to see if X509 could be extended with a new "CanIssueUntil"
>> field. Basically, it would act as
On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
Just spitballing ideas here, but in Alex's case, part of me would be
tempted to see if X509 could be extended with a new "CanIssueUntil"
field. Basically, it would act as an off switch for CA:TRUE after a
given date, but certif
On 05/16/2017 06:05 AM, Peter Gutmann wrote:
> Ryan Sleevi via dev-security-policy
> writes:
>
> Unless someone has a means of managing frequent updates of the root
> infrastructure (and there isn't one, or at least none that work), this will
> never fly. There's a reason why roots have 20-40 y
Ryan Sleevi writes:
>I can't help but feel you're raising concerns that aren't relevant.
CAs issue roots with effectively infinite (20 to 40-year) lifetimes because
it's too painful to do otherwise. You're proposing instead:
require that all CAs must generate (new) roots on some interval (e.
On Tue, May 16, 2017 at 7:19 AM, Peter Gutmann
wrote:
> Ryan Sleevi writes:
>
> >Mozilla updates every six to eight weeks. And that works. That's all that
> >matters for this discussion.
>
> Do all the world's CAs know this?
Does that matter, if all participants in Mozilla's Root Program _coul
Ryan Sleevi writes:
>Mozilla updates every six to eight weeks. And that works. That's all that
>matters for this discussion.
Do all the world's CAs know this?
Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
ht
On Tue, May 16, 2017 at 6:05 AM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan Sleevi via dev-security-policy
> writes:
>
> >An alternative solution to the ossification that Alex muses about is to
> >require that all CAs must generate (new) roots on s
Ryan Sleevi via dev-security-policy
writes:
>An alternative solution to the ossification that Alex muses about is to
>require that all CAs must generate (new) roots on some interval (e.g. 3
>years) for inclusion. That is, the 'maximum' a root can be included in a
>Mozilla product is 3 years (or
30 matches
Mail list logo