On 9/3/2019 2:37 μ.μ., Ryan Sleevi wrote:
I’m chiming in, Dimtris, as it sounds like you may have
unintentionally misrepresented the discussion and positions, and I
want to provide you, and possibly HARICA, the guidance and clarity it
needs in this matter.
On Sat, Mar 9, 2019 at 12:46 AM Dimitris Zacharopoulos via
dev-security-policy <[email protected]
<mailto:[email protected]>> wrote:
I am personally shocked that a large part of this community considers
that now is the time for CAs to demonstrate "agility to replace
certificates", as lightly as that, without considering the
significant
pain that Subscribers will experience having to replace hundreds of
thousands of certificates around the globe. It is very possible that
Relying parties will also suffer availability issues.
I believe this significantly misunderstands the discussion and
motivation. Having read all of the discussion to date, I do not
believe this is at all an accurate framing of the expectations or
motivations. I would humbly ask that you provide citations to back
this claim.
I must admit that I may have over-reacted with this one, taking one
particular paragraph from
https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/HNDX5LaZCAAJ
which made me focus on the word "agility" as a requirement that CAs are
ultimately responsible of building, and the sooner the better. Having
worked with Subscribers that had a very hard time to manually install
certificates in legacy web servers, I am very worried that CAs will have
to repeat these tasks because for several cases, there are no tools to
assist the automation process.
You are correct if you were to say one or two people have provided
such a goal, but that’s certainly not consistent with the majority of
the discussion to date from the root program participants. Indeed, the
expectation expressed is that, *as with every other incident*, the CA
consistently follow the expectations.
I highlight this, because I don’t think it’s reasonable to conflate
existing expectations, which have been repeatedly clarified, as
somehow motivated by some other motivation based on one or two
participants’ views.
If you truly feel this way, please revisit the discussion in
https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/S2KNbJSJ-hs
, as I hope that mine and Wayne’s responses can demonstrate this.
Judging by that thread, only a single voice has expressed something
remotely as to how you’ve phrased it.
I stand corrected.
I don't know if others share the same view about the
interpretation of
7.1 but it seems that some highly respected members of this community
did. If we have to count every CA that had this interpretation,
then I
suppose all CAs that were using EJBCA with the default configuration
have the same interpretation.
I believe this also misunderstands the discussion to date, and as a
consequence misrepresents this. I don’t believe it is reasonable or
fact based to suggest that the CAs that had incidents necessarily
shared the interpretation. The incident reports demonstrate that there
are a myriad reasons, beyond interpretive differences, that one can
find themselves in such a situation. Avoiding conflating the two is
necessary, although if you feel it is justified, then I would implore
you when summarizing others views to support your view, that you
provide the direct links and references. This makes it easier to
respond to and provide CAs the necessary clarity of expectations, as
well as allows other participants to evaluate and judge themselves the
accuracy of the summary.
I think I provided a link to an issue in the github repository of
cablint where this topic was briefly discussed in the past.
Although I agree with you on that summarizing others views without them
explicitly saying so (my comment for CAs using EJBCA with the default
configuration) is not very objective, I see that over the past years,
more and more CAs avoid to participate in m.d.s.p. leaving us with no
choice but to "guess". That is unfortunate. At some point, the issue of
less-and-less CA participation in m.d.s.p. should be discussed.
BTW, the configuration in EJBCA that we are talking about, as the
default number of bytes, had the number "8" in the setting,
resulting in
64-bits, not 63. So, as far as the CA administrator was concerned,
this
setting resulted in using 64 random bits from a CSPRNG. One would
have
to see the internal code to determine that the first bit was
replaced by
a zero.
This is exactly the point. CAs have an obligation to understand the
code they’re using, regardless of the software platform. The failing
is not with EJBCA, it is with the CAs that have done so. While there
are a number of considerable and profound benefits to using EJBCA -
most notably, it seems, in the dearth of issues the CAs presently
reporting have had compared to those using closed-source platforms or
home-grown platforms - the strength of that platform is not a
reasonable mitigation for the CAs not being thorough.
As others have mentioned [1], building a fully custom system from
scratch seems to bring a lot more risks to the ecosystem and although I
agree with the general expectation you described (that CAs must verify
the software's compliance with all the policies/requirements set by the
BRs and Root store programs), for this particular issue, it seems very
unlikely that a CA could perform this level of code analysis, especially
if they interpreted the BRs that all that is needed is 64 random bits
from a CSPRNG. Thus, for this particular topic, you might be raising the
bar to an unreachable level.
Every CA, when Ballot 164 was passed, had a clear obligation to review
how they construct serial numbers, from the technical implementation
to the policy configuration. CAs that did so could have placed in a
request for the newly announced functionality, or, given the open
source nature, contributed such a change themselves.
IMO that is the main difference with other cases of mis-issuance. EJBCA
constructed serial numbers according to the policy and the technical
implementation was getting 64 bits of entropy from a CSPRNG. To the best
of my knowledge and after reading the response from PrimeKey and other
community members [2], [3] (to list some), my conclusion is that this
was certainly not a creative interpretation of the requirements.
That is guidance that stands regardless of the serial number, and
trying to conflate it as somehow a unique response to this incident
only does it a disservice.
IMO, Mozilla should also treat this as an incident and evaluate the
specific parameters (strict interpretation of section 7.1, CAs did
not
deliberately violate the requirement, a globally-respected software
vendor and other experts had a different allowable interpretation
of a
requirement, the security impact on Subscribers and Relying
Parties for
1 bit of entropy is negligible), and consider treating this
incident at
least as the underscore issue. In the underscore case, there was a
SCWG
ballot with an effective date where CAs had to ultimately revoke all
certificates that included an underscore.
The response from Wayne in
https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/S2KNbJSJ-hs
already sets the clear expectations, which are and have been
consistent with how we handle incidents. It’s thoroughly unproductive
to have this discussion every time there is an incident, especially
when the principles and goals are quite sound and to the benefit of
users. There is nothing punitive about them, and rather clear guidance
about the expectations.
While a point-by-point comparison to underscores could be made, with
the result being a very clear diverengence in the material facts, the
end result would still be the consistent application of principles. I
don’t think treating misissuances as popularity contests is indeed
productive - that same logic would have us ignore many of the
requirements, given
https://wiki.mozilla.org/CA/Incident_Dashboard .
I believe Root programs have the necessary policy in place to treat
incidents -in exceptional circumstances- on a case-by-case basis. Wayne
had mentioned in a previous post [4] that Mozilla doesn't want to be
responsible for assessing the potential impact, but that statement took
for granted that there was a definite violation of a requirement.
The question I'm having trouble answering, and I would appreciate if
this was answered by the Mozilla CA Certificate Policy Module Owner, is
"does Mozilla treat this finding as a violation of the current language
of section 7.1 of the CA/B Forum Baseline Requirements"?
I believe answering this question would bring some clarity to the
participating CAs.
Thank you,
Dimitris.
[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/7WuWS_20758/HfyVD5-sCAAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/OVKywVZIBgAJ
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/KSaNV9-vAAAJ
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/hbo2SCH8c_M/efVpglelBQAJ
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
