Re: Symantec Response B
On 13/04/17 17:43, Jeremy Rowley wrote: > Because the certificate improperly included Symantec's BR-compliance OID. If > the cert wasn't a BR-covered certificate but included the BR compliance OID, > then the cert was still mis-issued and should be disclosed. But that was not the reason they gave for it being misissued; they only noticed that when someone else pointed it out to them. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Symantec Response B
Because the certificate improperly included Symantec's BR-compliance OID. If the cert wasn't a BR-covered certificate but included the BR compliance OID, then the cert was still mis-issued and should be disclosed. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Gervase Markham via dev-security-policy Sent: Thursday, April 13, 2017 7:49 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Symantec Response B Symantec's bug opens with the words: "At the end of 2013, Symantec issued a cert to one of its customers that did not comply with several provisions of the CA/Browser Forum Baseline Requirements."[0] So Symantec, at least, thought that this cert fell under the BRs. If their case was that it did not, why did they feel a need to report? Gerv [0] https://bugzilla.mozilla.org/show_bug.cgi?id=966350 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
Symantec's bug opens with the words: "At the end of 2013, Symantec issued a cert to one of its customers that did not comply with several provisions of the CA/Browser Forum Baseline Requirements."[0] So Symantec, at least, thought that this cert fell under the BRs. If their case was that it did not, why did they feel a need to report? Gerv [0] https://bugzilla.mozilla.org/show_bug.cgi?id=966350 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Symantec Response B
I am curious about the software requiring the 1024 bit cert off the root. The dates of mis-issuance are 2013-2014, which is still early in adoption of the BRs. At that time, the scope of the BRs was confusing and lead to lots of discussions. Although the term "intended to be used for authenticating servers" is still the scope of the BRs, everyone seems to agree that this means all certs with serverAuth are included. This was not the case in 2013. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, April 12, 2017 6:40 AM To: Kurt Roeckx <k...@roeckx.be> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Symantec Response B On Wed, Apr 12, 2017 at 4:24 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't think 2) applies. It's only their software, that obviously > can't be updated yet, and so won't enforce such limit. That doesn't > prevent the rest of us to set such limit. > Hi Kurt, I appreciate that you're engaged and offering your thoughts. I would appreciate, however, if you allowed Steve to respond on behalf of Symantec. I do not agree with your conclusions or interpretation of matters, but more importantly, the questions are for Symantec. #2 absolutely applies as a principle. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
On Wed, Apr 12, 2017 at 4:24 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't think 2) applies. It's only their software, that obviously can't > be updated yet, and so won't enforce such limit. That doesn't prevent the > rest of us to set such limit. > Hi Kurt, I appreciate that you're engaged and offering your thoughts. I would appreciate, however, if you allowed Steve to respond on behalf of Symantec. I do not agree with your conclusions or interpretation of matters, but more importantly, the questions are for Symantec. #2 absolutely applies as a principle. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
On 2017-04-11 17:54, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The reply indicated that it was a non-browser application. So I understand that a browser should never see that certificate. There's no way to objectively quantify or assess that, however. My question still remains - what are the criteria for determining this, and what process is in place for disagreement about this risk? The question is, can that certificate be used for authenticating something it shouldn't? And I guess that's not the case. No. That is not the question. The problem with 1024 keys is that someone with enough resources can find the private key. I assume there are no other (new) certificates with the same key. So I think there are 3 potential problems: 1) The subscriber itself can be attacked 2) The rest can't enforce the 2048 limit, so we can't be sure we're not attacked. 3) The certificate could be used to authenticate something else He said "we believed that issuance of this cert didn't impose risk on anyone but this specific customer", which would be 1). I don't think 2) applies. It's only their software, that obviously can't be updated yet, and so won't enforce such limit. That doesn't prevent the rest of us to set such limit. Which would only leave 3) Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The reply indicated that it was a non-browser application. So I understand > that a browser should never see that certificate. > There's no way to objectively quantify or assess that, however. My question still remains - what are the criteria for determining this, and what process is in place for disagreement about this risk? > The question is, can that certificate be used for authenticating something > it shouldn't? And I guess that's not the case. > No. That is not the question. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
On 2017-04-11 17:20, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Hi Ryan, On 10/04/17 16:38, Ryan Sleevi wrote: 1) You're arguing that "the issuance of this cert didn't impose risk on anyone but this specific customer" a) What factors lead you to that decision? Can you lay out for us a scenario where this issuance might impose risk on someone else? Sure. Consider the ecosystem risk where if every CA were to continue issuing 1024-bit certs. This imposes a risk on the collective users of the ecosystem, but notably Mozilla users, when accessing these sites, because it provides a weaker security guarantee than other sites. That is, it means the 'effective' security of the lock is gated on 1024-bit. Similarly, if we accept that 1024-bit does no one but the subscriber any harm, then it meaningfully prevents disabling 1024-bit support for leaf certs, both for Mozilla and the ecosystem. The reply indicated that it was a non-browser application. So I understand that a browser should never see that certificate. The question is, can that certificate be used for authenticating something it shouldn't? And I guess that's not the case. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > > On 10/04/17 16:38, Ryan Sleevi wrote: > > 1) You're arguing that "the issuance of this cert didn't impose risk on > > anyone but this specific customer" > > a) What factors lead you to that decision? > > Can you lay out for us a scenario where this issuance might impose risk > on someone else? > Sure. Consider the ecosystem risk where if every CA were to continue issuing 1024-bit certs. This imposes a risk on the collective users of the ecosystem, but notably Mozilla users, when accessing these sites, because it provides a weaker security guarantee than other sites. That is, it means the 'effective' security of the lock is gated on 1024-bit. Similarly, if we accept that 1024-bit does no one but the subscriber any harm, then it meaningfully prevents disabling 1024-bit support for leaf certs, both for Mozilla and the ecosystem. Importantly though, I think the question highlights the principle at play here - which is Symantec seems to view the Baseline Requirements as "The Baseline Suggestions that should be Requirements for our Competitors but Recommendations for Us". That is deeply problematic, and it's useful to understand from Symantec what factors go in to such determinations, in order to determine whether or not Symantec is, has been, or can be trustworthy. > > 2) You've noted that you did not disclose it due to "contractual > > obligations to protect the customer's privacy", which "remains in force". > > a) If a contractual obligation is in conflict with the Baseline > > Requirements, do you have a process defined to resolve that conflict? If > > so, please fully describe it. > > Do you think this particular contractual obligation to privacy _is_ in > conflict with the BRs? If so, which section? > The obligation itself, no, but the results of that obligation unquestionably are. I think it's in conflict with trustworthiness for Symantec to have policies that would prevent it from meaningfully disclosing certificates that are misissued (whether according to the Baseline Requirements or Symantec's CP/CPS), because it prevents and impairs the ability to understand the scope of the issues or the truthfulness of Symantec's claims. I'm deeply concerned with the suggestion that details of BR violations either cannot or should not be disclosed. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
Hi Ryan, On 10/04/17 16:38, Ryan Sleevi wrote: > 1) You're arguing that "the issuance of this cert didn't impose risk on > anyone but this specific customer" > a) What factors lead you to that decision? Can you lay out for us a scenario where this issuance might impose risk on someone else? > 2) You've noted that you did not disclose it due to "contractual > obligations to protect the customer's privacy", which "remains in force". > a) If a contractual obligation is in conflict with the Baseline > Requirements, do you have a process defined to resolve that conflict? If > so, please fully describe it. Do you think this particular contractual obligation to privacy _is_ in conflict with the BRs? If so, which section? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
Hi Steve, Some quick follow-ups: 1) You're arguing that "the issuance of this cert didn't impose risk on anyone but this specific customer" a) What factors lead you to that decision? b) What process does Symantec have in place to make such determination? c) Does such process continue to exist? d) If Symantec is incorrect in its determination, for this incident, past, or future incidents, what do you believe should be an appropriate response? 2) You've noted that you did not disclose it due to "contractual obligations to protect the customer's privacy", which "remains in force". a) If a contractual obligation is in conflict with the Baseline Requirements, do you have a process defined to resolve that conflict? If so, please fully describe it. b) If a contractual obligation is in conflict with other Root Program requirements, do you have a process defined to resolve that conflict? If so, please fully describe it? c) Please share the details of that contract, as well as any other such contracts that may exist, to the extent of such privacy requirements. If you're unable to do so, please fully describe why? d) Specifically, how many such contracts exist? e) Does Symantec have a procedure in place for when no such contracts exist (e.g. in the case of Example D, where Symantec failed to disclose to affected parties, citing "confidentiality", where no such contract existed?) f) What steps has Symantec taken, if any, to eliminate such clauses, in order to ensure that appropriate transparency for the ecosystem supersedes that of customer obligations, particularly when faced with situations like 1.d? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
