Re: EJBCA defaulting to 63 bit serial numbers

[Jaime Hablutzel via dev-security-policy]

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

It looks like it would be useful to have this exceptions handling procedure in 
place, especially for situations like the current one with with low security 
impact but a high potential for producing service disruption everywhere.

Is Mozilla reassessing to introduce a procedure to handle exceptions?.
___
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

[Jaime Hablutzel via dev-security-policy]

> 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 replaced by 
> further invocation of the CSPRNG.

This reasoning has the potential to decrease the security that is provided by a 
requirement for a given minimum entropy and I'll try to illustrate my point 
better with the following fictional situation where the requirement would be 
something like this:

> ... CAs SHALL generate non-sequential Certificate serial numbers greater than 
> zero (0) containing at least 8 bits of output from a CSPRNG.

So we think that we can comply by generating serial numbers with exactly 1 byte 
fixed size as the requirement asks for 8 bits.

Then we start generating serial number candidates, but we need to perform some 
filtering:

1. First, as we want to produce one byte constant length positive serial 
numbers we filter out values where the high-order bit is 1 and we are left with 
only 128 possible values.
2. Then, we filter out the 0 value and now we have 127 possible values to 
choose from.
3. Finally, we have to discard serial numbers assigned to previously issued 
certificates and let's say we've issued 126 certificates previously, so now 
we're left with only one possible serial number to choose from.

And there it is, full predictability for the next serial number to be generated.

Now, this is just an example but my point is that the interpretation that 
allowed for one byte fixed size serial numbers was a clear mistake in the 
context of this fictional requirement.

Nevertheless, in real life we would be reducing 64 bits by just a little (e.g. 
to 63 bits), but anyway, the security is being reduced, maybe not enough to 
allow for a real attack... but there is a reduction.

Finally, as I see it, CA's should ellaborate their serial numbers generation 
strategy guaranteeing that generated serial numbers at all times, now and in 
the future (after issuing many quadrillions of certificates), will always 
contain at least 64 bits of unfiltered entropy within them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Ryan Sleevi via dev-security-policy]

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.
> The various actors in the WebPKI need to strive for a secure
> environment, not act adversarially. This includes both acting in good
> faith (e.g. not attempting to pursue "creative interpretations"), but
> also, equally, recognizing when actions and decisions may have
> unexpectedly and unintentionally contributed to a problem, and making
> changes to eliminate that possibility in the future.
>

Hey Hector,

I tried to capture in [1] that the interpretation being offered here is
consistent with past discussions. While I understand you may disagree with
the documentation, I also tried to capture in [1] how it avoids a different
problem which has been discussed in this Forum.

As it relates to the remarks about assigning blame or pushing to their
customers, I think a more charitable read of those remarks is, again,
consistent with long-standing expectations of the policy and past
discussions in the Forum, the CA is ultimately responsible for compliance.
We have CAs using vendors that are far less responsive or engaged in this
Forum, and which software produces things far less compliant, and I want to
make sure we don't discourage participation by not assuming good faith or
good intent. I totally understand that your personal opinions will
naturally (and should naturally!) impact the choice of CA software you run,
so I don't want you to think I'm shilling for a particular vendor, but I
also want to make sure we're assigning responsibility appropriately.

I definitely think it behoves all participants - CAs, software vendors,
random users - to strive to avoid "creative interpretations", for the
reasons you mention. I think the extent of such creative explorations
should be in the pursuit of providing stronger guidance - whether as a
matter of policy or to be enshrined in the requirements - rather than
excuse or dismiss problems. However, I don't think the current discussion
is about dismissing the problems - but about ensuring meaningful technical
accuracy so that there's a clear understanding of the issue.

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/13lXh5gomB8/Ie7AnHC9BwAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Hector Martin 'marcan' via dev-security-policy]

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 in the 
>> future. Not everyone gets things right the first time, but owning up to 
>> problems, understanding the technical issue at hand, and accepting 
>> responsibility is a basic tenet of earning community trust.
> 
> I'm sorry you feel that way, but here's the thing. EJBCA produces whatever 
> length serial numbers you request from it, restricted to an even octet and 
> within the span of 4 to 20. EJBCA set to produce 8 octet serial numbers will 
> produce exactly 64 bit serial numbers, including the MSB. Are you suggesting 
> that a logical behavior for a 8 octet serial number would be to produce a 9 
> octet serial number and pad the first 7 bits? 
> EJBCA will produce exactly the serial number you've specified, and give you 
> as much entropy as your serial length allows. 

It's clear that multiple CAs made a configuration mistake here, and in
general when multiple users make the same mistake when configuring
software, that points to a usability problem in the software. Your
statement is just shoving the entirety of the issue on CAs, while
picking the interpretation most favorable to EJBCA. While the ultimate
responsibility certainly lies with the CAs, it is not helpful for EJBCA
to be so dismissive of the subject.

We can make several accurate statements about EJBCA configured to an
8-octet serial number size (the default):

- It generates serial numbers with 63 bits of entropy (or negligibly
less, if we consider the duplicate-removal code)
- It generates serial numbers from 1 to 2**63 - 1
- It generates serial numbers with 63 bits of effective output from a
CSPRNG (the MSB having been coerced to zero, and thus effectively
eliminated; that this is done by "trying until you get lucky" is an
irrelevant implementation detail and has no bearing on the result)
- It generates 8-byte serial numbers in encoded DER form (which is 64
bits worth of DER).

In other words, only after DER encoding does the serial number become 64
bits in length. The statement "There are no, and has never been any, 63
bit serial numbers created by EJBCA." presumes that bit length is being
measured at one specific point consistent with what EJBCA is actually
doing, which may not be what users expect.

I would in fact expect that if software is taking N bits of output from
a CSPRNG (with the goal of providing N bits of entropy), that it would
then encode it as a positive integer in DER, which indeed requires
adding an extra zero octet to contain the sign bit when the MSB of the
original value is 1. In fact, I would dare say that the output size is
less likely to be relevant to users than the amount of entropy contained
within, and that if a fixed output size is desired, a solution much less
likely to result in people shooting themselves in the foot is to prepend
a fixed constant byte 0x01<=0x7f to the serial before encoding.

The EJBCA configuration file defaults state, verbatim:
> # The length in octets of certificate serial numbers generated. 8 octets is a 
> 64 bit serial number.
> # It is really recommended to use at least 64 bits, so please leave as 
> default unless you are really sure, 
> # and have a really good reason to change it.
> # Possible values: between 4 and 20
> # Default: 8
> #ca.serialnumberoctetsize=8

Considering:

1) The BRs require 64 bits of output from a CSPRNG (which can only be
reasonably interpreted by anyone familiar with the subject as as 64 bits
of entropy; anything else is just 'creative interpretation')
2) The configuration file *explicitly* discourages changes.
3) All references are to "64 bits", with no mention that this refers to
the *encoded* serial number and, thus, one of those bits is always zero

Then it's not surprising that multiple CAs made the same mistake; heck,
I probably would've done the same too, without reviewing the code.

