Re: EJBCA defaulting to 63 bit serial numbers

[Wayne Thayer via dev-security-policy]

On Sat, Mar 9, 2019 at 12:49 PM Dimitris Zacharopoulos via
dev-security-policy  wrote:

>
> 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"?
>
>
Speaking as the CA Certificate Policy Module Owner, and being aware of the
discussions that led to the current wording, I believe the intent of the BR
language is for serial numbers to contain 64-bits of entropy. I certainly
agree that the language could be improved, but I think the meaning is clear
enough and yes I do expect CAs to treat serial numbers that do not actually
consist of 64-bits of entropy as a BR and a Mozilla policy section 5.2
violation.

I believe answering this question would bring some clarity to the
> participating CAs.
>
> Thank you for pointing this out Dimitris. While it seems obvious to me, I
can understand if there is some uncertainty resulting from the opposing
arguments.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EJBCA defaulting to 63 bit serial numbers

[James Burton via dev-security-policy]

What concerns me overall in this discussion is the fact that some CAs
thought it was completely acceptable to barely scrape through to meet the
most basic minimum of requirements. I hope these CAs have a better security
posture and are not operating at the minimum.

Thank you,

Burton

On Sat, Mar 9, 2019 at 8:24 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Sat, Mar 9, 2019 at 2:49 PM Dimitris Zacharopoulos 
> wrote:
>
> > 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 think for Mozilla, this is best answered by Kathleen, Wayne, the Mozilla
> CA Policy Peers, and which I am not.
>
> On behalf of Google and the Chrome Root Authority Program, and consistent
> with past discussion in the CA/Browser Forum regarding expectations [1], we
> do view this as a violation of the Baseline Requirements. As such, the
> providing of incident reports, and the engagement with public discussion of
> them, represents the most transparent and acceptable course of action.
>
> Historically, we have found that the concerns around incident reporting
> have been best addressed through a single, unified, and transparent
> engagement in the community. Much as ct-pol...@chromium.org has happily
> and
> intentionally supported collaboration from counterparts at Mozilla and
> Apple, Mozilla has historically graciously allowed  for the unified
> discussion on this mailing list, and the use of their bugtracker for the
> purpose of engaging publicly and transparently on incident reports that
> affect the Web PKI. Should Mozilla have a different interpretation of the
> Baseline Requirements’ expectations on this, we’d seek guidance as to
> whether or not the bug tracker and mailing list continue to represent the
> best place for discussion of this specific issue, although note that
> historically, this has been the case.
>
> This should make it clear that CAs which extracted 64 bits of entropy as an
> input to an algorithm that then set the sign bit to positive and
> potentially decreasing the entropy to 63 bits, as opposed to
> unconditionally guaranteeing that there was a positive integer with _at
> least_ 64 bits of entropy, are non-compliant with the BRs and program
> expectations, and should file incident reports and include such disclosures
> in their reporting by and assertions to auditors.
>
> [1]
> https://cabforum.org/pipermail/public/2016-April/007245.html
> ___
> 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: EJBCA defaulting to 63 bit serial numbers

[Ryan Sleevi via dev-security-policy]

On Sat, Mar 9, 2019 at 2:49 PM Dimitris Zacharopoulos 
wrote:

> 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 think for Mozilla, this is best answered by Kathleen, Wayne, the Mozilla
CA Policy Peers, and which I am not.

On behalf of Google and the Chrome Root Authority Program, and consistent
with past discussion in the CA/Browser Forum regarding expectations [1], we
do view this as a violation of the Baseline Requirements. As such, the
providing of incident reports, and the engagement with public discussion of
them, represents the most transparent and acceptable course of action.

Historically, we have found that the concerns around incident reporting
have been best addressed through a single, unified, and transparent
engagement in the community. Much as ct-pol...@chromium.org has happily and
intentionally supported collaboration from counterparts at Mozilla and
Apple, Mozilla has historically graciously allowed  for the unified
discussion on this mailing list, and the use of their bugtracker for the
purpose of engaging publicly and transparently on incident reports that
affect the Web PKI. Should Mozilla have a different interpretation of the
Baseline Requirements’ expectations on this, we’d seek guidance as to
whether or not the bug tracker and mailing list continue to represent the
best place for discussion of this specific issue, although note that
historically, this has been the case.

This should make it clear that CAs which extracted 64 bits of entropy as an
input to an algorithm that then set the sign bit to positive and
potentially decreasing the entropy to 63 bits, as opposed to
unconditionally guaranteeing that there was a positive integer with _at
least_ 64 bits of entropy, are non-compliant with the BRs and program
expectations, and should file incident reports and include such disclosures
in their reporting by and assertions to auditors.

[1]
https://cabforum.org/pipermail/public/2016-April/007245.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EJBCA defaulting to 63 bit serial numbers

[Tomas Gustavsson via dev-security-policy]

Hi, 

As others have already pointed out the subject in this thread is incorrect. 
There are no, and has never been any, 63 bit serial numbers created by EJBCA.

As the specific topic has already been discussed, I just wanted to reference to 
the post[1] with technical details, if anyone ends up in this thread without 
background.

Regards,
Tomas

[1]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/nnLVNfqgz7g%5B26-50%5D
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EJBCA defaulting to 63 bit serial numbers

[Dimitris Zacharopoulos via dev-security-policy]

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 > 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 pres

Re: EJBCA defaulting to 63 bit serial numbers

[Ryan Sleevi via dev-security-policy]

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  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.

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 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.

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.

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.

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.co

Re: A modest proposal for a better BR 7.1

[James Burton via dev-security-policy]

Matt's right, you need to discussion this on the CAB Forum.

Burton

On Sat, Mar 9, 2019 at 9:10 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Mar 08, 2019 at 08:43:49PM -0600, Matthew Hardeman via
> dev-security-policy wrote:
> > I know this isn't the place to bring a BR ballot, but I'm not presently a
> > participant there.
>
> My understanding is that discussing potential BR changes here is actively
> counter-productive, because of intellectual property concerns around the
> BRs.  Basically, if you want to propose a change in the BRs, you really
> *have* to sign up as an interested party and do the IPR agreement dance,
> otherwise... problems.  And no, disclaiming copyrights, etc probably isn't
> enough, because it's far more complicated than that.
>
> - Matt
>
> ___
> 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: A modest proposal for a better BR 7.1

[Matt Palmer via dev-security-policy]

On Fri, Mar 08, 2019 at 08:43:49PM -0600, Matthew Hardeman via 
dev-security-policy wrote:
> I know this isn't the place to bring a BR ballot, but I'm not presently a
> participant there.

My understanding is that discussing potential BR changes here is actively
counter-productive, because of intellectual property concerns around the
BRs.  Basically, if you want to propose a change in the BRs, you really
*have* to sign up as an interested party and do the IPR agreement dance,
otherwise... problems.  And no, disclaiming copyrights, etc probably isn't
enough, because it's far more complicated than that.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy