Re: Mozilla Policy and CCADB Disclosure scope

On Wednesday, May 31, 2017 at 10:34:34 AM UTC-5, Gervase Markham wrote: > However, that discussion suggests to me that we should do the following: > > * Given CT, and the need within it to disclose TCSCs, the privacy > argument seems to have been abandoned. So I think it's reasonable to > also

Re: Mozilla Policy and CCADB Disclosure scope

On 19/05/17 14:47, Gervase Markham wrote: > We need to have a discussion about the appropriate scope for: > > 1) the applicability of Mozilla's root policy > 2) required disclosure in the CCADB I've now reviewed the previous discussion we had on this topic, here:

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 3:45 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, May 23, 2017 at 12:39:05 PM UTC-5, Ryan Sleevi wrote: > > > Setting aside even the 'damage' aspect, consider the ecosystem impact. > > Assume a wildwest - we

Re: Mozilla Policy and CCADB Disclosure scope

On Tuesday, May 23, 2017 at 12:39:05 PM UTC-5, Ryan Sleevi wrote: > Setting aside even the 'damage' aspect, consider the ecosystem impact. > Assume a wildwest - we would not have been able to effectively curtail and > sunset SHA-1. We would not have been able to deploy and require Certificate >

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 12:33 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I just think there's no need to concern themselves if someone quite clever > (whatever that means) decides to ASN.1 encode a Trollface GIF and roll that > into an EE cert

Re: Mozilla Policy and CCADB Disclosure scope

On 23/05/2017 18:18, Ryan Sleevi wrote: On Tue, May 23, 2017 at 11:52 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Note as this is about a proposed future policy, this is about validation code updated if and when such a policy is enacted. Current

Re: Mozilla Policy and CCADB Disclosure scope

On Tuesday, May 23, 2017 at 10:53:03 AM UTC-5, Jakob Bohm wrote: > > Or could this be solved by require such "TCSC light" SubCA certs to > carry a specific CAB/F policy OID with CT-based community enforcement > that all SubCA certs with this policy OID comply with the more stringent >

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 11:52 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Note as this is about a proposed future policy, this is about validation > code updated if and when such a policy is enacted. Current validation > code has no reason to check a

Re: Mozilla Policy and CCADB Disclosure scope

On 23/05/2017 16:22, Ryan Sleevi wrote: On Tue, May 23, 2017 at 9:45 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: * TCSCs can, by their existing definition, be programmatically recognized by certificate validation code e.g. in browsers and other

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 9:45 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > * TCSCs can, by their existing definition, be programmatically > recognized by certificate validation code e.g. in browsers and other > clients. > In theory, true. In practice,

Re: Mozilla Policy and CCADB Disclosure scope

On 22/05/2017 19:41, Matthew Hardeman wrote: On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: So your proposal is that technical requirements should be enforced in-product rather than in-policy, and so effectively there's no need for policy for the EE certs under a TCSC.

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 9:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I even concede that that alone does create a potential for compatibility > issues should a need arise to make a global web pki-wide change to > certificate issuance (say,

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 7:24:42 PM UTC-5, Ryan Sleevi wrote: > https://groups.google.com/d/msg/mozilla.dev.security.policy/yS_L_OgI5qk/OhLX9iyZBAAJ > specifically proposed > > "For example, no requirement of audit by the enterprise holding the > technically constrained intermediate, and no

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 7:58 PM, Peter Bowen wrote: > > Why do you need to add 10,000 communication points? A TCSC is, by > definition, a subordinate CA. The WebPKI is not a single PKi, is a > set of parallel PKIs which do not share a common anchor. The browser > to CA

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 12:21 PM, Ryan Sleevi via dev-security-policy wrote: > Consider, on one extreme, if every of the Top 1 sites used TCSCs to > issue their leaves. A policy, such as deprecating SHA-1, would be > substantially harder, as now there's

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 5:35 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > It is within the above that I can see a real problem in making more broad > use of TCSCs problematic. If the browser community does not effectively > move in the fashion

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 3:50:30 PM UTC-5, Ryan Sleevi wrote: > Right, but I reject that :) > I hope to better understand your position. In transitioning from a long time lurker to actively commenting on this list, it is my hope to contribute what that I usefully can, bow out gracefully

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 4:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I'm not certain that I accept the premise that TCSCs fundamentally or > substantively change that dynamic. Particularly if the validity period of > the TCSC is limited in

