On 17/05/17 12:55, Jakob Bohm wrote:
> That is /human readable/ information, not /computer readable/ data that
> can be imported by other libraries when those are used with the Mozilla
> root program.
Yes, indeed. But you asked where in certdata.txt those things are, and
that page explains pretty
On 17/05/2017 13:29, Gervase Markham wrote:
On 16/05/17 18:04, Jakob Bohm wrote:
Could you please point out where in certdata.txt the following are
expressed, as I couldn't find it in a quick scan:
1. The date restrictions on WoSign-issued certificates.
2. The EV trust bit for some CAs.
I
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,
On 16/05/17 18:04, Jakob Bohm wrote:
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.
I am surprised you are engaging in a
-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
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
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
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
On Tue, May 16, 2017 at 1:59 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy
> wrote:
> > On 16/05/2017 19:36, Peter Bowen wrote:
> >>
> >> My
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
On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy
wrote:
> On 16/05/2017 19:36, Peter Bowen wrote:
>>
>> My experience is that Mozilla is very open to taking patches and will
>> help contributors get things into acceptable form, so I'm
On Tue, May 16, 2017 at 10:04 AM, Jakob Bohm via dev-security-policy
wrote:
> On 16/05/2017 18:10, Peter Bowen wrote:
>>
>> On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
>> wrote:
>>>
>>> Your
On 05/16/2017 01:04 PM, Jakob Bohm wrote:
>
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.
>
Not the OP, but WoSign
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/16/2017 11:10 AM, Peter Bowen wrote:
> Jakob,
>
> What I think Ryan has been trying to express is his view that this
> request is not possible. A *stable* data format is unable to
> express future graduated trust rules.
>
I've been
On 16/05/2017 18:10, Peter Bowen wrote:
On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
wrote:
Your post above is the first response actually saying what is wrong
with the Microsoft format and the first post saying all the
restrictions
On Tue, May 16, 2017 at 12:00 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Your post above is the first response actually saying what is wrong
> with the Microsoft format and the first post saying all the
> restrictions are actually in the certdata.txt
On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
wrote:
> Your post above is the first response actually saying what is wrong
> with the Microsoft format and the first post saying all the
> restrictions are actually in the certdata.txt
On 16/05/2017 17:10, Peter Bowen wrote:
On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy
wrote:
On 13/05/2017 00:48, Ryan Sleevi wrote:
And in the original message, what was requested was
"If Mozilla is interested in doing a
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
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
> On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy
> wrote:
>
> On 13/05/2017 00:48, Ryan Sleevi wrote:
>>
>> And in the original message, what was requested was
>> "If Mozilla is interested in doing a substantial public service, this
>>
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,
On Tue, May 16, 2017 at 10:42 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I suggest you read and understand the OP in this thread, which is
> *entirely* about using the Mozilla Root Store outside Mozilla code.
>
Hi Jakob,
Could I echo Alex's request
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 13/05/2017 00:48, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
suggesting a good format for sharing this info across libraries
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
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
gmail.com>; MozPol <mozilla-dev-security-pol...@lists.mozilla.org>;
Cory Benfield <c...@lukasa.co.uk>
Subject: Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser
Consumption
While the internet is moderately good at handling a single cross-sign (modulo
the challenges
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
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
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
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
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
On Tue, May 16, 2017 at 9:54 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16/05/2017 15:23, Alex Gaynor wrote:
>
>> That's not an appropriate way to participate in a mailing list, please
>> communicate civilly.
>>
>>
> Sorry about the flaming, but he
On 16/05/2017 15:23, Alex Gaynor wrote:
That's not an appropriate way to participate in a mailing list, please
communicate civilly.
Sorry about the flaming, but he was constantly derailing that
particular discussion with this misconception, and I was frankly
getting fed up.
Enjoy
Jakob
c...@lukasa.co.uk>; Ryan Sleevi <r...@sleevi.com>; Gervase Markham
> <g...@mozilla.org>
> Subject: Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser
> Consumption
>
> On Tue, May 16, 2017 at 7:19 AM, Peter Gutmann
> <pgut...@cs.auckland.ac.nz>
&
That's not an appropriate way to participate in a mailing list, please
communicate civilly.
Alex
On Tue, May 16, 2017 at 8:53 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 11/05/2017 18:42, Ryan Sleevi wrote:
>
>> On Thu, May 11, 2017 at 11:57 AM,
On 11/05/2017 18:42, Ryan Sleevi wrote:
On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Ryan,
I think you've correctly highlighted that there's a problem -- the Mozilla
CA store is "designed" to be consumed from NSS, and
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
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
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.
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
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
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
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
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
On Mon, May 15, 2017 at 10:18 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Once upon a time I would said "yes, we should totally encourage people to
> lovingly craft their perfect trust store, to reduce their risk profile".
> Now, not so much.
>
> As
Once upon a time I would said "yes, we should totally encourage people to
lovingly craft their perfect trust store, to reduce their risk profile".
Now, not so much.
As we've seen in numerous discussions, customers of CAs, particularly large
enterprises and vendors (think payment terminals) love
On 15/05/2017 15:19, Gervase Markham wrote:
On 12/05/17 09:18, Cory Benfield wrote:
I try not to decide whether there is interest in features like this:
if they’re easy I’d just implement them and let users decide if they
want it. That’s what I’d be inclined to do here. If Mozilla added
such a
On 12/05/17 09:18, Cory Benfield wrote:
> I try not to decide whether there is interest in features like this:
> if they’re easy I’d just implement them and let users decide if they
> want it. That’s what I’d be inclined to do here. If Mozilla added
> such a flag, I’d definitely be open to adding
> On May 12, 2017, at 3:48 PM, Ryan Sleevi via dev-security-policy
> wrote:
>
> On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> This SubThread (going back to Kurt Roeckx's post
On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
> suggesting a good format for sharing this info across libraries though.
> Discussing that on a list
On 12/05/2017 23:45, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 2:15 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 12/05/2017 20:43, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy <
On Fri, May 12, 2017 at 2:15 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 12/05/2017 20:43, Ryan Sleevi wrote:
> > On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Could
On 12/05/2017 20:43, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Could something be derived from / based on the ASN.1 format apparently
used by Microsoft in it's root store, with OpenSSL/Mozilla OIDs
On Fri, May 12, 2017 at 07:50:46PM +0200, Jakob Bohm via dev-security-policy
wrote:
> On 12/05/2017 10:06, Kurt Roeckx wrote:
> > From past discussion on the OpenSSL list, I understand that we want to
> > support a trust store that supports all such kind of attributes. Some
> > things like for
On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Could something be derived from / based on the ASN.1 format apparently
> used by Microsoft in it's root store, with OpenSSL/Mozilla OIDs added
> for things that have no Microsoft
On 12/05/2017 10:06, Kurt Roeckx wrote:
On 2017-05-11 17:57, Alex Gaynor wrote:
Ryan,
I think you've correctly highlighted that there's a problem -- the
Mozilla
CA store is "designed" to be consumed from NSS, and CA-specific
remediations are a part of that (hash algorithms, maximum certificate
Cory, from your point of view is there interest in being able to tell Requests
"I want the no-compromises trust store" and accept a reduced compatibility in
exchange for knowing that you're a little safer ?
Right now, as a programmer I have three choices with Requests:
Verify=True: The
I think you left this a bit implicit Cory, so I figured it's worth spelling
out: the strength of Mozilla's CA program, as a tool for making the web
stronger, comes from having people using it, that's the carrot that forces
people to meet our standards (also the fact that as a transparent, root
> On 11 May 2017, at 19:27, Gervase Markham wrote:
>
> On 11/05/17 18:05, Alex Gaynor wrote:
>> I don't think Cory's arguing against browsers making use of these types of
>> remediations, he just wants the non-browser clients to be able to
>> participate as well :-)
>
> Sure.
On 11/05/17 18:05, Alex Gaynor wrote:
> I don't think Cory's arguing against browsers making use of these types of
> remediations, he just wants the non-browser clients to be able to
> participate as well :-)
Sure. I'm just heading off that argument at the pass :-)
Gerv
On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Cory,
>
> On 11/05/17 15:21, Cory Benfield wrote:
> > While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can
Hi Cory,
On 11/05/17 15:21, Cory Benfield wrote:
> While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily.
Unfortunately, this is not a good enough reason to remove graduate trust
proposals from our arsenal of
On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan,
>
> I think you've correctly highlighted that there's a problem -- the Mozilla
> CA store is "designed" to be consumed from NSS, and CA-specific
> remediations are a part
Ryan,
I think you've correctly highlighted that there's a problem -- the Mozilla
CA store is "designed" to be consumed from NSS, and CA-specific
remediations are a part of that (hash algorithms, maximum certificate
lifetimes, and any number of other important technical controls).
Unfortunately,
But if you use the trust database without using NSS, you no longer fit into
any of the assumptions or security models with the discussions here on
m.d.s.p.
A good example of this would be EKU related misissuance. NSS, like
CryptoAPI and several other platforms, has for the past 15 or so years
On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote:
> While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily. For
> example, I run a downstream non-browser HTTP client[1] that by default uses a
>
All,
While this ongoing discussion regarding Symantec is going on, I wanted to chime
in quickly to make a suggestion about graduated trust. Many of the proposals
that Mozilla, Google, and other teams running CA programs put forward in cases
of CA misbehaviour is to transition a CA from
71 matches
Mail list logo