Re: Google Plan for Symantec posted
On Sunday, May 21, 2017 at 11:31:54 PM UTC, Michael Casadevall wrote: > There's also a fair number of points dealing with who can sign and for > what while Symantec spins up the new roots (which the Google proposal > says a trusted third party CA signed by Symantec"). > > I'm against this point specifically because third-party CA operations is > how we got into this mess. I agree with your general concern, but the OP states: "These sub-CAs must be operated by a non-affiliated organization that operates roots currently trusted in the Android and Chrome OS trust stores that have been trusted for a period of at least two years." This to me sounds very similar in theory to Certum/Asseco doing OV for WoSign, which on this list has been considered OK. Personally, I'd rather not have any of this CA mixing, 3rd-party delegating, cross-signing of whole trees, root-buying etc. but all this stuff seems to be an integral part of current industry practice.+ I say in theory because Symantec's "good arguments" (aka monies) have the potential to make the selected CA their bi...dding doer by means of contract in reality. What else is new though? I'm positive Symantec would have always found some business arrangement with another CA for their customers that want > 9 months cert lifetime and/or EV under Google's first proposal, so we would have gotten some "Managed CA" one way or the other. Worst case it would have been mixed in with other certs, not having a dedicated subCA or other marker. Now it's explicit, separate and even has some additional rules. NSS* already trusts that other CA to do proper validation right now, and they might just be smart enough to realize that they will be watched way more closely when Symantec starts using them to not do anything totally stupid. I honestly think that this "Managed CA" will get more practical oversight both by auditors and by the community than most of the roots in NSS. + Appreciation footnote for the DTP discussion @ cabf and the GlobalSign->Google root transfer discussion on here * Android trust store seems to be a subset of NSS' ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
On 05/21/2017 02:37 PM, userwithuid wrote: > To me, the most noticable difference between how Google and Mozilla can take > action is with regards to exisiting certs. As proposed, Google has a really > neat timeline to get rid of Symantec's questionable legacy stuff quickly and > effectively. (Legacy stuff which we - and arguably Symantec themselves > judging from their responses on here so far - still don't have a complete > picture of). > There's also a fair number of points dealing with who can sign and for what while Symantec spins up the new roots (which the Google proposal says a trusted third party CA signed by Symantec"). I'm against this point specifically because third-party CA operations is how we got into this mess. I rather cap new certificate length from the existing roots as both a way to light a fire under Symantec and to avoid the same old mistakes. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection
On 19/5/2017 6:04 μμ, Jakob Bohm via dev-security-policy wrote: On 19/05/2017 16:15, Gervase Markham wrote: On 19/05/17 14:58, Jakob Bohm wrote: Because the O and other dirname attributes may be shown in an e-mail client (current or future) as a stronger identity than the technical e-mail address. Do you know of any such clients? No, but it would be similar to how Fx displays that field in EV certs, so a future Thunderbird, or a non-Mozilla client could reasonably do something similar, even at OV level. It doesn't have to be displayed in a client UI. It is information in the Subject of the Certificate and Relying Parties read and decide what to do with this information. I think we need to describe some use cases to better understand if dirName in permittedSubtrees must be required. One case, is issuing a TCSC for an organization so that this organization (and possibly its affiliates) can issue personal certificates for employees. These personal certificates, apart from document signing/client authentication, could also be used for s/mime. Just as section 7.1.5 of the BRs for TCSCs require a dirName present in the permittedSubtrees, having a similar requirement for email-constrained TCSCs reduces the risk of having end-entity certificates that bind particular users (e.g. CN=John Doe) to an organization (O=Very High Profile Corporation). If the TCSC was restricted to dirName="C=XX, L=XXX, O=ACME", the risk is lower. The administrator could still allow any e-mail address to be included in the end-entity certificates. Another case that was described in this thread is an e-mail provider (such as Gmail) that wants to constrain issuance via a TCSC for @gmail.com. However, as Gerv pointed out, they would need to allow only information related to their customers (CN=John Doe and emailAddress=jsomeu...@gmail.com). I don't think dirName entries in permittedSubtrees allow such a representation. If there was a way to limit this, we would have a solution for both cases. Are there any other cases we should consider in this discussion? IMHO, because of the risk associated in the first use case (incorrect binding between a natural person and an organization), TCSCs should require a dirName. Dimitris. Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a SubCA name constrained to "@wosign.cn", but not to any range of DNs. Surely such a certificate would be misissued? Although I guess the issue here is that we are excluding them from scope... So the idea would be to say that dirName had to be constrained to either be empty (is that possible?) or to contain a dirNames validated as correctly representing an organization owning at least one of the domain name(s) in the cert? Rather: It should be constrained to an X.500 subtree identifying an organization validated to at least BR compliant OV level (EV level if SubCA notBefore after some policy date) as for a ServerAuth certificate for the same domain names specified in the rfc822name restrictions. Keeps it short and simple and subject to well-understood policies. Enjoy Jakob ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