Re: Mozilla Policy and CCADB Disclosure scope

> > Right now the list excludes anything with a certain set of name > constraints and anything that has EKU constraints outside the in-scope > set. I'm suggesting that the first "layer" of CA certs always should > be disclosed. > I understand now. In that, I fully concur.

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 1:02 PM, Matthew Hardeman via dev-security-policy wrote: > On Monday, May 22, 2017 at 2:43:14 PM UTC-5, Peter Bowen wrote: > >> >> I would say that any CA-certificate signed by a CA that does not have >> name constraints and not

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:21:41 PM UTC-5, Ryan Sleevi wrote: > > > Regarding specifically the risk of the holder of a technically > > > constrained subCA issuing a certificate with an SHA-1 signature or > > > other improper signature / algorithm, my belief at this time is that > > > with

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:43:14 PM UTC-5, Peter Bowen wrote: > > I would say that any CA-certificate signed by a CA that does not have > name constraints and not constrained to things outside the set > {id-kp-serverAuth, id-kp-emailProtection, anyEKU} should be disclosed. > This would mean

Re: Mozilla Policy and CCADB Disclosure scope

On Fri, May 19, 2017 at 6:47 AM, Gervase Markham via dev-security-policy wrote: > We need to have a discussion about the appropriate scope for: > > 1) the applicability of Mozilla's root policy > 2) required disclosure in the CCADB > > The two questions are

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:14:57 PM UTC-5, Ryan Sleevi wrote: > Another approach is to make an argument that such validations are already > accounted for in the EV Guidelines, in which a certificate may be issued > for 27 months, but for which the domain must be revalidated at 13 months. > In

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 12:50 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 22/05/17 16:43, Matthew Hardeman wrote: > > Regarding specifically the risk of the holder of a technically > > constrained subCA issuing a certificate with an SHA-1

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 1:41 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > > > How do the various validation routines in the field today validate a > > > scenario in which a

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > So your proposal is that technical requirements should be enforced > in-product rather than in-policy, and so effectively there's no need for > policy for the EE certs under a TCSC. > > This is not an unreasonable position. >

Re: Mozilla Policy and CCADB Disclosure scope

On 22/05/17 16:43, Matthew Hardeman wrote: > Regarding specifically the risk of the holder of a technically > constrained subCA issuing a certificate with an SHA-1 signature or > other improper signature / algorithm, my belief at this time is that > with respect to the web PKI, we should be able

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 3:41:50 AM UTC-5, Gervase Markham wrote: > On 19/05/17 20:40, Matthew Hardeman wrote: > > Not speaking as to the status quo, but rather in terms of > > updates/changes which might be considered for incorporation into > > policy would be to recognize the benefit of name

Re: Mozilla Policy and CCADB Disclosure scope

On 19/05/17 20:40, Matthew Hardeman wrote: > Not speaking as to the status quo, but rather in terms of > updates/changes which might be considered for incorporation into > policy would be to recognize the benefit of name constrained > intermediates and allow a reduction in burden to entities

Re: Mozilla Policy and CCADB Disclosure scope

Thanks, Nick, for the comment on the scope difference in the dnsName constraints vs. SAN wildcard. I hadn't contemplated that. As you note, the real risk isn't dissimilar. (I would presume that this is because a CA willing to issue a SAN dnsName of *.example.com would also presumably issue a

Re: Mozilla Policy and CCADB Disclosure scope

On Friday, 19 May 2017 20:41:20 UTC+1, Matthew Hardeman wrote: > From a perspective of risk to the broader web PKI, it would appear that a > properly name constrained intermediate with (for example) only the Server > and Client TLS authentication ekus with name constraints limited to >

Re: Mozilla Policy and CCADB Disclosure scope

Not speaking as to the status quo, but rather in terms of updates/changes which might be considered for incorporation into policy would be to recognize the benefit of name constrained intermediates and allow a reduction in burden to entities holding and utilizing name constrained intermediates,