While time isn't entropic and in its minutes and seconds there are more variable bits than the 20 required by policies, the main influences in a subordination process are air gap, limitations on the number of rounds, and lack of control of the plaintext.
Subordination occurs with paper contracts and security officers and internal auditors and sneakernet. That produces both controls and low predictability. In my experience, an outlying case would be where an external candidate for subordination receives more than two sets of certificates in response to requests. In every case where practical and possible and a volume of key use events are occurring, serial entropy has a value. But in justifying that you make two points I'd like to explore further: - What low-round attacks could exploit creation of a two byte sequential serial in a case where the submitter does not control the entire plaintext? Or the serial number itself? Or the submission process? The Playstation attack was not just 18 hour birthdaying, it was discovery of a pliable and predictable CA issuance process. It was watching the pace of sequential serial number progression for weeks, nudging it even, to get near the target number near the target date. It was flooding the system with auto-approved requests for sequentially assigned serial numbers and predictable validity date/time when that t-minus six seconds moment arrived. - Why does HSM vs software keys matter? That's hypothetically, as all subordinate keys are in HSMs. The subordinate exists already, signed by either a root or senior subordinate. Its own serial (arcane use of AKI aside) isn't relevant to that which it signs. Same question goes for inner sanctum vs fielded certs. Ultimately, yes, do the best things everywhere, no dispute whatsoever. But among us, can we share an opinion that there comes a point on a cold winter night when another blanket offers no value? Rationalizing two byte serials in offline processes rather than encoding their prohibition into audit isn't an attempt to keep us awake worrying, it's more to prevent smothering us. Kind regards, Steve On Sun, Feb 14, 2016 at 1:48 PM Jakob Bohm <[email protected]> wrote: > 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. > > > > -----Original Message----- > > From: dev-security-policy > > [mailto:dev-security-policy-bounces+steve.medin > [email protected] > > zilla.org] On Behalf Of Jakob Bohm > > Sent: Thursday, February 11, 2016 1:23 PM > > To: [email protected] > > Subject: Re: New requirement: certlint testing > > > > 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). > > > > > > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