> EJBCA is a general CA implementation with multiple use cases, so it's not 
> built to specifically conform to cabf requirements. As Ryan Sleevi pointed 
> out - It is up to the end customer to understand their own requirements, and 
> to understand that a 64 bit signed integer can in no way or fashion contain 
> 64 bits of entropy. 
> 
> 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 case, EJBCA does not produce 63 bit serial numbers. 

The MSB is part of the serial number *encoding*. It is part of the
serial number field as encoded in a DER certificate. It is not part of
the *number* itself, the integer. For example, the MSB has no meaning
when certificate serial numbers are e.g. expressed in integer decimal
notation. A 64-bit positive 

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Ryan Sleevi via dev-security-policy]

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 case, EJBCA does not produce 63 bit serial
> numbers.
>

As this has come up in discussion in the past [1], particularly as called
out by Peter Bowen [2], there's been some ambiguity as to whether limits on
the maximum size of serial numbers apply to the encoded form or the
unencoded form. This came up as well during the Ballot 164 discussion [3].

I highlight this, because I think your response is absolutely consistent
with the past discussion - namely, that treating the sign-bit as part of
the serial number is consistent. By treating the sign-bit as part of the
length, even though it is conceptually an encoding issue of DER/BER, as
opposed to fundamental to the ASN.1 version, this naturally leads to a
conclusion that there are 159 bits available for the CA to control, since
the most significant bit, the sign bit, MUST be 0.

The confusion, however, that I think is being highlighted here, is whether
the setting is perceived as a configuration of the 'output' serial number
(in which case, you're guaranteeing 8 octets) or the 'CA-controlled' serial
number (in which case, only 63 bits are being contributed by the CA). The
interpretation that EJBCA is applying - in which the configuration
specifies the hard upper bound of the encoded serial - is a very reasonable
configuration, given the implications to the 20 octet maximum captured in
RFC 5280, thus avoiding the issues in [1], although introducing the issues
in [3].

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/74sItqcvBgAJ

[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/96ENFxrGBgAJ
[3] 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: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Mike Kushner via dev-security-policy]

> 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 experience and an understanding of the intent, the current 
> language clearly means "take 64 bits from a CSPRNG once, put whatever 
> you want around them (or nothing), DER encode, and stuff it into the 
> serial field". But clearly some implementers interpreted this 
> differently, and here we are.
> 
> That said, I do think the current exercise is, shall we say, bringing 
> out some interesting opinions on what an appropriate response to the 
> problem is. Statements such as:
> 
> > 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 in the 
> future. Not everyone gets things right the first time, but owning up to 
> problems, understanding the technical issue at hand, and accepting 
> responsibility is a basic tenet of earning community trust.

I'm sorry you feel that way, but here's the thing. EJBCA produces whatever 
length serial numbers you request from it, restricted to an even octet and 
within the span of 4 to 20. EJBCA set to produce 8 octet serial numbers will 
produce exactly 64 bit serial numbers, including the MSB. Are you suggesting 
that a logical behavior for a 8 octet serial number would be to produce a 9 
octet serial number and pad the first 7 bits? 
EJBCA will produce exactly the serial number you've specified, and give you as 
much entropy as your serial length allows. 

EJBCA is a general CA implementation with multiple use cases, so it's not built 
to specifically conform to cabf requirements. As Ryan Sleevi pointed out - It 
is up to the end customer to understand their own requirements, and to 
understand that a 64 bit signed integer can in no way or fashion contain 64 
bits of entropy. 

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 case, EJBCA does not produce 63 bit serial numbers. 

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

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Hector Martin 'marcan' via dev-security-policy]

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 impression, that choice 2 was meant by the
BRGs. If choice 1 is meant, then I think the requirement of being
'non-sequential' is just some lyrical sugar in the BRGs. Maybe there is a
third definition of "sequential" that I haven't thought of?



I had definitely seen it as lyrical sugar, trying to *really* hammer the
point of concern (of predictable serials). This is an example where
providing guidance in-doc can lead to more confusion, rather than less.

For example, a "confused" reading of the BR requirement would say "at least
64-bits of entropy" by generating a random number once [1] and including it
in all subsequent serials, monotonically increasing +1 each time :)


Sony tried this (minus the increment) when generating random nonces for 
ECDSA signing, apparently generating the nonce once during key 
generation, and reusing it for all subsequent signing operations [1]. 
That worked wonders for them *cough* :)


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 experience and an understanding of the intent, the current 
language clearly means "take 64 bits from a CSPRNG once, put whatever 
you want around them (or nothing), DER encode, and stuff it into the 
serial field". But clearly some implementers interpreted this 
differently, and here we are.


That said, I do think the current exercise is, shall we say, bringing 
out some interesting opinions on what an appropriate response to the 
problem is. Statements such as:



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 in the 
future. Not everyone gets things right the first time, but owning up to 
problems, understanding the technical issue at hand, and accepting 
responsibility is a basic tenet of earning community trust.


[1] https://mrcn.st/t/1780_27c3_console_hacking_2010.pdf pp. 122-129

--
Hector Martin "marcan"
Public key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Peter Gutmann via dev-security-policy]

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 "MD5
considered harmful today" which took advantage of the fact that RapidSSL used
a counter to create its serial numbers.

Given that we've now got several more interpretations of what 7.1 is
requiring, and it's only Monday (at least for you lot), I think this really,
really needs an update to clarify what's actually required.  The 7.1 text is
clearly inadequate to convey precisely what should be going into the serial
number field, given the number of interpretations and the amount of debate
about what is and isn't allowed.  The "modest proposal" sounds like a good
fit for the updated text.

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

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Ryan Sleevi via dev-security-policy]

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 meant, then I think the requirement of being
> 'non-sequential' is just some lyrical sugar in the BRGs. Maybe there is a
> third definition of "sequential" that I haven't thought of?
>

I had definitely seen it as lyrical sugar, trying to *really* hammer the
point of concern (of predictable serials). This is an example where
providing guidance in-doc can lead to more confusion, rather than less.

For example, a "confused" reading of the BR requirement would say "at least
64-bits of entropy" by generating a random number once [1] and including it
in all subsequent serials, monotonically increasing +1 each time :)

[1] https://xkcd.com/221/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Buschart, Rufus via dev-security-policy]

> 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> > wrote:
> 
> > [...] nowhere the BRGs define the exact meaning of "non-sequential".
> > I always read this as serial numbers being totally random, but I know there 
> > is at least one CA out there that constructs its serial
> > numbers like this:
> >
> > serialNumber = timeInMS() + random(64) + 'constant_suffix'
> >
> > Serial numbers constructed like this are strict monotonously rising but 
> > never the less contain 64 bits of random data. Do we
> > consider those as "non-sequential"? We can't even go by the definition in 
> > the dictionary, because according to that (at least the one I
> > consulted), every list of numbers is 'sequential', as one number comes 
> > after another.
> 
> Oof,
> 
> With the requirement to be a positive integer greater than zero, you can 
> think of the serial number space as the one of /natural
> numbers/ (or, because zero is excluded, /whole numbers/) whose DER encoding 
> is less than or equal to twenty bytes. The sequential
> requirement is 'meant' to apply to serial numbers being constructed in order 
> of that sequence of whole numbers - that is, 1, 2, 3 is
> sequential in the set of whole numbers, although 1, 3 would be out of 
> sequence with respect to the set of valid whole number serials.
> 
> If I understand the question correctly, you're describing a situation in 
> which the serial number construct follows a strict ordering, and
> thus itself forms a sequence of whole numbers which maintain sequential order 
> of the set of all valid whole numbers, but which does
> not include each whole number, provided that no two certificates are issued 
> in the same millisecond. If two certificates are issued in
> the same millisecond, the 64-bits of entropy create a probability that the 
> certificates will not appear in sequential (monotonically
> increasing) order. Is that correct?

