Re: PROCERT issuing certificates with non-random serial numbers

2017-08-17 Thread Matthew Hardeman via dev-security-policy
Just from the posted serial numbers, it looks almost like the high order bits 
may represent 32 bits of random, which is still far short of the requirement.

Perhaps they intended a 48 bit sequential counter after a 32 bit random, or 
intended a 64 bit random followed by a 16 bit sequential counter, but failed at 
filling the second half of the 64 bit random space.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: PROCERT issuing certificates with non-random serial numbers

2017-08-16 Thread Andrew Ayer via dev-security-policy
On Wed, 16 Aug 2017 19:56:45 -0700
Andrew Ayer via dev-security-policy
 wrote:

> Every certificate known to CT issued by PROCERT with a notBefore
> date after September 30, 2016 has what appears to be a non-random
> serial number: https://crt.sh/?Identity=%25&iCAID=750

These are now being tracked on misissued.com: https://misissued.com/batch/12/

> In addition, their OCSP responder is returning a status of "Good" for
> adjacent serial numbers, suggesting sequential assignment of serial
> numbers.

Actually, their OCSP responder is returning good for unissued
certificates, which is itself a BR violation.  I've attached a sample
OCSP response to the
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1391058

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


PROCERT issuing certificates with non-random serial numbers

2017-08-16 Thread Andrew Ayer via dev-security-policy
Every certificate known to CT issued by PROCERT with a notBefore
date after September 30, 2016 has what appears to be a non-random
serial number: https://crt.sh/?Identity=%25&iCAID=750

1e:4d:94:48:00:00:00:00:0c:79
2f:84:26:06:00:00:00:00:0b:1b
3d:94:73:d1:00:00:00:00:0a:ab
4b:53:8c:18:00:00:00:00:09:db
4c:94:f1:d5:00:00:00:00:0a:bd
4c:f3:00:86:00:00:00:00:0a:c0
4d:a7:2c:6a:00:00:00:00:0a:c3
4e:11:32:b3:00:00:00:00:0a:c7
6f:d3:c3:24:00:00:00:00:0c:56
7b:33:8f:17:00:00:00:00:0c:96
7b:98:a8:b1:00:00:00:00:0c:97
11:bb:b9:9f:00:00:00:00:0b:af
14:e9:6d:a4:00:00:00:00:0a:fa
16:8e:a3:9d:00:00:00:00:0b:f5
17:93:5a:4f:00:00:00:00:09:a6
17:96:d7:b8:00:00:00:00:09:a7
18:94:8a:f4:00:00:00:00:09:5a
18:98:dc:bb:00:00:00:00:09:5b
35:ce:d9:af:00:00:00:00:0c:02
43:ed:d4:a7:00:00:00:00:0a:b1
51:33:c5:60:00:00:00:00:0a:36
62:fa:e6:81:00:00:00:00:08:ad
69:4d:2f:c1:00:00:00:00:08:b4
76:81:87:9b:00:00:00:00:0b:65

In addition, their OCSP responder is returning a status of "Good" for
adjacent serial numbers, suggesting sequential assignment of serial
numbers.

This violates section of 7.1 of the BRs, which state:

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

I have not reported this to PROCERT since their problem reporting
mechanism is a link to a non-English web page.

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