Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of May 2017 Audit Reminder Emails Date: Tue, 16 May 2017 19:00:29 + (GMT) Mozilla: Audit Reminder Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 Standard Audit:

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

-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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

> 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 >>

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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,

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

RE: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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 might not know which roots it has? From: Alex Gaynor

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

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 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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Configuring Graduated Trust for Non-Browser Consumption

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

RE: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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/most users upgraded to new browsers, it would be time to change

Re: Configuring Graduated Trust for Non-Browser Consumption

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,

Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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.

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

在 2017年5月16日星期二 UTC+8上午5:19:14，Patrick Tronnier写道： > Greetings, I have reviewed your second BR self-assessment > (https://bugzilla.mozilla.org/attachment.cgi?id=8860627) against your updated > CP/CPS (CP V1.6, CPS V4.5, EV CP V1.4, and EV CPS V1.5) and provided the > following comments and/or

Re: April CA Communication: Results

Jakob Bohm via dev-security-policy writes: >Indeed, I strongly suspect Microsoft *customers* combined with Microsoft >untrustworthiness (they officially closed their Trustworthy Computing >initiative!) may be the major hold out, specifically: > >1. [...]

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

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

Re: Symantec: Update

On 05/16/2017 03:50 AM, Michael Casadevall wrote: > On 05/15/2017 06:05 PM, Jakob Bohm wrote: >> > > - A three-day grace period shall be in place from the issuance date of > a certificate to when it must be in the CT logs for validation reasons > (this is in line with other proposals here). > >

Re: Symantec: Update

On 05/15/2017 06:05 PM, Jakob Bohm wrote: > > Ok, that's much better. > Yay for reasonable courses of action. We'll see if it goes into the next proposal. >> I can see the point here, but I'm not sure I agree. Every time we keep >> digging, we keep finding more and more problems with these