Yes, exactly 

> Put differently, the question is whether or not the algorithm, as specified, 
> needs to consider two certificates issued at different times
> (and, presuming time is linear and increasing, so too will the serial 
> numbers), or whether it can/should consider certificates issued at
> the same time (and thus be probabilistically out of sequential ordering)
>
> Just making sure I've phrased and framed it correctly.

You got it totally right. Now basically we have two possible definitions of 
"sequential serial numbers":

1) A CA generates "sequential serial numbers" if every generated serial number 
meets the following criteria: serialNumber(n) = serialNumber(n-1)+1, with n 
being the n-th number of generated serial numbers
2) A CA generates "sequential serial numbers" if every generated serial number 
meets the following criteria: serialNumber(n) > serialNumber(n-m) (or 
serialNumber(n) < serialNumber(n-m) ), with n being the n-th number of 
generated serial numbers and m any whole number smaller n

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 meant, then I think the requirement of being 'non-sequential' is 
just some lyrical sugar in the BRGs. Maybe there is a third definition of 
"sequential" that I haven't thought of?

To put in a concrete example: There is a CA that generated the following serial 
numbers:

1843319960437720643048278653969636 on 2019-01-11 09:53:47 UTC
1843319960437694134774632325152679 on 2019-01-10 13:49:21 UTC
1843319960437689654817618007073336 on 2019-01-10 09:05:57 UTC
1843319960437665986305459379269472 on 2019-01-09 09:24:59 UTC
1843319960437653534927818400454844 on 2019-01-08 10:24:51 UTC
1843319960437625653787354520462187 on 2019-01-08 08:40:14 UTC
1843319960437610711593417697551974 on 2019-01-08 08:39:37 UTC

Are those serial numbers sequential? I think, yes, they are, but I admit, there 
are good arguments to say, no, they are not.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and 

Re: EJBCA defaulting to 63 bit serial numbers

[Peter Bowen via dev-security-policy]

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 fix a significant bit it must be beyond the 64th bit.  If
> your 64 bit serial number does not contain 1's in the significant byte, as
> long as you still write 64 full bits of data to the cert with 0's left
> padded, then the desired entropy is achieved and is valid. CAs should keep
> this in mind while building their revocation lists.
>

You can't left pad with zeros in DER.  DER requires that the maximum
padding is a leading zero to set the sign, otherwise no leading zeros.

You could go for more than 64 bit serial length and set the upper bits to
01 to avoid the issue, so the most significant byte is between 64 - 127
inclusive.  You would need to have at least 9 octets for serial number, but
this is no more than what you have 50% of the time now.

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

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Matthew Hardeman via dev-security-policy]

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 the discussion, I miss one interesting aspect. The BRGs
> not only speak about 64 bits as output from a CSPRNG but also about serial
> numbers being "non-sequential". But nowhere the BRGs define the exact
> meaning of "non-sequential". I always read this as serial numbers being
> totally random, but I know there is at least one CA out there that
> constructs its serial numbers like this
>

I'm glad someone else asked, as no one has enjoyed the question in the form
that I presented it.

But I suggest that if "non-sequential" is taken to mean a guarantee that no
two serial numbers shall be numerically adjacent integer values, then I
submit that any serial numbers which only contain what was previously
considered to be 64-bits of entropy and no other data save, perhaps a
leading 0x00 byte if necessary to prevent high-order bit being 1, then the
effective entropy must be considered less because two adjacent values are
effectively blocked by any prior chosen value.

But, maybe "non-sequential" doesn't mean that.  It's a pity a concept like
that isn't clearly objective.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Ryan Sleevi via dev-security-policy]

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 the less, in the discussion, I miss one interesting aspect. The BRGs
> not only speak about 64 bits as output from a CSPRNG but also about serial
> numbers being "non-sequential". But nowhere the BRGs define the exact
> meaning of "non-sequential". I always read this as serial numbers being
> totally random, but I know there is at least one CA out there that
> constructs its serial numbers like this:
>
> serialNumber = timeInMS() + random(64) + 'constant_suffix'
>
> Serial numbers constructed like this are strict monotonously rising but
> never the less contain 64 bits of random data. Do we consider those as
> "non-sequential"? We can't even go by the definition in the dictionary,
> because according to that (at least the one I consulted), every list of
> numbers is 'sequential', as one number comes after another.
>

Oof,

With the requirement to be a positive integer greater than zero, you can
think of the serial number space as the one of /natural numbers/ (or,
because zero is excluded, /whole numbers/) whose DER encoding is less than
or equal to twenty bytes. The sequential requirement is 'meant' to apply to
serial numbers being constructed in order of that sequence of whole numbers
- that is, 1, 2, 3 is sequential in the set of whole numbers, although 1, 3
would be out of sequence with respect to the set of valid whole number
serials.

If I understand the question correctly, you're describing a situation in
which the serial number construct follows a strict ordering, and thus
itself forms a sequence of whole numbers which maintain sequential order of
the set of all valid whole numbers, but which does not include each whole
number, provided that no two certificates are issued in the same
millisecond. If two certificates are issued in the same millisecond, the
64-bits of entropy create a probability that the certificates will not
appear in sequential (monotonically increasing) order. Is that correct?

Put differently, the question is whether or not the algorithm, as
specified, needs to consider two certificates issued at different times
(and, presuming time is linear and increasing, so too will the serial
numbers), or whether it can/should consider certificates issued at the same
time (and thus be probabilistically out of sequential ordering)

Just making sure I've phrased and framed it correctly.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Buschart, Rufus via dev-security-policy]

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 the 
less, in the discussion, I miss one interesting aspect. The BRGs not only speak 
about 64 bits as output from a CSPRNG but also about serial numbers being 
"non-sequential". But nowhere the BRGs define the exact meaning of 
"non-sequential". I always read this as serial numbers being totally random, 
but I know there is at least one CA out there that constructs its serial 
numbers like this:

serialNumber = timeInMS() + random(64) + 'constant_suffix'

