> 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
> The rule as written requires that the output bits have come from a CSPRNG.
> But it doesn't say that they have to come from a single invocation of a
> CSPRNG or that they have to be collected as a contiguous bit stream from the
> CSPRNG with no bits of output from the CSPRNG discarded and
On Tue, Mar 12, 2019 at 2:49 PM Hector Martin 'marcan' via
dev-security-policy wrote:
> What I'm saying is that merely sticking to the most convenient
> interpretation for you and deflecting all responsibility for how we
> ended up here is not productive, and does not scream trustworthiness.
>
On 12/03/2019 21.10, Mike Kushner via dev-security-policy wrote:
>>> There are no, and has never been any, 63 bit serial numbers created by
>>> EJBCA.
>>
>> ... lead me to significantly reduce my trust in those making them, and
>> their ability to correctly interpret security-critical standards
On Tue, Mar 12, 2019 at 12:07 PM Mike Kushner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Unless you're going under the presumption that the MSB doesn't count as a
> part of the serial number (and I've never seen an RFC or requirement
> pointing to that being the
> I think when it comes to specifications with cryptographic relevance (as
> unpredictable serials are), less is more; the more inflexible and
> unambiguous the spec is, the less likely it will be "creatively
> interpreted" in a manner that bypasses the whole point. To someone with
> crypto
On 12/03/2019 07:54, Ryan Sleevi via dev-security-policy wrote:
On Mon, Mar 11, 2019 at 5:35 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Since choice 1 is a logical consequence of "containing 64 bits of random
data", I was always under the
Matthew Hardeman via dev-security-policy
writes:
>But, maybe "non-sequential" doesn't mean that. It's a pity a concept like
>that isn't clearly objective.
I assume what the text was meaning to say was "unpredictable", but it was
unfortunately phrased badly, presumably as a rushed response to
On Mon, Mar 11, 2019 at 5:35 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Since choice 1 is a logical consequence of "containing 64 bits of random
> data", I was always under the impression, that choice 2 was meant by the
> BRGs. If choice 1 is
> Von: Ryan Sleevi
> Betreff: Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to
> 63 bit serial numbers)
>
> On Mon, Mar 11, 2019 at 1:18 PM Buschart, Rufus via dev-security-policy
> <mailto:dev-security-policy@lists.mozilla.org> >
On Mon, Mar 11, 2019 at 10:00 AM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Glad you agree 64bit serial numbers can have no fixed bits, as a fixed bit
> in a 64 bit serial number would result in less than 64 bits of entropy. If
> you are going to
On Mon, Mar 11, 2019 at 12:18 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I really like reading this discussion about 64 vs. 63 bits and how to read
> the BRGs as it shows a lot of passion by all of us in the PKI community.
> Never the less, in
On Mon, Mar 11, 2019 at 1:18 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear mdsp!
>
> I really like reading this discussion about 64 vs. 63 bits and how to read
> the BRGs as it shows a lot of passion by all of us in the PKI community.
> Never
aymion Reynolds via dev-security-policy
> Gesendet: Montag, 11. März 2019 18:00
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: EJBCA defaulting to 63 bit serial numbers
>
> On Monday, March 11, 2019 at 8:57:27 AM UTC-7, Ryan Sleevi wrote:
> > I don’t think ther
On Monday, March 11, 2019 at 8:57:27 AM UTC-7, Ryan Sleevi wrote:
> I don’t think there’s anything inherently wrong with an approach that uses
> a fixed prefix, whether of one bit or more, provided that there is at least
> 64 bits of entropy included in the serial prior to encoding to DER.
>
>
I don’t think there’s anything inherently wrong with an approach that uses
a fixed prefix, whether of one bit or more, provided that there is at least
64 bits of entropy included in the serial prior to encoding to DER.
This means a scheme with guarantees a positive INTEGER will generate
*encoded*
On Saturday, March 9, 2019 at 5:15:50 PM UTC-7, Wayne Thayer wrote:
> 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
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
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
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
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
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
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
Dimitris Zacharopoulos via dev-security-policy
writes:
>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.
There's also an unknown number of CAs not using EJBCA that may have
Adding to this discussion, and to support that there were -in fact-
different interpretations (all in good faith) please check the issue I
had created in Dec 2017 https://github.com/awslabs/certlint/issues/56.
My simple interpretation of the updated requirement in 7.1 at the time
was that "no
On Fri, Mar 8, 2019 at 7:55 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:
>
> > I consider that only a single CA has represented any ambiguity as being
> > their explanation as to why the
On Fri, Mar 8, 2019 at 10:54 PM Matthew Hardeman
wrote:
>
>
> On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:
>
>> I consider that only a single CA has represented any ambiguity as being
>> their explanation as to why the non-compliance existed, and even then,
>> clarifications to resolve
On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:
> I consider that only a single CA has represented any ambiguity as being
> their explanation as to why the non-compliance existed, and even then,
> clarifications to resolve that ambiguity already existed, had they simply
> been sought.
>
On Fri, Mar 8, 2019 at 10:29 PM Matthew Hardeman
wrote:
> I would appreciate your thoughts on it.
>
I consider the matter more than settled, based on the clear historic
evidence, so I see no value in engaging further. The amount of time and
energy necessary to evaluate and reason about it seems
On Fri, Mar 8, 2019 at 8:52 PM Ryan Sleevi wrote:
I appreciate the attention to detail, but I find it difficult to feel that
> it is a good faith effort that is designed to produce results consistent
> with the goals that many of this community have and share, and thus don't
> think it would be
On Fri, Mar 8, 2019 at 7:22 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Pursuant to the plain language of 7.1 as written, that circumstance --
> regardless of how it would occur -- would appear to be a misissuance.
>
I've already addressed this
On Friday, March 8, 2019 at 6:05:05 PM UTC-6, Ryan Sleevi wrote:
> You're absolutely correct that two certificates, placed next to eachother,
> could appear sequential. Someone might then make a claim that the CA has
> violated the requirements. The CA can then respond by discussing how they
>
On Fri, Mar 8, 2019 at 6:50 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am well aware of the reason for the entropy in the certificate serial
> number. What I'm having trouble with is that there can be no dispute that
> two certificates with
On Fri, Mar 8, 2019 at 3:10 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Having sequential serial numbers is not problematic. Having *predictable*
> serial numbers is problematic.
My problem with this is that, if we parse the english language
Hi Jakob,
On Thursday, March 7, 2019 at 7:30:03 PM UTC+1, Jakob Bohm wrote:
> In the cause of the other discussion it was revealed that EJBCA by PrimeKey
> has apparently:
>
> 1. Made serial numbers with 63 bits of entropy the default. Which is
> not in compliance with the BRs for globally
On Thu, Mar 07, 2019 at 08:47:46PM -0600, Matthew Hardeman via
dev-security-policy wrote:
> On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > Past analysis and discussion have shown the interpretation is hardly
> > specific to
On Friday, 8 March 2019 04:28:17 UTC+1, Matt Palmer wrote:
> On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via
> dev-security-policy wrote:
> > On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > > But BRs are not to be
Matt Palmer via dev-security-policy
writes:
>If you generate a 64-bit random value, then discard some values based on any
>sort of quality test, the end result is a 64-bit value with less-than-64-bits
>of randomness.
That's not what 7.1 says, merely:
CAs SHALL generate non-sequential
On Thu, Mar 7, 2019 at 9:28 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> The "CS" is "CSPRNG" stands for "cryptographically secure", and "CSPRNG" is
> defined in the BRs.
>
Yes. There are various levels of qualification and quality for algorithms
On Thu, Mar 7, 2019 at 9:47 PM Matthew Hardeman wrote:
>
> The actual text of the guideline is quite clear -- in much the same manner
> that frosted glass is.
>
> "Effective September 30, 2016, CAs SHALL generate non-sequential
> Certificate serial numbers greater than zero (0) containing at
On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via
dev-security-policy wrote:
> On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > But BRs are not to be interpreted, just to be applied to the letter,
> > whether it makes
On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> But BRs are not to be interpreted, just to be applied to the letter,
> whether it makes sense or not. When it no longer makes sense, the wording
> can be improved for the future.
>
Ballot 164 statement of intent is pretty clear: (arbitrary) 64 bit of
randomness was needed to defeat collisions in broken MD5.
With SHA2, the missing 1 bit does not seem to have any impact on the possible
collisions.
But BRs are not to be interpreted, just to be applied to the letter, whether
On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Past analysis and discussion have shown the interpretation is hardly
> specific to a single CA. It was a problem quite literally publicly
> discussed during the drafting and
On Thu, Mar 7, 2019 at 9:18 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Oh, and the BR's need an update so that half the CAs on the planet aren't
> suddenly non-BR compliant based on the DarkMatter-specific interpretation.
Past analysis and
On Thu, Mar 7, 2019 at 8:20 PM Peter Gutmann
wrote:
> I swear I didn't plan that in advance :-).
I believe you. When the comedy is this good, it's because it wrote itself.
:-)
___
dev-security-policy mailing list
Matthew Hardeman writes:
>As if on queue, comes now GoDaddy with its confession.
I swear I didn't plan that in advance :-).
Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
I wrote:
As I said above, you can get arbitrarily silly with this. I'm sure if we
looked at other CA's code at the insane level of nitpickyness that
DarkMatter's use of EJBCA has been examined, we'd find reasons why their
implementations are non-compliant as well.
Seconds after sending
On Thu, Mar 7, 2019 at 8:14 PM Peter Gutmann
wrote:
>
> As I said above, you can get arbitrarily silly with this. I'm sure if we
> looked at other CA's code at the insane level of nitpickyness that
> DarkMatter's use of EJBCA has been examined, we'd find reasons why their
> implementations are
Matthew Hardeman writes:
>Can the CA's agent just request the cert, review the to-be-signed certificate
>data, and reject and retry until they land on a prime? Then issue that
>certificate?
>
>Does current policy address that? Should it?
Yeah, you can get arbitrarily silly with this. For
On Thu, Mar 7, 2019 at 7:47 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 0. Given that the value of 64 bits was pulled out of thin air (or possibly
>less well-lit regions), does it really matter whether it's 63 bits, 64
>bits, 65 3/8th bits,
Jakob Bohm via dev-security-policy
writes:
>This raises 3 derived concerns:
And a fourth, which has been overlooked during all the bikeshedding...
actually I'll call it question 0, since that's what it should have been:
0. Given that the value of 64 bits was pulled out of thin air (or
In the cause of the other discussion it was revealed that EJBCA by PrimeKey
has apparently:
1. Made serial numbers with 63 bits of entropy the default. Which is
not in compliance with the BRs for globally trusted CAs and SubCAs.
2. Mislead CAs to believe this setting actually provided 64
53 matches
Mail list logo
