G’day Corey,
To follow up on this thread, we have confirmed with the developers of the
platform that the approach used to include 64-bit output from a CSPRNG in the
serialNumber is to generate the required output and then test it to see if it
can be a valid serialNumber. If it is not a valid serialNumber, it is
discarded, and new value is generated. This process is repeated until the first
valid serialNumber is produced.
This process ensures that 64 bits output from a CSPRNG is used to generate each
serialNumber that gets used, and this is complaint with the BRS Section 7.1.
I will also point out that if the returned value is a valid as a serialNumber,
it is further checked to see if that value has not been used before, since
there is obviously a minimal chance of collision in any truly random process.
In this case the serialNumber value will also be discarded and the process
repeated.
I think it reasonable to expect that EVERY implementation of a compliant CA
software is doing this post-processing to ensure the intended serialNumber has
not already been used, and this is not something unique to EJBCA. As such,
every CA out there will have some process that requires post-processing of
whatever value is returned with a possibility to have to repeat the process if
there is a collision.
Regards,
--
Scott Rea
Scott Rea | Senior Vice President - Trust Services
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott....@darkmatter.ae
The information transmitted, including attachments, is intended only for the
person(s) or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
in error, please contact the sender and destroy any copies of this information.
On 2/25/19, 6:11 AM, "Scott Rea" <scott....@darkmatter.ae> wrote:
G’day Corey,
I am not sure if the phrase “…outputting 64 random bits from the CSPRNG and
then coercing the most significant bit to 0” is actually an accurate
representation of what is happening under the covers – we have asked for
clarification from the developers so we can all have an informed discussion (I
know that DM is not the only CA using this platform). My anticipation is that
what happens is that CSPRNG process is repeated until a positive INTEGER is
returned. In which case a 64-bit output from a CSPRNG is contained in the
serialNumber as is required. Please note, the requirement is not a 64-bit
number, but that a 64-bit output from a CSPRNG process is contained in the
serialNumber, and we believe this is exactly what is happening.
Regards,
--
Scott Rea
On 2/25/19, 5:48 AM, "dev-security-policy on behalf of Corey Bonnell via
dev-security-policy" <dev-security-policy-boun...@lists.mozilla.org on behalf
of dev-security-policy@lists.mozilla.org> wrote:
Hi Scott,
Thank you for the prompt response and the transparency in regard to the
software stack used by your CA operations. The detailed response that you
provided will hopefully make it easier to highlight the disconnect we have.
You are correct that ASN.1 INTEGERs are 2's-complement signed integers.
Every DarkMatter-issued certificate that I've encountered (both those chained
to Digicert roots as well as your roots as well as the DarkMatter root
certificates themselves) has an INTEGER data size of exactly 8 octets (64
bits). By outputting 64 random bits from the CSPRNG and then coercing the most
significant bit to 0 (to make the INTEGER value positive, as you mentioned)
means that the CA software is discarding one bit from the CSPRNG (since the
most significant bit is being coerced to 0) and embedding only 63 bits of
CSPRNG output in the certificate serial number. Section 7.1 of the Baseline
Requirements requires at least 64 bits output from a CSPRNG, so I do not
believe the serial number generation scheme that you have described is
compliant.
Thanks,
Corey
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