Serial numbers constructed like this are strict monotonously rising but never 
the less contain 64 bits of random data. Do we consider those as 
"non-sequential"? We can't even go by the definition in the dictionary, because 
according to that (at least the one I consulted), every list of numbers is 
'sequential', as one number comes after another.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Daymion 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 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* serials in the range of one bit to sixty five bits, of the
> > goal is to use the smallest possible amount of entropy.
> >
> > However, as you note, this issue only arises when one uses the
> > absolute minimum. A robust solution is to use 159 bits, the maximum
> > allowed. This helps ensure that, even when encoded, it will not exceed
> > 20 bytes, this avoiding any client interpretation issues regarding
> > whether the 20 bytes mentioned in 5280 are pre-encoding (the intent)
> > or post-encoding (as a few embedded libraries implemented).
> >
> > Note, however, even with 159 bits of entropy, it’s still possible to
> > have a compressed encoding of one byte, due to zero folding. Using a
> > one bit prefix in addition to the sign bit (thus, two fixed bits in
> > the serial) can help ensure that a leading run of zero bits are not folded 
> > when encoding.
> 
> 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 fix a significant bit it must be beyond the 
> 64th bit.  If your 64 bit serial number does not contain 1's in the
> significant byte, as long as you still write 64 full bits of data to the cert 
> with 0's left padded, then the desired entropy is achieved and is
> valid. CAs should keep this in mind while building their revocation lists.
> ___
> 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

[Daymion Reynolds via dev-security-policy]

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.
> 
> This means a scheme with guarantees a positive INTEGER will generate
> *encoded* serials in the range of one bit to sixty five bits, of the goal
> is to use the smallest possible amount of entropy.
> 
> However, as you note, this issue only arises when one uses the absolute
> minimum. A robust solution is to use 159 bits, the maximum allowed. This
> helps ensure that, even when encoded, it will not exceed 20 bytes, this
> avoiding any client interpretation issues regarding whether the 20 bytes
> mentioned in 5280 are pre-encoding (the intent) or post-encoding (as a few
> embedded libraries implemented).
> 
> Note, however, even with 159 bits of entropy, it’s still possible to have a
> compressed encoding of one byte, due to zero folding. Using a one bit
> prefix in addition to the sign bit (thus, two fixed bits in the serial) can
> help ensure that a leading run of zero bits are not folded when encoding.

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 fix a significant bit it must be beyond the 64th bit.  If your 64 bit 
serial number does not contain 1's in the significant byte, as long as you 
still write 64 full bits of data to the cert with 0's left padded, then the 
desired entropy is achieved and is valid. CAs should keep this in mind while 
building their revocation lists.
___
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]

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* serials in the range of one bit to sixty five bits, of the goal
is to use the smallest possible amount of entropy.

However, as you note, this issue only arises when one uses the absolute
minimum. A robust solution is to use 159 bits, the maximum allowed. This
helps ensure that, even when encoded, it will not exceed 20 bytes, this
avoiding any client interpretation issues regarding whether the 20 bytes
mentioned in 5280 are pre-encoding (the intent) or post-encoding (as a few
embedded libraries implemented).

Note, however, even with 159 bits of entropy, it’s still possible to have a
compressed encoding of one byte, due to zero folding. Using a one bit
prefix in addition to the sign bit (thus, two fixed bits in the serial) can
help ensure that a leading run of zero bits are not folded when encoding.
___
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

[Daymion Reynolds via dev-security-policy]

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

When it comes entropy how does the industry feel about preceding zeros? There 
have been a few online and offline discussions around the requirement for the 
most significant bit to be set to (1). 

For example:
1000        which 
results in an integer of 9223372036854775808.

In my opinion, to achieve a full 64bits of serial number entropy we should not 
fix any of the bits. What are the thoughts on this?

This following value also has 64bits but does not have the most significant bit 
set yet seems to meet the section 7.1 baseline requirements. 

0001        which 
results in an integer of 72057594037927936.

In both cases the certificate field header lists the length of the serial 
number as 64bits. 

For GoDaddy, we will be moving to 128bit serial numbers to resolve this 
permanently.
___
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

[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 

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

Re: EJBCA defaulting to 63 bit serial numbers

[Peter Gutmann 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 even
further interpretations.  For example my code, which I'll point out in advance
has nothing to do with the BR and predates the existence of the CAB Forum
itself, may or may not be compliant with whatever Mozilla's interpretation of
7.1 is.  I literally have no idea whether it meets Mozilla's expectations.  It
doesn't do what EJBCA does, so at least it's OK there, but beyond that I have
no idea whether it does what Mozilla wants or not.  

I assume any number of other CAs are in the same position, and given that if
they guessed wrong they have to revoke an arbitrarily large number of certs,
it's in their best interests to keep their heads down and wait for this to
blow over.

So perhaps instead of trying to find out which of the hundreds of CAs in the
program aren't compliant, we can check which ones are.  Would any CA that
thinks it's compliant let us know, and indicate why they think they're
compliant?  For example "we take 64 bits of CSPRNG output, pad it with a
leading , and use that as the serial number", in other words what
Matthew Hardeman suggested, would seem to be OK.

Peter.
___
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]

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 matter what, the resulting serial number should be at least 
64 bits long". However, experts like Peter Bowen, Rob Stradling and Matt 
Palmer, paying attention to details of the new requirement, gave a 
different interpretation. According to their explanation, if you take 
64-bits from a CSPRNG, there is a small but existing probability that 
the resulting serialNumber will be something smaller.  So, "shorter" 
serial numbers were not considered a violation of the BRs as long as the 
64-bits came out of a CSPRNG.


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.


As discussed before, automation is one of the goals (other opinions had 
been raised, noting security concerns to this automation). Centralized 
systems like large web hosting providers or single large Subscribers 
like the ones already mentioned in current incident reports, can build 
automation easier. However, simple/ordinary Subscribers that don't have 
the technical skills to automate the certificate replacement, that 
struggled to even install certificates in their TLS servers in the first 
place, will create huge burden for no good reason.


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.


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.


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.



Thanks,
Dimitris.

On 9/3/2019 6:32 π.μ., Peter Bowen via dev-security-policy wrote:

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 non-compliance existed, and even then,
clarifications to resolve that ambiguity already existed, had they simply
been sought.


Please contemplate this question, which is intended as rhetorical, in the
most generous and non-judgmental light possible.  Have you contemplated the
possibility that only one CA attempted to do so because you've stated your
interpretation and because they're subject to your judgement and mercy,
rather than because the text as written reflects a single objective
mechanism which matches your own position?


Matthew,

I honestly doubt so.  It seems that one CA software vendor had a buggy
implementation but we know this is not universal.  For example, see
https://github.com/r509/r509/blob/05aaeb1b0314d68d2fcfd2a0502f31659f0de906/lib/r509/certificate_authority/signer.rb#L132
  and https://github.com/letsencrypt/boulder/blob/master/ca/ca.go#L511 are
open source CA software packages that clearly do not have the issue.
Further at least one CA has publicly stated their in-house written CA
software does not have the issue.

I know, as the author of cablint, that the main reason I didn't have any
confusion.  I didn't add more checks because of the false positive rate
issue; if I checked for 64 or more bits, it would be wrong 50% of the
time.  The rate is still unacceptable with even looser rules; in 1/256
cases the top 8 bits will all be zero, leading to a whole the serial being
a whole byte shorter.

I do personally think that the CAs using EJBCA should not be faulted here;
their vendor added an option to be 

Re: EJBCA defaulting to 63 bit serial numbers

[Peter Bowen via dev-security-policy]

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 non-compliance existed, and even then,
> > clarifications to resolve that ambiguity already existed, had they simply
> > been sought.
> >
>
> Please contemplate this question, which is intended as rhetorical, in the
> most generous and non-judgmental light possible.  Have you contemplated the
> possibility that only one CA attempted to do so because you've stated your
> interpretation and because they're subject to your judgement and mercy,
> rather than because the text as written reflects a single objective
> mechanism which matches your own position?
>

Matthew,

I honestly doubt so.  It seems that one CA software vendor had a buggy
implementation but we know this is not universal.  For example, see
https://github.com/r509/r509/blob/05aaeb1b0314d68d2fcfd2a0502f31659f0de906/lib/r509/certificate_authority/signer.rb#L132
 and https://github.com/letsencrypt/boulder/blob/master/ca/ca.go#L511 are
open source CA software packages that clearly do not have the issue.
Further at least one CA has publicly stated their in-house written CA
software does not have the issue.

I know, as the author of cablint, that the main reason I didn't have any
confusion.  I didn't add more checks because of the false positive rate
issue; if I checked for 64 or more bits, it would be wrong 50% of the
time.  The rate is still unacceptable with even looser rules; in 1/256
cases the top 8 bits will all be zero, leading to a whole the serial being
a whole byte shorter.

I do personally think that the CAs using EJBCA should not be faulted here;
their vendor added an option to be compliant with the BRs and it was very
non-obvious that it had a bug in the implementation.  Based on my
experience with software development, we should be encouraging CAs to use
well tested software rather than inventing their own, when possible.

Thanks,
Peter
___
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 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 that ambiguity already existed, had they simply
>> been sought.
>>
>
> Please contemplate this question, which is intended as rhetorical, in the
> most generous and non-judgmental light possible.  Have you contemplated the
> possibility that only one CA attempted to do so because you've stated your
> interpretation and because they're subject to your judgement and mercy,
> rather than because the text as written reflects a single objective
> mechanism which matches your own position?
>

I consider the matter more than settled, based on the clear historic
evidence, so I see no value in engaging further.

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

[Matthew Hardeman via dev-security-policy]

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

Please contemplate this question, which is intended as rhetorical, in the
most generous and non-judgmental light possible.  Have you contemplated the
possibility that only one CA attempted to do so because you've stated your
interpretation and because they're subject to your judgement and mercy,
rather than because the text as written reflects a single objective
mechanism which matches your own position?
___
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 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 extremely wasteful,
given the ease at which alternative and plainly obvious solutions to comply
with the existing language exist. 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.

I do appreciate the effort, even though I believe it misspent. I do
sincerely hope that this thoroughly beaten horse corpse may be left alone
for some time. Of all the things to improve in the BRs that can have real
and meaningful improvement to the ecosystem, this does not rate on my Top
100.

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

[Matthew Hardeman via dev-security-policy]

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 a particularly valuable thing to continue discussing.
> While there is certainly novelty in the approach, which is not at all
> unfamiliar in the legal profession [3], care should be taken to make sure
> that we are making forward progress, rather than beating dead horses.
>

In the spirit of demonstrating good faith, looking forward, and perhaps
even making a useful contribution), I have started a new thread [1] in
which I propose alternative language which might replace the specification
presently in BR 7.1.  I would appreciate your thoughts on it.

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/PDzNNsxhzLU/F0uxY6qmCAAJ

>
___
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 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 line of reasoning several times now as to what
the expectations are. Indeed, the very message you're replying to has
already addressed the scenario and the expectations, so I'm not sure
repeating it is furthering much new insight.

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 replaced by
> further invocation of the CSPRNG.  Clearly a technicality, but shouldn't
> the rules be engineered with the assumption that implementers (or their
> software vendors) might take a different interpretation?
>

We can only do so much to defend against the jackass genie [1]. Likewise,
there is no defensible interpretation that an algorithm that, say, takes
bits from a CSPRNG and either keeps or discards them based on some
non-CSPRNG algorithm, and then outputs them, still represents a CSPRNG,
just as we cannot say that we sample bits from RFC 3514 [2] and only keep
the good ones, and thus ensuring we never corrupt our machine with evil.
The substance of this argument is quite literally haggling over what
"output" and "contains" is, and that, frankly, is obnoxious.

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 a particularly valuable thing to continue discussing.
While there is certainly novelty in the approach, which is not at all
unfamiliar in the legal profession [3], care should be taken to make sure
that we are making forward progress, rather than beating dead horses.

I'm not going to tell you to stop talking about this, as I think it'd be
improper to police such a thread given my involvement in it. However, I
want to highlight that nothing productive has emerged from it, and the
creative interpretations being advocated. We are no further in
understanding any of the questions being proposed by those applying
creative interpretations, because the principles have not changed. Every
time a CA has tried to apply such problematic logic, it has worked out
poorly for them in this community. whether arguing it was "ambiguous" that
MITM was prohibited, even though there was a requirement to validate (and
ensure validation of) all domain names in a certificate or that it's not
"misissuance", even though no evidence can be provided that the
requirements were followed, nothing good has come of that.

Indeed, I think advocating this line of reasoning is doing more active
harm, to this community and to CAs, and I hope it's abundantly clear as to
why that is.

[1] https://tvtropes.org/pmwiki/pmwiki.php/Main/JackassGenie
[2] https://www.ietf.org/rfc/rfc3514.txt
[3] https://en.wikipedia.org/wiki/Monkey_selfie_copyright_dispute
___
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

[Matthew Hardeman via dev-security-policy]

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
> actually validate serial numbers, and the whole matter can be dismissed as
> compliant.

Let's set aside certificates for a moment and talk about serial numbers, 
elsewhere definitionally defined as positive integers.

Certificate serial number A (represented as plain unencoded integer):  123456
Certificate serial number B (represented as plain unencoded integer): 123457

Can we agree that those two numbers are factually provable as sequential as 
pertains integer mathematics?

If so, then regardless of when (or in what order) two different certificates 
arise in which those serial numbers feature, as long as they arise as 
certificates issued by the same issuing CA, two certificates with 
definitionally sequential numbers have at that point been issued.

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 concur with you fully that a CA (and anyone, really) should view the BRs with 
an adversarial approach to review.

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 replaced by further invocation 
of the CSPRNG.  Clearly a technicality, but shouldn't the rules be engineered 
with the assumption that implementers (or their software vendors) might take a 
different interpretation?
___
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 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 serial numbers off by one from each other, no matter
> how you wind up getting there, are in fact sequential serial numbers and
> that this would appear to be forbidden explicitly.
>
> It seems that in reality that your perspective calls upon the CA to act
> according to the underlying risk that the rule attempts to mitigate rather
> than abide the literal text.  That seems a really odd way to construe a
> rule.
>

I think this is fundamentally an unhelpful way to think about and frame the
problem, but I think it's largely a result of not having to be a CA placed
in this position.

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
actually validate serial numbers, and the whole matter can be dismissed as
compliant.

You're fixating on the "rules lawyering" part, but that's not a remotely
productive framing. A CA that is doing the right thing can demonstrate how
they were doing it. A CA that is doing the wrong thing can't. That
'problem' you see is easily and rapidly resolved by such an explanation.

This framing is exactly why the ZLint side of things warns, rather than
errors - because it can arise in legitimate cases. If there's concern that
it's arising in illegitimate cases, a report is made, the CA investigates,
and the information shared, and we all move on. It's not that hard or
unreasonable :)

A CA is expected to be adversarially reading the BRs, and from that, either
highlighting concerns to m.d.s.p. and the CA/Browser Forum ("you COULD
interpret it like this") or taking steps to mitigate even under the most
adversarial reading. If and when an incident occurs, a CA that performed
such steps is in a far better place to explain the incident and the steps
taken. A CA that doesn't, and says "We didn't know", is more likely
indicative of a CA not  adversarially reading or critically evaluating it.
___
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

[Matthew Hardeman via dev-security-policy]

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 constructs
of the rule as stated in the BRs, the first requirement of a certificate
serial number is literally "non-sequential Certificate serial numbers", and
then furthermore that these must consist consist of at least 64 bits of
output from a CSPRNG.

Both your and Ryan Sleevi's comments seem to suggest that the
non-sequential part doesn't really matter when it arises incidentally as
long as they're randomly generated and that two certificates with
certificate serial numbers off-by-one from each other would not be a
problem.

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 serial numbers off by one from each other, no matter
how you wind up getting there, are in fact sequential serial numbers and
that this would appear to be forbidden explicitly.

It seems that in reality that your perspective calls upon the CA to act
according to the underlying risk that the rule attempts to mitigate rather
than abide the literal text.  That seems a really odd way to construe a
rule.
___
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

[Mike Kushner via dev-security-policy]

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 trusted CAs and SubCAs.

This has been the default setting since 2001, predating Ballot 164 quite some. 
At the time this was more than sufficient, and we hadn't reviewed it.

> 2. Mislead CAs to believe this setting actually provided 64 bits of 
>   entropy.

I'm presuming that you're not assigning any intention to the above.

We have always been open with that EJBCA generates 64 bit serial numbers, 
compliant with RFC5280 (3280 back then) and X.690. We weren't, at start of the 
previous thread, aware of the requirements made by CABF Ballot 164 as we've 
only been active in following the proceedings for the last couple of years, but 
as vendors we've historically viewed the responsibility configuring EJBCA 
correctly to meet existing standards as up to the end customer. We've been 
aware of the BR requirement for some time now, but we were not aware of the 
detailed previous discussion related to 63 vs 64 bits that has been held.

> 3. Discouraged CAs from changing that default.

This is not true in the least. Serial number size has been configurable since 
at least 2008 (long before B164). There is a note in the configuration file 
about not changing it unless you understand what you're doing, but that 
pertains to not lowering it below 64 bits. Raising the SN size (and thus 
entropy) has in fact been done by several of our customers (in response to 
B164, or for whatever other reason).
 
> This raises 3 derived concerns:
> 
> 4. Any CA using the EJBCA platform needs to manually check if they 
>   have patched EJBCA to comply with the BR entropy requirement despite 
>   EJBCAs publisher (PrimeKey) telling them otherwise.
>Maybe this should be added to the next quarterly mail from Mozilla to
>   the CAs.

A patch isn't required as the value is configurable in a config file, and in 
response to the concerns raised here we've added functionality for changing the 
serial number size without requiring a change to the config files. 

Again, I don't agree with your statement that we've told anybody that EJBCA, by 
default configuration, complies with the BR, as much configuration is needed to 
issue BR compliant certificates. A correct technical description of serial 
numbers is documented in the configuration file. The documentation did not 
consider the above discussion regarding entropy, as 64 bit serial numbers were 
leagues past the entropy requirements prior to 2016.

The documentation absolutely does encourage the end user to feel free to use 
larger serial number sizes, EJBCA is used in a lot of non public CA use cases, 
and as such ability to configure according to BR requirement or not is a key 
feature.

It does bear mentioning that the purpose of requiring serial number entropy was 
to mitigate against pre-imaging attacks against SHA-1, something which today 
has no bearing whatsoever. While I'm not claiming that there will never ever be 
a collision found against SHA256, but I hope you understand that this is a 
compliance issue against a requirement that for now has no has any security 
impact.

> 5. Is it good for the CA community that EJBCA seems to be the only 
>   generally available software suite for large CAs to use?

While I agree that diversity is good for any ecosystem, I would remind you that 
a majority of CA's don't actually run our software, and many run their own 
proprietary solutions. The availability of EJBCA is likely due to the fact that 
the vast majority of our code is FOSS (and the rest if always available to 
customers), which is partly due to our wish to make PKI available to all, and 
partly because we encourage external inspection of our implementation. 


> 6. Should the CA and root program community be more active in ensuring 
>   compliance by critical CA infrastructure providers such as EJBCA and 
>   the companies providing global OCSP network hosting.

Absolutely, and I would say that many already are. We don't have any goal other 
than making EJBCA as compliant as possible, and have always aimed to lay a step 
ahead of existing standards. Since 2016 (as a part of maturing as a software 
vendor) we changed focus in how we handle requirements work by actively 
following various standards orgs (including CABF), instead of receiving 
requirements from our customers. 

Cheers,
Mike
___
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

[Matt Palmer via dev-security-policy]

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 a single CA. It was a problem quite literally publicly
> > discussed during the drafting and wording of the ballot. References were
> > provided to those discussions. Have you gone and reviewed them? It might be
> > helpful to do so, before making false statements that mislead.
> 
> "Effective September 30, 2016, CAs SHALL generate non-sequential
> Certificate serial numbers greater than zero (0) containing at least 64
> bits of output from a CSPRNG. "  [1]
> 
> Irrespective of the discussion underlying the modifications of the BRs to
> incorporate this rule, there are numerous respondent CAs of varying
> operational vintage, varying size, and varying organizational complexity.

Yes, there are, and they all have a huge burden of trust placed on them. 

> The history underlying a rule should not be necessary to implement and
> faithfully obey a rule.

I absolutely agree with this.  Thankfully, there is no requirement to
understand the history behind the changes under discussion in order to
correctly implement it.

> Rather than have us theorize as to why non-compliance with this rule seems
> to be so widespread, even by a number of organizations which have more
> typically adhered to industry best practices, would you be willing to posit
> a plausible scenario for why all of this non-compliance has gone on for so
> long and by so many across so many certificates?

Because, like so many other things that go on for a long time before they're
discovered, nobody took a look.

> Additionally, assuming a large CA with millions of issued certificates
> using an actual 64-bit random serial number...  Should the CA also do an
> exhaustive issued-serial-number search to ensure that the to-be-signed
> serial number  is not off-by-one in either direction from a previously
> issued certificate serial number?  However implausible, if it occurred,
> this would indeed result in having participated in the issuance of 2
> certificates with sequential serial numbers.

Having sequential serial numbers is not problematic.  Having *predictable*
serial numbers is problematic.

- Matt

___
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

[okaphone.elektronika--- via dev-security-policy]

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 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.
> > 
> > Indeed.  But following BR 7.1 to the letter apparently doesn't get you all
> > the way to compliance, by some opinions.
> 
> No, *misinterpreting* BR 7.1 doesn't get you all the way to compliance.
> 
> > After all, nothing in 7.1
> > requires anything as to the quality of the underlying CSPRNG utilized.
> 
> The "CS" is "CSPRNG" stands for "cryptographically secure", and "CSPRNG" is
> defined in the BRs.
> 
> > It
> > does not specify whether the 64-bits must be comprised of sequential bits
> > of data output by the CSPRNG,
> 
> Nor does it need to.
> 
> > nor does it specify that one is not permitted
> > to discard inconvenient values (assuming you seek replacement values from
> > the CSPRNG).
> 
> 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.  The reduction in randomness depends on the
> exact quality function employed.
> 
> - Matt

Could be me but when I read this spec as a programmer, I would probably decide 
that the serial number needs to be bigger than 64 bits. After all the specs 
require you to exclude the value zero. Because of that the entropy of the 
serial number can only be at least 64 bits if its size is actually larger than 
64 bits.

And if you need more than 64 bits anyway... having a bit more entropy than 
required is not going to hurt, so I'd probably go for 128 bits. ;-)

CU Hans
___
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

[Peter Gutmann via dev-security-policy]

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 Certificate serial numbers greater than
  zero (0) containing at least 64 bits of output from a CSPRNG

There's nothing there about whether you can, for example, discard values that
you don't like and generate another one (in fact it specifically requires that
you reject the value 0 and generate another one).  In particular, for your
objection, how is one totally random value different from another?
Specifically, if I discard a totally random value that has the high bit set
(because of ASN.1 encoding issues) and take the next value generated, how is
that (a) not compliant with 7.1 and (b) different from another totally random
value that happens to not have the high bit set in the first place?

