On 12/02/2016 12:03, Medin, Steven wrote:
> There's no requestor control of validityNotBefore for an offline CA signing
> event, and certainly none with an online CA since the Playstation attack.
> There's limited control of toBeSigned: CAs will grab the asserted subject
> DN, public key, and toss the decorations in the PKCS#10 away. They'll amend
> the DN as they see fit based on vetting and any omissions and set validity
> dates based on the moment the offline root is exposed to perform the event.
> They're bringing multiple humans together at an externally unpredictable
> time (timezone even) and day.
>
> Even though subordination can be external or beyond core PKI realm, you
> can't get chosen plaintext or birthday with an offline CA. RapidSSL was
> another story entirely and even though they were an outlier, the 20-bit
> serial entropy that resulted was certainly warranted at the end entity tier.
> It remains an important security measure when signing anything requested
> from outside, including 3rd party sub-CA certificates, cross certificates
> for the roots of other CAs, certificates for more remote parts of the CA's
> organization (such as certificates for the Symantec software business issued
> by a Symantec owned CA) etc.
>
Note that the realistic variation in the validity dates (as seen from
someone already well enough posed to submit requests in the first
place) is a lot less than the 160 bit minimum of serial number entropy.
Just because the offline CA processes poses a significant slowdown of
any attacks, it does not entirely prevent attacks that require a low
number of "rounds", where each round submits 1 or more requests and
awaits the signed certs.
Hence my suggestion that as a prudent security measure, seemingly
random serial numbers should still be generated for any requests not
from the innermost circle of the CA operations "castle". Examples that
would be excluded would be self-signing the root certificate and
signing any locally hosted major subsystems generating their keys in
local high security hardware, such as some locally hosted subCAs and
some OCSP responders. However it would not be prudent for requests
generated or transmitted through less secure systems, such as
software-only OCSP responders or systems located off site (or just
outside the doubly secured inner sanctum of the building).
In Mozilla policy terms this would imply that Mozilla typically cannot
know if such CA-related certificates are securely on-site and thus
should not enforce the 160-bit randomness rules for certificate types
where this exception might apply.
However auditors *should* (perhaps in a future CAB/F BR) be required to
specifically check that any low-entropy-serial-number certificates
generated do in fact refer to such secure on-site systems. As these
will be low in number (perhaps less than 10), and each directly name
the system they refer to, this would be a simple case of traditional
by-the-numbers auditing:
"An automated log search (similar to the crt.sh tools but run against
more complete internal logs) listed the following certificates with
low entropy serial numbers: A.B, C.D, E.F and G.H, A.B is the root
cert, OK. C.D is the HSM in the OCSP responder on shelf 3 in rack 2
in the secure cage, OK. E.F. (revoked) was the HSM in the old subCA
on shelf 5 in rack 1 in the cage, which has been decommissioned and
securely destroyed as per audited document 234, OK. G.H is the HSM
of the current off-line EV subCA on shelf 1 in rack 1 in the cage,
that issues batches of end entity certificates in a daily ceremony
and updated revocation data in more frequent ceremonies, OK. All
accounted for and in line with the requirement, next item."
(Of cause the published audit would omit the specific locations of
those servers, that would be in an longer internal document available
only to insiders).