Re: Policy Update Proposal -- Remove Email Trust Bit
On Tue, September 22, 2015 3:13 pm, Kathleen Wilson wrote: > == Arguments against removing the Email trust bit == > Based on the information I currently have, and the discussion so far, I > think we should keep the Email trust bit. For a future version of the > policy, we can consider separating out the policy that is specific to > the Email trust bit into its own section. > > Did I miss anything? > > Is there any other input/feedback we should consider? Hi Kathleen, I think I'd disagree with a lot of the arguments against, in that they seem to be operating from either flawed assumptions or inconsistent statements. Intermingled in the arguments for the S/MIME trust bit is a defense of S/MIME, but that's not entirely relevant to the topic at hand I don't think. This isn't an discussion about whether or not Mozilla should come against S/MIME, or whether S/MIME is technically sound, but what are the implications to Mozilla - and potential downstream consumers. If I might try to summarize: == Arguments For == - We've heard from some Thunderbird developers that they rely on the NSS trust store to determine authenticity of S/MIME messages, and so that it's important for NSS trust store to support the e-mail trust bit for their needs. - Previously, we heard from some Red Hat employees (conspicuously silent in this discussion) that they rely on the NSS trust store as well to determine the authenticity of S/MIME messages, and so that it is important for the NSS trust store to support the e-mail trust bit for their needs. - We've heard arguments that the current Mozilla policy, as lax and liberal as it is with respect to S/MIME, is reasonable. - Related, we've heard arguments that starting a new S/MIME root program would be difficult, therefore it benefits the community to reuse the existing Mozilla processes and procedures. These are concrete items of feedback that are actionable. Arguments such as "The Internet has two killer applications" is not a reasonable or sound technical argument, because it's no different than if I were to advance the argument that "The Internet has two killer applications, virtual reality and food synthesis". That is, the proof is in the proverbial pudding, and we need consumers of NSS (such as Joshua from Thunderbird or, in the past, Bob Relyea of Red Hat) to chime in and contribute, otherwise we're talking about the world as we wish it was, rather than the world that is. We've also heard arguments for removing, for which the only 'weak' argument in that list that I would suggest is the discussion of alternatives, as that's a discussion related to S/MIME, not to the Mozilla store. I do want to echo many of the concerns Brian raised: - Reviewing S/MIME applications distracts from my own ability to review TLS applications or deal with improving TLS security. - I do not believe NSS implements correct, safe, or secure behaviours for S/MIME. Because I do not use S/MIME, I'm not motivated to fix these, nor apparently are other NSS or Thunderbird contributors. This can be empirically validated using public bugs Brian has mentioned or the private, unfixed security bugs within NSS. - In the past five years, I have trouble recalling a single incident, effort, or contribution by the community to improve S/MIME handling, with respect to policy or industry efforts. While I have no doubt that to some people it's "important", the lack of contribution suggests that the community is not actively engaged in dealing with security issues related to policy or implementation, suggesting it's "abandoned". - Simultaneously, the argument has been put forth that it's too much work for some other organization to take on, yet not a burden for Mozilla to take on. This logically appears inconsistent and is largely presented without evidence of the complexities or why obvious solutions such as "Do what Mozilla does" are not viable, unless the reality is that it is a burden on Mozilla to do so. One of the challenges in evaluating this proposal is the quality asymmetry between the Website Trust Bit and the Email Trust Bit. The Website trust bit is actively curated and reviewed, undergoes wide industry participation (via the CA/Browser Forum), is actively being policed and monitored (as recently demonstrated by Google's detection of a misissued Symantec certificate), and has active contributions to the codebase to improve support and consistency. The Email trust bit, however, is simply information gathering - by yourself. It does not undergo thorough community review, it is not being actively monitored for misissuance, and has zero industry efforts in the past decade to improve the issuance. Further, as Brian mentioned, the code itself is problematic for support, and the S/MIME support within NSS is a veritable font of bugs, as S/MIME relies on BER for interoperability, which adds a significant complexity footprint to the NSS codebase. Without active investment of Mozilla, these issues won't get fi
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
Joshua Cranmer š§ wrote: > Kathleen Wilson wrote: > >> Large parts of it are >>> out of date and the people who maintain the certificate validation logic >>> aren't required to keeping S/MIME stuff working. In particular, it is OK >>> according to current development policies for us to change Gecko's >>> certificate validation logic so that it works for SSL but doesn't >>> (completely) work for S/MIME. So, basically, Mozilla doesn't implement >>> software that can properly use S/MIME certificates, as far as we know. >>> >>> >> Is this true? Can some at Mozilla confirm or deny this statement about >> current development policies? >> > > Last I checked, Thunderbird is a product whose trademark is owned by > Mozilla, whose infrastructure is paid for by Mozilla, and whose developers > are Mozilla community members. And it is still a product with active > development. > > So saying that Mozilla doesn't have any software that uses S/MIME is a lie. Literally nobody said that. I said "Mozilla doesn't implement software that can properly use S/MIME certificates, we far as we know." The key word is *properly*. I cited two pieces of evidence in support of that. Also, Joshua, I wish that the situation with Thunderbird was the opposite of what it is. But, it is what it is and we have to acknowledge that. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Remove Email Trust Bit
On 9/22/15 9:29 AM, Kathleen Wilson wrote: First, we need to determine if the Email trust bit should remain part of Mozilla's CA Certificate Policy. To be clear, IF this proposal to remove the Email trust bit from Mozilla's CA Certificate Policy is approved, then it would follow that the email trust bit would be turned off for root certificates in the NSS root store. So, I would very much like to hear from folks who depend on certificates chaining up to roots with the Email trust bit enabled. Here's a summary of this discussion so far... == Arguments against removing the Email trust bit == - S/MIME and PGP are the only (popular) ways to do encryption over email. The encryption part is probably not the most important part of it, but the authentication of the sender is. E.g. If I get an email from my broker I really want it to be from someone who is still a Fidelity employee. - Hierarchical trust models meet the needs of hierarchical organizations very well. Governments and many enterprises are hierarchical. Which makes this (NSS root store with email trust bit) the preferred trust model for government and business uses. - The Internet has two killer applications, Mail and the Web. - Both client-side (e.g. S/MIME) and server side (e.g. TLS) authentication are needed. - There is a need to have a publicly trusted root store containing CA certificates that are trusted to issue certs for S/MIME. If the NSS root store were to stop supporting this, then another publicly-trusted root store would be needed. It would be a huge effort to start another root store. - S/MIME has an important role in inter-organizational encrypted communication. It's not perfect, but it works in many scenarios. There are alternatives for sure, but they cover different aspects of encrypted communication and are useful in different scenarios. - Without the Email trust bit, setting up certificates would be much more difficult up to the point that enrollment workflows become completely unusable. Users receiving email encrypted with an S/MIME certificate currently do not have to manually trust the certificate if it already chains to a root in a public root store. - Mozilla's CA Certificate Policy is basically doing what is reasonable. There are currently no Baseline Requirements For Email Certificates, so itās a valid solution to refer to established audit standards and enrich them with explicit requirements regarding e-mail address verification. - The policy language that is specific to the Email trust bit can be separated out into its own section. - This is spectacularly bad timing for us to do this discussionā¦ The Thunderbird team is trying very hard to get Mozilla to clarify the position of Thunderbird within Mozilla, and at the same time organizing funding external to MoCo that will allow us to have a team of developers - Mozilla (Thunderbird) is not the only consumer of the NSS root store. == Arguments for removing the Email trust bit == - Mozilla's policies regarding Email certificates are not currently sufficient. - Alternatives with different models exist, such a GPG and TextSecure. - S/MIME discussions distract some people from the TLS work. - The policy can be cleaned up if it only has to deal with TLS certs. - Mozilla's S/MIME processing isn't well supported. - An organization that does not have a strong interest in how the email trust bit affects its products may not be a good choice to run a program for email CA trust. Based on the information I currently have, and the discussion so far, I think we should keep the Email trust bit. For a future version of the policy, we can consider separating out the policy that is specific to the Email trust bit into its own section. Did I miss anything? Is there any other input/feedback we should consider? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
On 9/22/2015 11:41 AM, Kathleen Wilson wrote: Large parts of it are out of date and the people who maintain the certificate validation logic aren't required to keeping S/MIME stuff working. In particular, it is OK according to current development policies for us to change Gecko's certificate validation logic so that it works for SSL but doesn't (completely) work for S/MIME. So, basically, Mozilla doesn't implement software that can properly use S/MIME certificates, as far as we know. Is this true? Can some at Mozilla confirm or deny this statement about current development policies? Last I checked, Thunderbird is a product whose trademark is owned by Mozilla, whose infrastructure is paid for by Mozilla, and whose developers are Mozilla community members. And it is still a product with active development. So saying that Mozilla doesn't have any software that uses S/MIME is a lie. The Mozilla Corporation does not have any paid developers on Thunderbird, but Mozilla is not limited to the Corporation, the last I knew. -- Joshua Cranmer Thunderbird and DXR developer Source code archƦologist ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
On Tue, Sep 22, 2015 at 4:47 AM, Brian Smith wrote: > Kathleen Wilson wrote: > > > Arguments for removing the Email trust bit: > > - Mozilla's policies regarding Email certificates are not currently > > sufficient. > > - What else? > > > > > * It isn't clear that S/MIME using certificates from publicly-trusted CAs > is a model of email security that is worth supporting. Alternatives with > different models exist, such a GPG and TextSecure. IMO, the TextSecure > model is more in line with what Mozilla is about that the S/MIME model. > The idea that there is one trust model that meets every need is completely wrong. Hierarchical trust models meet the needs of hierarchical organizations very well. When I last did a survey I was rather surprised to find that there are actually the same number of CA issued S/MIME certs as on the OpenPGP servers. And that ignores a huge deployment in the US military that isn't visible to us. Governments and many enterprises are hierarchical. Which makes that the preferred trust model for government and business uses. If I get an email from my broker I really want it to be from someone who is still a Fidelity employee. Hierarchical is not sufficient by itself which is why email clients should not be limited to a single trust model. It should be possible to specify S/MIME keys directly by fingerprint. * It is better to spend energy improving TLS-related work than > S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS > work. > The TLS model is server side authentication. Saying client side authentication distracts from server side makes no sense to me. > * We can simplify the policy and tighten up the policy language more if the > policy only has to deal with TLS certificates. > You could save even more time if you stopped supporting Thunderbird. If Mozilla isn't going to do Thunderbird right and keep it up to date, that might be the right choice of course. * Mozilla's S/MIME processing isn't well supported. Large parts of it are > out of date and the people who maintain the certificate validation logic > aren't required to keeping S/MIME stuff working. In particular, it is OK > according to current development policies for us to change Gecko's > certificate validation logic so that it works for SSL but doesn't > (completely) work for S/MIME. So, basically, Mozilla doesn't implement > software that can properly use S/MIME certificates, as far as we know. > Just to make sure people understand the last point: I think it is great > that people try to maintain Thunderbird. But, it was a huge burden on Gecko > developers to maintain Thunderbird on top of maintaining Firefox, and some > of us (including me, when I worked at Mozilla) lobbied for a policy change > that let us do our work without consideration for Thunderbird. Thus, when > we completely replaced the certificate verification logic in Gecko last > year, we didn't check how it affected Thunderbird's S/MIME processing. > Somebody from the Thunderbird maintenance team was supposed to do so, but I > doubt anybody actually did. So, it would be prudent to assume that > Thunderbird's S/MIME certificate validation is broken. > The Internet has two killer applications, Mail and the Web. I invented WebMail (no really we had a court case with a patent troll and it turns out that I did) and I don't think it is the right answer. Right now there are problems with the specs for OpenPGP, and with S/MIME. Both are examples of 90/10 engineering from the days when that was sufficient. Today they just don't make the grade. If people want to have an email infrastructure that is end-to-end secure, offers all the capabilities of OpenPGP, and S/MIME is fully backwards compatible and makes email and the Web easier to use then I have an architecture that does exactly that. If someone was willing to work with me and help me to integrate with Thunderbird in the same way that I currently integrate with Windows Live Mail (and Outlook to come) then we could open with support for all the major desktop email clients. At some point, I can do the same thing for WebMail, but it isn't possible to meet all my goals there until we can move to ECC. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
Kathleen Wilson wrote: > * It is better to spend energy improving TLS-related work than >> > S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS >> work. >> >> > Please further explain whose energy this is referring too, and who is > getting distracted too much from the TLS work. Eveybody that reads or writes email in this mailing list, for one. Anybody who has to write text for Mozilla's CA policy and/or propose changes for another. > * We can simplify the policy and tighten up the policy language more if the >> policy only has to deal with TLS certificates. >> > > Another approach would be to separate the policy language that is specific > to the "Email trust bit" certs. That also seems reasonable. If the email policy were completely separate then people could ignore it. > * Mozilla's S/MIME processing isn't well supported. >> > > Mozilla is not the only consumer of the NSS root store. Yes. But, I don't think that an organization that does not have a strong interest in how the email trust bit affects its products is a good choice to run a program for email CA trust, despite the good intentions and hard work of the people within that organization to try to do something good. > Large parts of it are >> out of date and the people who maintain the certificate validation logic >> aren't required to keeping S/MIME stuff working. In particular, it is OK >> according to current development policies for us to change Gecko's >> certificate validation logic so that it works for SSL but doesn't >> (completely) work for S/MIME. So, basically, Mozilla doesn't implement >> software that can properly use S/MIME certificates, as far as we know. >> > > Is this true? Can some at Mozilla confirm or deny this statement about > current development policies? You can see an example of this policy at work at https://bugzilla.mozilla.org/show_bug.cgi?id=1114787. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
On 9/22/15 11:37 AM, R Kent James wrote: On 9/21/2015 7:07 PM, Kathleen Wilson wrote: As we did with the discussion about the code signing trust bit, let's list the arguments for and against removing references to the Email trust bit from Mozilla's CA Certificate Policy. The main comment that I can give is that this is spectacularly bad timing for us to do this discussion. If we must have this discussion now, OK we'll do it, but I would ask instead if this can't be delayed for six months. Actually, the future of Thunderbird is not the primary factor in this discussion. There are many other users of the NSS root store. My job has always been to manage the NSS root store, so I must take the non-Mozilla users of the NSS root store into account as well. In the case of Code Signing, I could not find any other users of the NSS root store depending on the Code Signing trust bit. On the contrary, I believe there are many users of the NSS root store depending on the Email trust bit (maybe for identity rather than S/MIME, but still using this trust bit). I hope some of them will speak up in this discussion. The Thunderbird team is trying very hard to get Mozilla to clarify the position of Thunderbird within Mozilla, and at the same time organizing funding external to MoCo that will allow us to have a team of developers that can address some of the complaints that Brian Smith makes about the current state of Thunderbird development. Part of the motivation for external funding is that Thunderbird, as the leading open-source desktop email client, plays a critical role in the worldwide infrastructure supporting end-to-end communications encryption. One way or the other, these issue will be resolved within 6 months, and a new policy toward Thunderbird publicly adopted by Mozilla. I am happy to hear that. I am a big fan of Thunderbird -- I use it for email, news, and calendar. Given all of that, it would be better to delay this discussion. If that is not possible, the most simple response I can give is that Thunderbird is still Mozilla's #2 product, security is an important part of the Mozilla manifesto and brand, and S/MIME is an important Thunderbird security feature that relies on this root certificate infrastructure. If there are issues with how that is handled, let's fix those issues. R Kent James Chair, Thunderbird Council Thanks for your input into this discussion. I greatly appreciate it! Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
On Mon, Sep 21, 2015 at 07:07:07PM -0700, Kathleen Wilson wrote: > > First, we need to determine if the Email trust bit should remain part of > Mozilla's CA Certificate Policy. I'm really concerned about this. S/MIME and PGP are the only (popular) ways to do encryption over email. The encryption part is probably not the most impotant part of it, but the authentication of the sender is. As far as I know email is still very important to many people, I don't see that going away in the near future. Doing S/MIME or PGP might be complicted to set up, but at least some people are trying to improve the user experience. Removing the email trust bit seems like a step in the wrong direction. I really do not want to start an other root store. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
On 9/21/2015 7:07 PM, Kathleen Wilson wrote: As we did with the discussion about the code signing trust bit, let's list the arguments for and against removing references to the Email trust bit from Mozilla's CA Certificate Policy. The main comment that I can give is that this is spectacularly bad timing for us to do this discussion. If we must have this discussion now, OK we'll do it, but I would ask instead if this can't be delayed for six months. The Thunderbird team is trying very hard to get Mozilla to clarify the position of Thunderbird within Mozilla, and at the same time organizing funding external to MoCo that will allow us to have a team of developers that can address some of the complaints that Brian Smith makes about the current state of Thunderbird development. Part of the motivation for external funding is that Thunderbird, as the leading open-source desktop email client, plays a critical role in the worldwide infrastructure supporting end-to-end communications encryption. One way or the other, these issue will be resolved within 6 months, and a new policy toward Thunderbird publicly adopted by Mozilla. Yes we understand that within parts of MoCo Thunderbird is all but written off. But in spite of years of neglect within Mozilla, Thunderbird is still the #2 product of Mozilla. The ratio of Thunderbird users to Firefox desktop users is relatively static, which is pretty amazing given that Thunderbird has done almost no marketing for years. The last official statement from Mozilla on Thunderbird, from Mitchell's 2012-07-06 blog posting, stated: "Much of Mozillaās leadership ā including that of the Thunderbird team ā has come to the conclusion that on-going stability is the most important thing ... Mozilla will provide security updates through an Extended Support Release process." Mozilla initially met this expectation, but started silently reneging on their promises a couple of years ago. Over the last 9 months volunteers have been slowly filling in the missing pieces to overcome this, but that is not the proper long-term solution for a product that is as important to as many people as Thunderbird is. We are putting in place a long-term solution, that may or may not keep Thunderbird as a critical part of the Mozilla organization, but the discussions are still ongoing. Given all of that, it would be better to delay this discussion. If that is not possible, the most simple response I can give is that Thunderbird is still Mozilla's #2 product, security is an important part of the Mozilla manifesto and brand, and S/MIME is an important Thunderbird security feature that relies on this root certificate infrastructure. If there are issues with how that is handled, let's fix those issues. R Kent James Chair, Thunderbird Council ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Remove Email Trust Bit
S/MIME has an important role in inter-organizational encrypted communication. It's not perfect, but it works in many scenarios. There are alternatives for sure, but they cover different aspects of encrypted communication and are useful in different scenarios. The Email trust bit is important because Thunderbird users rely on it when using S/MIME. Without the Email trust bit, setting up certificates would be much more difficult up to the point that enrollment workflows become completely unusable. The current discussion seems to revolve around two aspects: 1. Implementation details and the amount of work Mozilla (?) is willing to invest in Thunderbird and its end-to-end encryption capabilities. (Is a broken Thunderbird S/MIME implementation reason enough to remove Email trust bits? Thats up to Mozilla I guess... .) 2. The maturity of Mozilla's CA Certificate Policy with regard to the E-Mail trust bit. => Mozilla's CA Certificate Policy is basically doing what is reasonable. There are no Baseline Requirements For Email Certificates, so its a valid solution to refer to established audit standards and enrich them with explicit requirements regarding e-mail adress verification. => I don't see a fundamental difference to SSL. Regards, Juergen Kathleen Wilson schrieb: On 9/21/15 7:07 PM, Kathleen Wilson wrote: In https://wiki.mozilla.org/CA:CertificatePolicyV2.3 The proposal is: (D27) Clarify which audit criteria are required depending on which trust bits are set. In particular, root certs with only the S/MIME trust bit set will have different audit criteria requirements than root certs with the Websites trust bit set. First, we need to determine if the Email trust bit should remain part of Mozilla's CA Certificate Policy. As background, when a CA requests the Email trust bit, I verify the information listed in #4 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices As we did with the discussion about the code signing trust bit, let's list the arguments for and against removing references to the Email trust bit from Mozilla's CA Certificate Policy. Arguments against removing the Email trust bit: - Users receiving email encrypted with an S/MIME certificate currently do not have to manually trust the certificate if it already chains to a root in a public root store. - There are known organizations depending on root certificates in the NSS root store for S/MIME. - There is support for bolstering the policies and audit requirements for the Email trust bit. - What else? Arguments for removing the Email trust bit: - Mozilla's policies regarding Email certificates are not currently sufficient. - What else? As always, I will appreciate your thoughtful and constructive input into this discussion. Thanks, Kathleen To be clear, IF this proposal to remove the Email trust bit from Mozilla's CA Certificate Policy is approved, then it would follow that the email trust bit would be turned off for root certificates in the NSS root store. So, I would very much like to hear from folks who depend on certificates chaining up to roots with the Email trust bit enabled. Thanks, Kathleen ___ 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: Policy Update Proposal -- Remove Email Trust Bit
On 9/21/15 7:07 PM, Kathleen Wilson wrote: In https://wiki.mozilla.org/CA:CertificatePolicyV2.3 The proposal is: (D27) Clarify which audit criteria are required depending on which trust bits are set. In particular, root certs with only the S/MIME trust bit set will have different audit criteria requirements than root certs with the Websites trust bit set. First, we need to determine if the Email trust bit should remain part of Mozilla's CA Certificate Policy. As background, when a CA requests the Email trust bit, I verify the information listed in #4 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices As we did with the discussion about the code signing trust bit, let's list the arguments for and against removing references to the Email trust bit from Mozilla's CA Certificate Policy. Arguments against removing the Email trust bit: - Users receiving email encrypted with an S/MIME certificate currently do not have to manually trust the certificate if it already chains to a root in a public root store. - There are known organizations depending on root certificates in the NSS root store for S/MIME. - There is support for bolstering the policies and audit requirements for the Email trust bit. - What else? Arguments for removing the Email trust bit: - Mozilla's policies regarding Email certificates are not currently sufficient. - What else? As always, I will appreciate your thoughtful and constructive input into this discussion. Thanks, Kathleen To be clear, IF this proposal to remove the Email trust bit from Mozilla's CA Certificate Policy is approved, then it would follow that the email trust bit would be turned off for root certificates in the NSS root store. So, I would very much like to hear from folks who depend on certificates chaining up to roots with the Email trust bit enabled. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
On 9/22/15 1:47 AM, Brian Smith wrote: Kathleen Wilson wrote: Arguments for removing the Email trust bit: - Mozilla's policies regarding Email certificates are not currently sufficient. - What else? * It isn't clear that S/MIME using certificates from publicly-trusted CAs is a model of email security that is worth supporting. Alternatives with different models exist, such a GPG and TextSecure. IMO, the TextSecure model is more in line with what Mozilla is about that the S/MIME model. It is my understanding that many people depend on this type of certificate for proof of identity. So, perhaps "Email trust bit" is a misnomer. * It is better to spend energy improving TLS-related work than S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS work. Please further explain whose energy this is referring too, and who is getting distracted too much from the TLS work. * We can simplify the policy and tighten up the policy language more if the policy only has to deal with TLS certificates. Another approach would be to separate the policy language that is specific to the "Email trust bit" certs. * Mozilla's S/MIME processing isn't well supported. Mozilla is not the only consumer of the NSS root store. Large parts of it are out of date and the people who maintain the certificate validation logic aren't required to keeping S/MIME stuff working. In particular, it is OK according to current development policies for us to change Gecko's certificate validation logic so that it works for SSL but doesn't (completely) work for S/MIME. So, basically, Mozilla doesn't implement software that can properly use S/MIME certificates, as far as we know. Is this true? Can some at Mozilla confirm or deny this statement about current development policies? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Refer to BRs forNameConstraintsRequirement
On 22/09/15 10:22, Brian Smith wrote: Rob Stradling wrote: https://aka.ms/rootcert Section 4.A.12, for example, says... "Rollover root certificates, or certificates which are intended to replace previously enrolled but expired certificates, will not be accepted if they combine server authentication with code signing uses unless the uses are separated by application of Extended Key Uses (āEKUās) at the intermediate CA certificate level that are reflected in the whole certificate chain." My reading of that is this: If you ask Microsoft to enable the code signing bit and the server authentication bit for the same root CA, then you must have separate intermediates for code signing and for server authentication, and those separate intermediates must have EKU extensions. But, if a given root certificate is only trusted for server authentication, then there is no requirement that the intermediate CA certificates contain EKU extensions. So, in fact, I think many CAs--e.g. ones that don't do code signing, or that have separate roots for code signing, would benefit from such a change because they'd be allowed to issue smaller certificates. And, that's a goood thing. That's true. -- 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: Policy Update Proposal -- Refer to BRs for NameConstraintsRequirement
Rob Stradling wrote: > https://aka.ms/rootcert Section 4.A.12, for example, says... > "Rollover root certificates, or certificates which are intended to > replace previously enrolled but expired certificates, will not be accepted > if they combine server authentication with code signing uses unless the > uses are separated by application of Extended Key Uses (āEKUās) at the > intermediate CA certificate level that are reflected in the whole > certificate chain." > My reading of that is this: If you ask Microsoft to enable the code signing bit and the server authentication bit for the same root CA, then you must have separate intermediates for code signing and for server authentication, and those separate intermediates must have EKU extensions. But, if a given root certificate is only trusted for server authentication, then there is no requirement that the intermediate CA certificates contain EKU extensions. So, in fact, I think many CAs--e.g. ones that don't do code signing, or that have separate roots for code signing, would benefit from such a change because they'd be allowed to issue smaller certificates. And, that's a goood thing. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Refer to BRs for NameConstraintsRequirement
On 22/09/15 09:34, Brian Smith wrote: On 22/09/15 01:01, Brian Smith wrote: But, if the intermediate CA certificate is allowed to issue SSL certificates, then including the EKU extension with id-kp-serverAuth is just wasting space. Mozilla's software assumes that when the intermediate CA certificate does not have an EKU, then the certificate is valid for all uses. So, including an EKU with id-kp-serverAuth is redundant. And, the wasting of space within certificates has material consequences that affect performance and thus indirectly security. Brian, Given that the BRs require id-kp-serverAuth in Technically Constrained intermediates, what would be the point of Mozilla dropping that same requirement? There seems little point providing options that, in reality, CAs are never permitted to choose. It would be the first step towards changing the BRs in the analogous manner. Even if Mozilla and the BRs make that change, many CAs will still have to include id-kp-serverAuth in intermediates (even non-technically-constrained intermediates!) due to Microsoft's requirements. https://aka.ms/rootcert Section 4.A.12, for example, says... "Rollover root certificates, or certificates which are intended to replace previously enrolled but expired certificates, will not be accepted if they combine server authentication with code signing uses unless the uses are separated by application of Extended Key Uses (āEKUās) at the intermediate CA certificate level that are reflected in the whole certificate chain." The number of CAs that issue server authentication certs that are intended to be used solely by Mozilla's software is, I suspect, vanishingly small. -- 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: Policy Update Proposal -- Specify audit criteria according to trust bit
On Tue, Sep 22, 2015 at 1:47 AM, Brian Smith wrote: > * Mozilla's S/MIME processing isn't well supported. Large parts of it are > out of date and the people who maintain the certificate validation logic > aren't required to keeping S/MIME stuff working. In particular, it is OK > according to current development policies for us to change Gecko's > certificate validation logic so that it works for SSL but doesn't > (completely) work for S/MIME. So, basically, Mozilla doesn't implement > software that can properly use S/MIME certificates, as far as we know. > Here is a good example to show that the security of Thunderbird's S/MIME handling is not properly managed: https://bugzilla.mozilla.org/show_bug.cgi?id=1178032 The bug report is that email that the user tried to encrypt was sent unencrypted. The bug was filed months ago, but hasn't been triaged so that it is marked as a serious security issue, and the validity of the bug report hasn't been investigated by anybody. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
Kathleen Wilson wrote: > Arguments for removing the Email trust bit: > - Mozilla's policies regarding Email certificates are not currently > sufficient. > - What else? > > * It isn't clear that S/MIME using certificates from publicly-trusted CAs is a model of email security that is worth supporting. Alternatives with different models exist, such a GPG and TextSecure. IMO, the TextSecure model is more in line with what Mozilla is about that the S/MIME model. * It is better to spend energy improving TLS-related work than S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS work. * We can simplify the policy and tighten up the policy language more if the policy only has to deal with TLS certificates. * Mozilla's S/MIME processing isn't well supported. Large parts of it are out of date and the people who maintain the certificate validation logic aren't required to keeping S/MIME stuff working. In particular, it is OK according to current development policies for us to change Gecko's certificate validation logic so that it works for SSL but doesn't (completely) work for S/MIME. So, basically, Mozilla doesn't implement software that can properly use S/MIME certificates, as far as we know. Just to make sure people understand the last point: I think it is great that people try to maintain Thunderbird. But, it was a huge burden on Gecko developers to maintain Thunderbird on top of maintaining Firefox, and some of us (including me, when I worked at Mozilla) lobbied for a policy change that let us do our work without consideration for Thunderbird. Thus, when we completely replaced the certificate verification logic in Gecko last year, we didn't check how it affected Thunderbird's S/MIME processing. Somebody from the Thunderbird maintenance team was supposed to do so, but I doubt anybody actually did. So, it would be prudent to assume that Thunderbird's S/MIME certificate validation is broken. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Refer to BRs for Name ConstraintsRequirement
On Tue, Sep 22, 2015 at 12:51 AM, Rob Stradling wrote: > On 22/09/15 01:01, Brian Smith wrote: > > >> But, if the intermediate CA certificate is allowed to issue SSL >> certificates, then including the EKU extension with id-kp-serverAuth is >> just wasting space. Mozilla's software assumes that when the intermediate >> CA certificate does not have an EKU, then the certificate is valid for all >> uses. So, including an EKU with id-kp-serverAuth is redundant. And, the >> wasting of space within certificates has material consequences that affect >> performance and thus indirectly security. >> > > Brian, > > Given that the BRs require id-kp-serverAuth in Technically Constrained > intermediates, what would be the point of Mozilla dropping that same > requirement? > > There seems little point providing options that, in reality, CAs are never > permitted to choose. It would be the first step towards changing the BRs in the analogous manner. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Refer to BRs for Name ConstraintsRequirement
On 22/09/15 01:01, Brian Smith wrote: But, if the intermediate CA certificate is allowed to issue SSL certificates, then including the EKU extension with id-kp-serverAuth is just wasting space. Mozilla's software assumes that when the intermediate CA certificate does not have an EKU, then the certificate is valid for all uses. So, including an EKU with id-kp-serverAuth is redundant. And, the wasting of space within certificates has material consequences that affect performance and thus indirectly security. Brian, Given that the BRs require id-kp-serverAuth in Technically Constrained intermediates, what would be the point of Mozilla dropping that same requirement? There seems little point providing options that, in reality, CAs are never permitted to choose. -- 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