What if I call every cert that would end up with the sign bit set a test cert
and only issue the ones where they're not set?  Again, fully compliant with
the wording of 7.1, but presumably not compliant with your particular
interpretation of the wording (OK, it might be, I'm sure you'll let me know if
it is or isn't). That's the problem with rules-lawyering, if you're going to
insist on your own very specific interpretation of a loosely-worded
requirement then it's open season for anyone else to find dozens of other
fully compatible but very different interpretations.

And, again, question zero: Given that the value of 64 bits was pulled out of
thin air, why does it even matter?  

Can we just agree that the bikeshed can be any colour people want as long as
you're not using lead-based paint and move on from this bottomless pit?

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

[Matthew Hardeman via dev-security-policy]

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
and entropy sources bearing that designation and they've changed over the
years.


>
> > It
> > does not specify whether the 64-bits must be comprised of sequential bits
> > of data output by the CSPRNG,
>
> Nor does it need to.
>

Really, why not?  The rule says that 64-bits of output from a CSPRNG must
be utilized.  It does not clearly delineate that one can't be choosy about
which 64 to take.


>
> > nor does it specify that one is not permitted
> > to discard inconvenient values (assuming you seek replacement values from
> > the CSPRNG).
>
> 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.  The reduction in randomness depends on
> the
> exact quality function employed.
>

I understand well the reasons that entropy is desired and I understand well
exactly the way, mathematically, that this behavior would reduce total
entropy.  My complaint is that nothing in the rule demands an actual set
minimum amount of true entropy even though that result is clearly what was
really desired.
___
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 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 least 64
> bits of output from a CSPRNG. "  [1]
>

Isn’t it amazing how “at least” is one of those requirements where you can
look at it, and ask “Should I do the absolute bare minimum, or should I
maybe build in safety?” I find it amazing how, when you rely on doing the
bare minimum, it can somehow backfire.

Irrespective of the discussion underlying the modifications of the BRs to
> incorporate this rule, there are numerous respondent CAs of varying
> operational vintage, varying size, and varying organizational complexity.
>
> The history underlying a rule should not be necessary to implement and
> faithfully obey a rule.  And yet...
>

It isn’t required. A basic understanding of ASN.1 is all that’s required,
combined with critical and defensive thinking.

You don’t have to be a CA to have that. As previously provided, there was
discussion on m.d.s.p. a year ago about that. You can find discussions on
zlint about it [1] [2].

These aren’t skills participating in the discussions here necessarily
require, but are absolutely required of CAs operating globally trusted
PKIs.

Rather than have us theorize as to why non-compliance with this rule seems
> to be so widespread, even by a number of organizations which have more
> typically adhered to industry best practices, would you be willing to posit
> a plausible scenario for why all of this non-compliance has gone on for so
> long and by so many across so many certificates?
>

As noted, it has been called out in the past. You can see issues with how,
purely from a linting perspective, the best we can say is something looks
wrong, and to have the CAs explain. I think the framing and implication of
that last question is profoundly unhelpful and misguided. The answer is
that there are a number of CAs continuing to have issues [3], and this is
merely a symptom of yet another issue. These issues would be far easier to
close out if CAs were consistent in following the expectations of incident
reporting, but we continue to see CAs struggle with performing any sort of
meaningful introspective analysis.

While I don’t want to throw Thomas and the PrimeKey folks under the bus
here, it’s clear that the incidents being reported are that CAs are
outsourcing their compliance requirements. They have an obligation to
review and evaluate the code they use - whether it’s EJBCA, ADCS, UniCERT,
or some other stack. Every responsible CA should be having their compliance
teams holistically engage in evaluating the software they use, looking for
other issues. The incident responses we are seeing demonstrate some of them
being proactive in this. It would be absolutely disastrous for a currently
trusted CA to demonstrate this issue in 6 months - not on the basis of the
single bit, but due to the complete dereliction of professional duty to
stay abreast of the industry and compliance that it would represent.

Additionally, assuming a large CA with millions of issued certificates
> using an actual 64-bit random serial number...  Should the CA also do an
> exhaustive issued-serial-number search to ensure that the to-be-signed
> serial number  is not off-by-one in either direction from a previously
> issued certificate serial number?  However implausible, if it occurred,
> this would indeed result in having participated in the issuance of 2
> certificates with sequential serial numbers.
>

These strawman arguments demonstrate a lack of understanding of the
fundamental issue. It’s rather defensible for a CA to issue a one-byte
serial number - or even sequential serial numbers - as you hypothesize,
while still being compliant with the requirements. If such a matter were to
be brought - e.g. to the CA’s problem reporting email - they could examine
and determine that, no, they did have 64 bits of entropy, and it was merely
the probability that what could happen, would.

But that’s not what we’re talking about, and while it is posed as an
argumentum ad absurdum, it belies the substance of what is more meaningful:
how a CA monitors the discussions, ensures compliance, and investigates
issues. A CA that makes a meaningful investigation into the context and
history of an issue, or who takes steps to do more than the bare minimum,
and takes actions to be beyond reproach, is far, far better for the
ecosystem.

Incident reports are the opportunity for the CA to demonstrate how it is
improving, and for the industry to learn and identify risks and challenges
to collectively improve. CAs that promote and encourage that are far more
helpful to the ecosystem.

Frankly, to some extent, it doesn’t matter whether or not participants here
want to debate how well they understood it. It matters whether CAs did -
and 

Re: EJBCA defaulting to 63 bit serial numbers

[Matt Palmer via dev-security-policy]

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 sense or not. When it no longer makes sense, the wording
> > can be improved for the future.
> 
> Indeed.  But following BR 7.1 to the letter apparently doesn't get you all
> the way to compliance, by some opinions.

No, *misinterpreting* BR 7.1 doesn't get you all the way to compliance.

> After all, nothing in 7.1
> requires anything as to the quality of the underlying CSPRNG utilized.

The "CS" is "CSPRNG" stands for "cryptographically secure", and "CSPRNG" is
defined in the BRs.

> It
> does not specify whether the 64-bits must be comprised of sequential bits
> of data output by the CSPRNG,

Nor does it need to.

> nor does it specify that one is not permitted
> to discard inconvenient values (assuming you seek replacement values from
> the CSPRNG).

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.  The reduction in randomness depends on the
exact quality function employed.

- Matt

___
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

[Matthew Hardeman via dev-security-policy]

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

Indeed.  But following BR 7.1 to the letter apparently doesn't get you all
the way to compliance, by some opinions.  After all, nothing in 7.1
requires anything as to the quality of the underlying CSPRNG utilized.  It
does not specify whether the 64-bits must be comprised of sequential bits
of data output by the CSPRNG, nor does it specify that one is not permitted
to discard inconvenient values (assuming you seek replacement values from
the CSPRNG).

It is therefore my belief that either the BR 7.1 guideline wrong/inadequate
or the opinions which would hold that following BR 7.1 to the written
letter are not quite adequate are wrong.
___
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

[bif via dev-security-policy]

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 it 
makes sense or not. When it no longer makes sense, the wording can be improved 
for the future.

PS replacing handful of certs within 5 days is fairly easy; replacing thousands 
(or millions, as we find out) is much less likely. Should BRs account for that?

On Friday, March 8, 2019 at 2:47:27 AM UTC+1, Peter Gutmann 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, or e^i*pi bits?
> 
> Peter.

___
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

[Matthew Hardeman via dev-security-policy]

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 wording of the ballot. References were
> provided to those discussions. Have you gone and reviewed them? It might be
> helpful to do so, before making false statements that mislead.
>

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 least 64
bits of output from a CSPRNG. "  [1]

Irrespective of the discussion underlying the modifications of the BRs to
incorporate this rule, there are numerous respondent CAs of varying
operational vintage, varying size, and varying organizational complexity.

The history underlying a rule should not be necessary to implement and
faithfully obey a rule.  And yet...

Rather than have us theorize as to why non-compliance with this rule seems
to be so widespread, even by a number of organizations which have more
typically adhered to industry best practices, would you be willing to posit
a plausible scenario for why all of this non-compliance has gone on for so
long and by so many across so many certificates?

Additionally, assuming a large CA with millions of issued certificates
using an actual 64-bit random serial number...  Should the CA also do an
exhaustive issued-serial-number search to ensure that the to-be-signed
serial number  is not off-by-one in either direction from a previously
issued certificate serial number?  However implausible, if it occurred,
this would indeed result in having participated in the issuance of 2
certificates with sequential serial numbers.

I agree with Peter Gutmann's statement.  Whatever the cause for the final
language in BR 7.1, the language as presently presented is awful and needs
to be fixed in such a manner as will eliminate ambiguity within the rules.
I cannot imagine that would hurt compliance, but I rather suspect it may
improve it.

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf
___
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 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 discussion have shown the interpretation is hardly
specific to a single CA. It was a problem quite literally publicly
discussed during the drafting and wording of the ballot. References were
provided to those discussions. Have you gone and reviewed them? It might be
helpful to do so, before making false statements that mislead.
___
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

[Matthew Hardeman via dev-security-policy]

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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EJBCA defaulting to 63 bit serial numbers

[Peter Gutmann via dev-security-policy]

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
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EJBCA defaulting to 63 bit serial numbers

[Peter Gutmann via dev-security-policy]

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 it, this arrived:

  As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate
  Serial Number issue. We have identified a significant quantity of
  certificates (> 1.8million) not meeting the 64bit serial number requirement.

I rest my case.

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.

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

[Matthew Hardeman via dev-security-policy]

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 non-compliant as well.


As if on queue, comes now GoDaddy with its confession.
___
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

[Peter Gutmann via dev-security-policy]

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 example my code has always
used 8-byte serial numbers (based on the German Tank Problem, nothing to do
with the BR), it requests 9 bytes of entropy and, if the first byte of the 8
that gets used is zero uses the surplus byte, and if that's still zero sets it
to 1 (again nothing to do with the BR, purely as an ASN.1 encoding thing so
you always get a fixed-length value).   So there's a bias of 1/64K values.  Is
that small enough?  What if I make it 32 bits, so it's 1/4G values?  What
about 48 bits?  What if I use a variant of what you're suggesting, a >64-bit
structured value that contains 64 bits of entropy (so perhaps something using
parity bits or similar), is that valid?

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.

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

[Matthew Hardeman via dev-security-policy]

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, or e^i*pi bits?
>

I was actually joking on Twitter...

Let's say there's a CA that specializes in -- among other things -- special
requests...

What if they typically utilize 71-bits of entropy, encoded with a fixed
high-order bit value of 0, to ensure no extra encoding, and the 7/8 of one
byte + the following 8 bytes are fully populated with 71 bits of entropy as
requested from an appropriate entropy source...

What if a special customer (who may be a degenerate gambler, but isn't
necessarily -- it's merely theorized) insists that they're only going to
accept a "lucky" certificate whose overall serial number decimal value is
any one of the set of any and all prime numbers which may be expressed in
the range of 71-bit unsigned integers?

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?
___
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

[Peter Gutmann via dev-security-policy]

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 possibly
   less well-lit regions), does it really matter whether it's 63 bits, 64
   bits, 65 3/8th bits, or e^i*pi bits?

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

EJBCA defaulting to 63 bit serial numbers

[Jakob Bohm via dev-security-policy]

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 bits of 
  entropy.

3. Discouraged CAs from changing that default.

This raises 3 derived concerns:

4. Any CA using the EJBCA platform needs to manually check if they 
  have patched EJBCA to comply with the BR entropy requirement despite 
  EJBCAs publisher (PrimeKey) telling them otherwise.
   Maybe this should be added to the next quarterly mail from Mozilla to
  the CAs.

5. Is it good for the CA community that EJBCA seems to be the only 
  generally available software suite for large CAs to use?

6. Should the CA and root program community be more active in ensuring 
  compliance by critical CA infrastructure providers such as EJBCA and 
  the companies providing global OCSP network hosting.


The above issue first came up in Message ID 

posted on Mon, 25 Feb 2019 08:39:07 UTC by Scott Rea, and subsequently 
lead to a number of replies, including at least one reply from Mike 
Kushner from EJBCA and a discovery that Google Trust Services was 
also hit with this issue to the tune of 100K non-compliant certificates.

On 07/03/2019 18:59, Jakob Bohm wrote:
> This thread is intended to be a catalog of general issues that come/came
> up at various points in the DarkMatter discussions, but which are not 
> about DarkMatter specifically.
> 
> Each response in this thread should have a subject line of the single 
> issue it discusses and should not mention DarkMatter except to mention 
> the Timestamp, message-id and Author of the message in which it came up.
> 
> Further discussion of each issue should be in response to that issue.
> 
> Each new such issue should be a response directly to this introductory 
> post, and I will make a few such subject posts myself.
> 
> Once again, no further mentions of Darkmatter in this thread are
> allowed, keep those in the actual Darkmatter threads.
> 


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy