Certificates with less than 64 bits of entropy

Baseline Requirements section 7.1 says:

> Effective September 30, 2016, CAs SHALL generate non=E2=80=90sequential =
Certificate serial numbers greater than zero (0) containing at least 64 =
bits of output from a CSPRNG.

There are 1027 unexpired unrevoked certificates known to CT with a =
notBefore date greater than or equal to 2016-09-30 that are trusted by =
NSS for server authentication and have a serial number that has less =
than 64 bits of entropy.

The full list can be found here: https://misissued.com/batch/6/

Some of these were brought up in a previous thread[0], but I though a =
comprehensive picture of this issue would be helpful.

I=E2=80=99ve included a breakdown at the end of this email, and here are =
a few things that stood out to me while researching this:

- The "Cihaz Sertifikas=C4=B1 Hizmet Sa=C4=9Flay=C4=B1c=C4=B1 - S=C3=BCr=C3=
=BCm 4=E2=80=9D intermediate appears to use randomly generated 48-bit =
numbers.
- Three intermediates, "TeleSec ServerPass Class 2 CA=E2=80=9D, "Go =
Daddy Secure Certificate Authority - G2=E2=80=9D, and "Starfield Secure =
Certificate Authority - G2=E2=80=9D, (which are not in this list) appear =
to issue certificates with serial numbers that are based on exactly 64 =
bits of entropy. This means that a small percentage of the certificates =
that they issue have serial numbers that are smaller than 8 bytes, =
requiring additional filtering to avoid false positives. It would be =
helpful if the policy was adjusted to require serial numbers always be =
at least 8 bytes before DER encoding to avoid these false positives.

Jonathan

[0] =
https://groups.google.com/d/topic/mozilla.dev.security.policy/vl5eq0PoJxY/=
discussion

=E2=80=94

QuoVadis (560)
    Siemens Issuing CA Internet Server 2016 (560)

D-TRUST (224)
    D-TRUST SSL Class 3 CA 1 2009 (178)
    D-TRUST SSL Class 3 CA 1 EV 2009 (45)
    D-TRUST Root Class 3 CA 2 EV 2009 (1)

DigiCert (85)
    Siemens Issuing CA Class Internet Server 2013 (82)
    InfoCert Web Certification Authority (3)

Izenpe S.A. (62)
    EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)

Government of The Netherlands, PKIoverheid (Logius) (55)
    Digidentity Services CA - G2 (55)

Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
    Cihaz Sertifikas=C4=B1 Hizmet Sa=C4=9Flay=C4=B1c=C4=B1 - S=C3=BCr=C3=BC=
m 4 (38)=
0
Jonathan
8/10/2017 3:20:16 PM
mozilla.dev.security.policy 1208 articles. 1 followers. Post Follow

3 Replies
43 Views

Similar Articles

[PageSpeed] 4

On Thursday, 10 August 2017 16:20:56 UTC+1, Jonathan Rudenberg  wrote:
 - Three intermediates, "TeleSec ServerPass Class 2 CA=E2=80=9D, "Go Daddy =
Secure Certificate Authority - G2=E2=80=9D, and "Starfield Secure Certifica=
te Authority - G2=E2=80=9D, (which are not in this list) appear to issue ce=
rtificates with serial numbers that are based on exactly 64 bits of entropy=
.. This means that a small percentage of the certificates that they issue ha=
ve serial numbers that are smaller than 8 bytes, requiring additional filte=
ring to avoid false positives. It would be helpful if the policy was adjust=
ed to require serial numbers always be at least 8 bytes before DER encoding=
 to avoid these false positives.


Mmmm. I previously spoke out in favour of the practice of calling out non-c=
ompliant certificates because we need CAs to be doing their best, but I thi=
nk there's also an allied element that when we're looking for problems we t=
oo need to put the effort in.

The truth is that there is no positive test for randomness, any work in thi=
s area is going to end up needing a judgement call, so I think inconvenienc=
ing the CAs even a small amount with such a policy change just to make auto=
mated testing easier isn't the right trade off. If there happens to be some=
 future work in this policy area and the opportunity is taken to incorporat=
e Jonathan's wording I have no problem with that, but I definitely don't th=
ink Mozilla should insist on it for its own sake.
0
Nick
8/10/2017 4:27:42 PM
On Thursday, August 10, 2017 at 11:27:53 AM UTC-5, Nick Lamb wrote:

> The truth is that there is no positive test for randomness, any work in t=
his area is going to end up needing a judgement call, so I think inconvenie=
ncing the CAs even a small amount with such a policy change just to make au=
tomated testing easier isn't the right trade off. If there happens to be so=
me future work in this policy area and the opportunity is taken to incorpor=
ate Jonathan's wording I have no problem with that, but I definitely don't =
think Mozilla should insist on it for its own sake.

Further to the point that Nick made, merely ensuring that the serial number=
 field is represented as at least eight bytes prior to DER encoding still d=
oes not tell you whether or not the CA truly incorporated 64 bits of random=
ness in the serial number versus, for example, packing together 32 bits of =
randomness and 32 bits of sequence number.
0
Matthew
8/10/2017 6:26:20 PM
Update on Siemens - Certificates with less than 64 bits of entropy
The following is regarding the topic https://groups.google.com/forum/#!topi=
c/mozilla.dev.security.policy/vl5eq0PoJxY regarding the =93Siemens Issuing =
CA Internet Server 2016=94 that is root signed by QuoVadis and independentl=
y audited and disclosed.

At the time the issue was reported, Siemens agreed to immediately take the =
CA offline, and it remains offline pending resolution.  This was reported t=
o the listserv by me on 7/20.

Siemens confirmed a bug in their internally-developed CA software which mea=
nt it was issuing TLS/SSL with 32bit serial numbers, although the serial nu=
mbers were non sequential.  Siemens informed their external auditors of the=
 situation.

It was found that 1201 currently valid certificates chained to the QuoVadis=
 root were affected.  An additional 137 currently valid certificates were i=
ssued under the previous "Siemens Issuing CA Internet 2013" chained to a Di=
gicert root, noted in an email from Ben Wilson of Digicert yesterday.  In t=
he case of the QuoVadis-chained certificates, the certificates are virtuall=
y all of one year validity with expirations balanced across the calendar mo=
nths (there are a handful of two and three year certificates, similar to th=
e Digicert-chained population).  The remaining Digicert-chained certificate=
s all expire by end of November 2017.  All certificates were issued to Siem=
ens entities and Siemens-controlled domains.

Next steps
Siemens has moved to accelerate the previously planned replacement of their=
 existing inhouse CA platform with a well-known open source CA with which Q=
uoVadis is well familiar.  QuoVadis and Siemens' auditors are coordinating =
with Siemens to confirm that the new CA configuration meets Baseline Requir=
ements.  It is worth noting that some BR controls, particularly related to =
vetting, are imposed by the Siemens certificate lifecycle system which will=
 continue to be used with the new CA.  Siemens will not recommence their in=
house SSL issuance until the new CA is active and confirmed compliant.  The=
 new CA is expected to come online in the second week of September.  Siemen=
s commits to logging new SSL from that CA in Certificate Transparency.

Replacement
Although the Siemens PKI is centralised, the certificates are issued to a w=
ide variety of Siemens group companies around the world and are used on bot=
h infrastructure and high traffic websites.  A rushed revocation and replac=
ement of these certificates would have a negative business impact on Siemen=
s that they believe outweighs the risk of the lower serials entropy (partic=
ularly given that they are nonsequential).

We propose that Siemens begin the early replacement of the affected certifi=
cates as soon as the new CA infrastructure is approved, with the goal of co=
mpleting the task by January 31, 2018.  This will include all the affected =
certificates (ie those chained from both the QuoVadis and Digicert roots). =
 While Siemens acknowledges that the affected certificates should not have =
occurred, we point out that they will all be replaced far in advance of the=
 September 2019 date when industry-wide the last certificates issued before=
 the BR change (to larger serial numbers) are scheduled to expire.

We request that Siemens be allowed this expanded scope to conduct an orderl=
y replacement of the affected certificates.

Many thanks, Stephen Davidson
QuoVadis

0
Stephen
8/15/2017 8:53:44 AM
Reply: