Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
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, you have an independent timestamp you can check beside the NotBefore value, and can independently confirm since CT logs are append-only. (Granted, I realize nothing actually checks the SCT in this way to my knowledge, but the idea itself may be on semi-solid ground). Yes, and I guess that's the reason why with code signing they also use a timestamp service. And I guess we could require either an SCT or a timestamp if they want signatures to remain valid. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
-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 SCT, you have an independent timestamp you can check beside the NotBefore value, and can independently confirm since CT logs are append-only. (Granted, I realize nothing actually checks the SCT in this way to my knowledge, but the idea itself may be on semi-solid ground). Michael -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJZHDLHAAoJEHM+GkLSJHY5rnAP/A7Y7x0B5yr/t3ft5Ua4k5BP P1EKD/Oguwf2QqTiBYgvuKOvdc8aCkOCoVXcq9awyERUzxpW/Pcvz5bOfLLyYY8v qLLFTAXylJSJvFCSlw8+M1aiFEcTzeVptOUl51yQbBxxooWh4Oc8BrhvBZsCZqO3 j5KEWKo7kGLN0pAfocXDHBktb3DVJBnQnyakrUFooz0BgoH+cfJ2te/dSSSNspvw TfPfydWC/ANg7FBkvuc4cZrH3PSGEfpnR7kcvFTfD56Pg2Q90i46gS3ikGdqHaA0 F3GOQ456J0sFpM3wjmIVvLV6OKnQG0jBNicrkyYOydw+YHTVwyhJN12VT7kAlYdc HUVdl18T+Fx2waf/J8sQLyrYoE8QQ0nEZ+8DC4/XXe7gkxwxSFfvD8fUTLnYRI8F TNfq1D+DnIQIQsEDEX5PYfgRAgNohKhzy6L+btLeyqLsqI1Vxak3cCJ40Zl68Pj8 NpTSvPchlSiUZNPRDD6moRIJdsSIfEGPDn6jjOntw4Go3gwg67jPl8btePBM3VWD 9WRAy6KGdX5rRWsrvH1Zrrmeqjsqe8kQ6t3vGbuU0Qcd7hDT4EoDWWTRafy8Nsbc BIag3UXSWtF27LLpw/0C+6wPDT9krdl01JMTPwc0li0tYYL8h7W3FfHe8jMvnOmT Z0bUn1hiBjaFftVpdlM0 =RWD4 -END PGP SIGNATURE- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
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 was compromised/factored/physically stolen, our only recourse would be to remove them from the root store, and deal with half the internet breaking. Would be nice if that could not be a thing. If the key is compromised, you can't rely on any date information anymore, you need to revoke it completely and break things. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 would be useful to enumerate the reasons why "there should not be a non-linear path" rather than just assume it to be fact. ;-) You mean I can't just spout opinion here without substantiating it? ;) You can do that if you want, but I tend to find well-reasoned arguments to be more persuasive. ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 accept "certs-only" CMS messages.' > > Out of interest, which particular clients chase AIA->caIssuers HTTP URLs > but ignore that "SHOULD"? > (I know CryptoAPI has accepted "certs-only" CMS messages since XP, but > I've not checked any other implementations). Selfishly, Chrome :) Less selfishly, macOS (see tpIssuerCertViaNet, which just creates a TPCertInfo with the response data, aka 'DER-encoded X.509v3 cert') Even the NSS implementation (by way of libpkix's AIA mgr calling CERT_DecodeCertPackage) doesn't "properly" implement the defined bits :) Just enough to get you close enough ;) > 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 would be useful to enumerate the > reasons why "there should not be a non-linear path" rather than just assume > it to be fact. ;-) You mean I can't just spout opinion here without substantiating it? ;) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 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 set the AIA->caIssuers content to be a PKCS#7 "group of cross-certs" ? 1) Clients don't widely support PKCS#7 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 messages.' Out of interest, which particular clients chase AIA->caIssuers HTTP URLs but ignore that "SHOULD"? (I know CryptoAPI has accepted "certs-only" CMS messages since XP, but I've not checked any other implementations). 2) LOL PKCS#7 is a tirefire 3) Because that's an added/unnecessarily complexity to the PKI which is pretty detrimental compared to a linearized path. Sure, it's certainly added complexity. I presume, but perhaps you can clarify, that the 'group of cross-certs' is meant to cover the case where you have roots A, B, C, where A was created a T-6, B at T-3, and C at T0, with an intermediate I issuing leaf L I presume that your goal is that rather than expressing: L -> I -> C -> B -> A That you want to express L -> I -> C -> C2 (via AIA) -> B -> C3 (via AIA) -> A > Is that correct? That's what my question was about, yes. 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 would be useful to enumerate the reasons why "there should not be a non-linear path" rather than just assume it to be fact. ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 (potentially blowing INITCWND and back to same round trips) :) (I'm ignoring the other factors, such as that the HTTP cache would have it, or Mozilla persisting observed intermediates to the NSS store, both of which also would eliminate those gains :P) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 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 set the AIA->caIssuers content to be a >> PKCS#7 "group of cross-certs" ? > > > 1) Clients don't widely support PKCS#7 > 2) LOL PKCS#7 is a tirefire > 3) Because that's an added/unnecessarily complexity to the PKI which is > pretty detrimental compared to a linearized path. > > I presume, but perhaps you can clarify, that the 'group of cross-certs' is > meant to cover the case where you have roots A, B, C, where A was created a > T-6, B at T-3, and C at T0, with an intermediate I issuing leaf L > > I presume that your goal is that rather than expressing: > L -> I -> C -> B -> A > > That you want to express > > L -> I -> C > -> C2 (via AIA) -> B > -> C3 (via AIA) -> A > > Is that correct? 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? > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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, 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 set the AIA->caIssuers content to be a > PKCS#7 "group of cross-certs" ? 1) Clients don't widely support PKCS#7 2) LOL PKCS#7 is a tirefire 3) Because that's an added/unnecessarily complexity to the PKI which is pretty detrimental compared to a linearized path. I presume, but perhaps you can clarify, that the 'group of cross-certs' is meant to cover the case where you have roots A, B, C, where A was created a T-6, B at T-3, and C at T0, with an intermediate I issuing leaf L I presume that your goal is that rather than expressing: L -> I -> C -> B -> A That you want to express L -> I -> C -> C2 (via AIA) -> B -> C3 (via AIA) -> A Is that correct? 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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 set the AIA->caIssuers content to be a PKCS#7 "group of cross-certs" ? Unquestionably, this means that performance gets worse for sites who support clients that do not support AIA and who serve the extra (potentially unnecessary) chains. This does put a certain pressure on these clients _to_ support AIA, and the performance implications would only become worse the longer the legacy clients exist. However, if/when 'enough' clients support AIA (or automatic updates), the performance costs evaporate. This helps create a virtuous cycle in which site operators are incentivized to support clients that support AIA/automatic updates, and software developers are incentivized to provide clients that support AIA/automatic updates :) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 store since the > web server might not know which roots it has? > Doug: Yes, that was the substance of the original proposal, when it posed the following: On Y3, you generate new root and new intermediate, and then cross-sign, > such that you have > (old root) -> (old intermediate) -> (old existing certs) >-> (new root) -> (new intermediate) -> (new leaf certs) > Sites can either rely on AIA (Ideal, but unfortunately, not yet supported > by Mozilla) or simply supply the full chain (less ideal, wasteful on > bandwidth and caching), of either > (site cert) -> (new intermediate) -> (new root) [the AIA path] > (site cert) -> (new intermediate) -> (new root) -> (old root) [the slow, > compatibility path] 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. Unquestionably, this means that performance gets worse for sites who support clients that do not support AIA and who serve the extra (potentially unnecessary) chains. This does put a certain pressure on these clients _to_ support AIA, and the performance implications would only become worse the longer the legacy clients exist. However, if/when 'enough' clients support AIA (or automatic updates), the performance costs evaporate. This helps create a virtuous cycle in which site operators are incentivized to support clients that support AIA/automatic updates, and software developers are incentivized to provide clients that support AIA/automatic updates :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
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 that server operators are unlikely to configure their servers > to serve a chain which works on all clients -- the likely result is clients > will need AIA chasing. Most (all?) non-browsers do not implement AIA > chasing. This isn't an objection, just a flag and a potential action item > on the "non-browser" side of this. > That's basically an argument of "assume we change nothing" :) Yes, this proposal would impose some degree of change - either on server operators (of which tools already exist, such as Cloudflare's excellent cfssl - https://github.com/cloudflare/cfssl ) or on non-browser consumers (to support AIA). My view of AIA is that it is decentralized, distributed update mechanisms for the Web PKI. Either we presume these clients also support revocation checking (in which case, the incremental cost of AIA is negligible, regardless of whether it's OneCRL-style or OCSP/CRL style) or we assume they do not (in which case, they're in a tricky spot re: security anyways, and are not reasonable to consider "in scope") ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 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 >> the roots out again and this will impact the ability for web site operators >> to enable TLS for all visitors. >> >> Before we can implement a short Root usage policy we'd need to convince >> all browsers to follow a process for rapid updates of root stores. >> > > Hi Doug. > > Imagine a root cert A, valid for a short duration; and a root cert B, > valid for a long duration. > Note: I was *not* proposing that the root's validity (e.g. expiration time) be expressed. Merely it's duration/participation in the Mozilla store. This purposefully allows 'never-updating' clients to continue to consume the store (within the bounds of the root validity), while allowing 'frequently-updated' clients - e.g. what Mozilla actually ships - to maintain a more agile basis of trust. > > Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas > other less agile root stores would contain B. > > A doesn't have to be in every root store, because B can cross-certify A. > (Let's call the cross-certificate A'). > > A widely compatible cert chain would therefore look like this: > B -> A' -> Intermediate -> Leaf > > If you're already cross-certifying from an older root C, then an even more > widely compatible cert chain would look like this: > C -> B' -> A' -> Intermediate -> Leaf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 [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 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 serve a chain which works on all clients -- the likely result is clients will need AIA chasing. Most (all?) non-browsers do not implement AIA chasing. This isn't an objection, just a flag and a potential action item on the "non-browser" side of this. Alex On Tue, May 16, 2017 at 10:27 AM, Rob Stradling mailto:rob.stradl...@comodo.com>> 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<http://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 the roots out again and this will impact the ability for web site operators to enable TLS for all visitors. Before we can implement a short Root usage policy we'd need to convince all browsers to follow a process for rapid updates of root stores. Hi Doug. Imagine a root cert A, valid for a short duration; and a root cert B, valid for a long duration. Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas other less agile root stores would contain B. A doesn't have to be in every root store, because B can cross-certify A. (Let's call the cross-certificate A'). A widely compatible cert chain would therefore look like this: B -> A' -> Intermediate -> Leaf If you're already cross-certifying from an older root C, then an even more widely compatible cert chain would look like this: C -> B' -> A' -> Intermediate -> Leaf -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 'limited trust' applied to them, and wanting to express this for use in other applications which consume the Mozilla trust store. First and foremost, in order for that limited trust to be relevant/applicable, we must presume these clients are capable of being updated. If they weren't, any expression of limited trust would be irrelevant, since they wouldn't consume the update. At best, it would simply ensure that, at a fixed point in time (e.g. when the application was built), to the best of the app devs knowledge, all roots were constrained appropriately. As we've seen from CA issues - whether Symantec or the top 5 CAs responsible for >90% of the Web's public trust - there's a whole host of complex scenarios involved with distrusting. Cory's problem also highlighted that there are a host of non-web consumers of the Mozilla trust store, and their compatibility needs are different. By posing the 'shorter lived root' scenario, we get to a scenario where a device that is staying up to date (e.g. tracking the Mozilla store at a frequency where 'limited trust' is applicable) is able to migrate off 'problematic' roots sooner, by providing a transition path that is constantly moving forward. Thus, rather than needing to express 'limited trust' for roots (which otherwise remain trusted), we provide a faster path to distrusting the problematic roots, independent of whatever trust is afforded the organization (which might have 'new' roots that are less/unconstrained) This is in conjunction with the expressions already found in certdata.txt which applications can use (e.g. name constraints). It doesn't address scenarios like whitelisting (e.g. CNNIC), since those are application-specific anyways. The proposal is meant to, in parallel, reduce the 'legacy compat risk' by providing a path to allow both 'legacy' and 'modern' clients to operate side-by-side, without indefinite expressions of constraints on 'legacy' roots. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 serve a chain which works on all clients -- the likely result is clients will need AIA chasing. Most (all?) non-browsers do not implement AIA chasing. This isn't an objection, just a flag and a potential action item on the "non-browser" side of this. Alex 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 browsers built from variants of the commercial browsers. By the >> time all/most users upgraded to new browsers, it would be time to change >> the roots out again and this will impact the ability for web site operators >> to enable TLS for all visitors. >> >> Before we can implement a short Root usage policy we'd need to convince >> all browsers to follow a process for rapid updates of root stores. >> > > Hi Doug. > > Imagine a root cert A, valid for a short duration; and a root cert B, > valid for a long duration. > > Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas > other less agile root stores would contain B. > > A doesn't have to be in every root store, because B can cross-certify A. > (Let's call the cross-certificate A'). > > A widely compatible cert chain would therefore look like this: > B -> A' -> Intermediate -> Leaf > > If you're already cross-certifying from an older root C, then an even more > widely compatible cert chain would look like this: > C -> B' -> A' -> Intermediate -> Leaf > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 all/most users upgraded to new browsers, it would be time to change the roots out again and this will impact the ability for web site operators to enable TLS for all visitors. Before we can implement a short Root usage policy we'd need to convince all browsers to follow a process for rapid updates of root stores. Hi Doug. Imagine a root cert A, valid for a short duration; and a root cert B, valid for a long duration. Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas other less agile root stores would contain B. A doesn't have to be in every root store, because B can cross-certify A. (Let's call the cross-certificate A'). A widely compatible cert chain would therefore look like this: B -> A' -> Intermediate -> Leaf If you're already cross-certifying from an older root C, then an even more widely compatible cert chain would look like this: C -> B' -> A' -> Intermediate -> Leaf -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 browsers. By the > time all/most users upgraded to new browsers, it would be time to change > the roots out again and this will impact the ability for web site operators > to enable TLS for all visitors. > No, it won't. Perhaps you missed the scenario where the old root (e.g. what these legacy devices use) cross-signs the new root. From the perspective of these old clients, there's always a contiguous path of trust. You can see this, of course, simply by looking at Google.com - which already shows this happening, because GIAG2 is signed by GeoTrust Global CA (a root in new clients), which is signed by Equifax Secure Certificate Authority (a root in older clients) As you can see, this is the most commonly practiced form of deployment. GlobalSign itself regularly does this - old roots sign new roots, new roots are included for new clients, but the path to the old root is continued for ubiquity. This is literally nothing new :) The only thing that changes is that Mozilla could require that, on some cadence (e.g. every 3 years), new roots are rolled. This allows another cadence (e.g. 5 years) of removing the 'old' roots and only keeping the 'new' roots. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 > 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: >> > > That's not an appropriate summary of the issues, but equally, as I already > described, and perhaps could work through with you if you had further > questions (rather than criticisms), that the 'too painful' scenario is > still meaningfully addressed. > > >> >> require that all CAs must generate (new) roots on some interval (e.g. 3 >> years) for inclusion. >> >> (that's quoted from the original message I replied to). How do you >> propose >> that Mozilla is going to get every commercial CA on earth to do this? >> > > The same way we in the Mozilla community have made progress for the past > decade - https://www.mozilla.org/en-US/about/governance/policies/ > security-group/certs/policy/ > > It's fairly easy to submit PRs to https://github.com/mozilla/pkipolicy > and discuss. Perhaps we can discuss the substance of the proposal, and work > through any confusion or misunderstanding, rather than suggesting it's not > possible because it's hard (of which both are not correct) > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 do otherwise. You're proposing instead: > That's not an appropriate summary of the issues, but equally, as I already described, and perhaps could work through with you if you had further questions (rather than criticisms), that the 'too painful' scenario is still meaningfully addressed. > > require that all CAs must generate (new) roots on some interval (e.g. 3 > years) for inclusion. > > (that's quoted from the original message I replied to). How do you propose > that Mozilla is going to get every commercial CA on earth to do this? > The same way we in the Mozilla community have made progress for the past decade - https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ It's fairly easy to submit PRs to https://github.com/mozilla/pkipolicy and discuss. Perhaps we can discuss the substance of the proposal, and work through any confusion or misunderstanding, rather than suggesting it's not possible because it's hard (of which both are not correct) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 the roots out again and this will impact the ability for web site operators to enable TLS for all visitors. Before we can implement a short Root usage policy we'd need to convince all browsers to follow a process for rapid updates of root stores. GlobalSign visitors use Nokia, NetFront, SeaMonkey, Amazon Silk, Blackberry and others, and assume ecommerce sites have even more legacy user agents (at percentages they cannot ignore). We'd need to be sure that these vendors change how they manage their root stores before we move to short use Roots (maybe some of them relay on the underlying operating system already and these are not all an issue). Mobile devices will perhaps be the most challenging as their OS support lifetime is relatively short but users hang onto them for longer. For example, Android 4.1 and 4.2 account for about 7% of the Android market share: https://developer.android.com/about/dashboards/index.html Android browser has about 6% market share: https://www.netmarketshare.com/browser-market-share.aspx?qprid=1&qpcustomb=1 but Android 4.1 and 4.2 are no longer supported: https://www.extremetech.com/mobile/197346-google-throws-nearly-a-billion-android-users-under-the-bus-refuses-to-patch-os-vulnerability Sure, 6% of 7% is around .5%, so in itself not a huge driver, but add up the other unsupported Android versions and those of all other mobile devices and this will become more meaningful. Under your proposal, how would you see mobile device manufacturers as well as OS and browser vendors supporting the requirement to keep updating root stores even after the end of support? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@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: [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 participants in Mozilla's Root Program _could_ know > this? > > I can't help but feel you're raising concerns that aren't relevant. Perhaps I > didn't explain sufficiently why even if a client takes a single copy of the > Mozilla root store and *never updates after that*, things could still work for > 20+ years for those clients, and with reduced risk for Mozilla users. I feel > like > if that point had been clearer, perhaps you would understand why it could fly. > > Perhaps you're confused and think the roots themselves have 5 year validity > (e.g. notBefore to notAfter). That's also not what I said - I said bound the > time > for inclusion of that root in Mozilla products. They're very different things, > you see, and the latter doesn't prescribe the validity period of the root - > precisely so it can support such broken 'legacy' cases without requiring too > much of the world to adopt modern security practices. > > That said, Mozilla's mission to ensure the Internet is a global public > resource > that is safe would, among other things, entitle them to push this particular > vision, since it would help make users safe. However, I merely proposed a > smaller step in that. > > Perhaps you could re-read the proposal with a fresh perspective, as I hope it > might become clearer how it could address many of these issues. As it relates > to the topic at hand, by limiting the lifetime of the roots themselves, it > reduces the risk/need to impose additional contraints - there are fewer legacy > roots, they're bounded in validity period, and things move onward towards > distrust much easier. That does seem a net-positive for the ecosystem. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 coherent reason given, it just got turned into a no-no. (Note the qualifier "coherent". There were various reasons proposed for removing it, but none that made any sense). Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 an off switch for CA:TRUE after a >> given date, but certificates signed before that would still be valid for >> that root, and then can be wound down beyond that point. > > That sounds like the "Private Key Usage Period" extension, which was > present in RFC3280 but removed in RFC5280. > > https://tools.ietf.org/html/rfc3280#section-4.2.1.4 > 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? Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 certificates signed before that would still be valid for that root, and then can be wound down beyond that point. That sounds like the "Private Key Usage Period" extension, which was present in RFC3280 but removed in RFC5280. https://tools.ietf.org/html/rfc3280#section-4.2.1.4 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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. There's a reason why roots have 20-40 year lifetimes and why they > get on-sold endlessly across different owners rather than simply being > replaced when required. > > Peter. > Arguably, this would be a nice thing to fix since it could help reduce issues with CA's changing owners. If we could update root stores retroactively, it would make a lot of migrations simpler. For example, if a device took the entire Mozilla root store before CNNIC was booted out, those devices would still trust those certificates. Given the glacier pace some things update at, having a type of root agility would be rather desirable. 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 certificates signed before that would still be valid for that root, and then can be wound down beyond that point. 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 was compromised/factored/physically stolen, our only recourse would be to remove them from the root store, and deal with half the internet breaking. Would be nice if that could not be a thing. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 some interval (e.g. 3 years) for inclusion. (that's quoted from the original message I replied to). How do you propose that Mozilla is going to get every commercial CA on earth to do this? Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 participants in Mozilla's Root Program _could_ know this? I can't help but feel you're raising concerns that aren't relevant. Perhaps I didn't explain sufficiently why even if a client takes a single copy of the Mozilla root store and *never updates after that*, things could still work for 20+ years for those clients, and with reduced risk for Mozilla users. I feel like if that point had been clearer, perhaps you would understand why it could fly. Perhaps you're confused and think the roots themselves have 5 year validity (e.g. notBefore to notAfter). That's also not what I said - I said bound the time for inclusion of that root in Mozilla products. They're very different things, you see, and the latter doesn't prescribe the validity period of the root - precisely so it can support such broken 'legacy' cases without requiring too much of the world to adopt modern security practices. That said, Mozilla's mission to ensure the Internet is a global public resource that is safe would, among other things, entitle them to push this particular vision, since it would help make users safe. However, I merely proposed a smaller step in that. Perhaps you could re-read the proposal with a fresh perspective, as I hope it might become clearer how it could address many of these issues. As it relates to the topic at hand, by limiting the lifetime of the roots themselves, it reduces the risk/need to impose additional contraints - there are fewer legacy roots, they're bounded in validity period, and things move onward towards distrust much easier. That does seem a net-positive for the ecosystem. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 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 less!) > > 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 year lifetimes and why > they > get on-sold endlessly across different owners rather than simply being > replaced when required. Mozilla updates every six to eight weeks. And that works. That's all that matters for this discussion. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 included in a >Mozilla product is 3 years (or less!) 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 year lifetimes and why they get on-sold endlessly across different owners rather than simply being replaced when required. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
