Ryan - Thank you for the feedback. On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi <r...@sleevi.com> wrote:
> While I realize the thinking is with regards to the recent serial number > issue, a few questions emerge: > > 1) Based on the software vendor reporting, they don’t view this as a > software defect, but a CA misconfiguration. Do you believe the current > policy, as worded, addresses that ambiguity? > > As the language is an example, I don't believe it needs to address this distinction. I intended "defect" to mean a defect in the certificate, so perhaps it would help to specify that - i.e. "certificate defect"? 2) We’ve seen CAs fail to do things like validate the well-formedness of > domain names or ensure consistent validation of their certificates. Given > the current (new) policy allows a CA to make a determination as to whether > a “massive” number of certificates / Subscribers are affected by a given > defect, and given that many CAs have historically viewed material and > substantial, dangerous non-compliance as “minor defects,” are you concerned > that this may place Mozilla directly in a position of requiring revocation > when CAs otherwise decline to? > > Are you asking if I'm concerned that CAs will abuse this guidance to avoid revocation of misissued certificates? If so, the answer is yes, both with the current/proposed and former wording. I don't feel that this additional example changes the situation. 3) With the rephrasing about acceptability to be “general” regarding the > severity of the issue, is there any concern that this may introduce > liability to Mozilla in assessing whether or not a given issue is a > security risk? It would seem that the previous intent is for the CA to > demonstrate their careful and thoughtful analysis as to the severity of > things, while this new policy would seem to permit CAs to make blanket > statements, without any expectations of them showing their analysis. While > it includes discussion on this forum, it’s unclear what acceptable > expectations there are. > > I can see how the term "generally" could be abused to mean "except in whatever current mess we find ourselves in", and on that basis I would support taking it back out. 4) This new policy seems to explicitly allow a CA never revoking a > non-compliant Certificate. Is that your intent? If so, is there any concern > that this introduces the risk of CAs presenting revocation as being > “required by Mozilla” as opposed to the factually correct and accurate > “required by the Baseline Requirements” if Mozilla or this community should > disagree with such a decision? > > Is there any difference between delaying revocation until a certificate expires and not revoking at all? Is there any difference between CAs misrepresenting revocation as "being required by Mozilla to happen by X date" and "being required by Mozilla"? 5) If multiple CAs are affected by a common incident, this seems to > encourage delaying revocation as long as possible. It’s unclear whether a > CA that can and does revoke their certificates will be more or less > favorably considered, both by the ecosystem and by this community. Given > the economic incentives, it seems to strongly discourage revocation, as a > way of competitive differentiation. > > I'm not following how these changes have the effect of encouraging multiple CAs to delay revocation as long as possible. but I do think it would be useful to state that CAs who violate the BRs will always be looked upon less favorably than those who do not. In general, this seems to significantly weaken the assurances that Relying > Parties have as to whether or not CAs will follow the BRs, and to place > Mozilla specifically, and this Forum generally, into a role of determining > whether or not revocation is required and whether the timelines are > reasonable. Given that the vast majority (all?) of the non-compliance > incidents we’ve seen have been argued as defects (in ACLs, in policy, in > procedures), I do worry that this encourages CAs to not revoke, whether > it’s a major matter - such as malformed DNS - or a “minor” matter (if such > a thing exists). > > I agree with this. The intent of the additional language stating that this forum must discuss any decision not to revoke based on lack of risk is intended to strengthen the requirement by forbidding CAs from unilaterally declaring that a particular issue is not a security risk, but the actual effect could be that it encourages CAs to try to punt every revocation decision to this forum. This language will need to change or be removed. This seems to create some of the wrong incentives, although I do understand > and appreciate the point from which it is coming from, in that it seems to > actively discourage revocation, unless and until Mozilla explicitly > requires it. This is certainly a position Mozilla could take, but it does > seem to be significantly different than the past conversations. > > I’m not yet sure how to best suggest clarifications, but I did want to > highlight how the relatively small changes seem to do more to significantly > alter policy, rather than to clarify existing policy. > > I welcome suggestions for how to improve the language in this guidance with the aim of adding clarity without introducing more risk. - Wayne _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
