As long as TLS handshake performance concerns keep RFC 6961 from de facto ( https://bugzilla.mozilla.org/show_bug.cgi?id=611836) we'll need to operate root tier responders with HSM-driven origins, cached responses, and multiple CDNs.
Further, you're talking about a certificate that is issued by the root owner on their own behalf. To me, that is within logical inner sanctum, regardless of how it needs to physically extend itself beyond the perimeter. By that point, the serial number that the root put into the responder certificate doesn't matter - the root owner controlled the responder key and PKCS#10 brought to their root. In my practice, all root private key exposures face the same procedural pre-audit, test root issuance, results review, production issuance (and associated m of n methods), post-audit, and delivery whether a subordinate CA or a responder certificate. Kind regards, Steve Medin On Tue, Feb 16, 2016 at 10:03 AM Jakob Bohm <jb-mozi...@wisemo.com> wrote: > A few clarifications: > > On 15/02/2016 16:06, Peter Bowen wrote: > > I actually agree with Steve, but for a slightly different reason. The > known attacks all required having a submitted subject key with certain > properties. The CA/Browser Forum Baseline Requirements state that all CA > keys (including subordinate CA keys) must be generated on HSMs during a > ceremony witnessed by an independent auditor. Now it is possible that the > HSM will generate an appropriate key, but it would be highly unlikely. > > > > My arguments were not restricted to sub-CA certificates, but included > other root-issued certificates such as OCSP responders (for revocation > checks on root-issued certificates). > > > Further, Mozilla is requiring disclosure of all CA-certificates. I > don’t know if the discussion ever closed on the timeline, but it should be > quite obvious if someone is attempting to put large numbers of random bytes > in a the subject Name, which is the only other attacker controlled field. > > > > Again, argument not restricted to sub-CA certificates. > > > That being said, I’m not going to change cablint to remove this warning > message unless the BRs are changed. Certlint and cablint intentionally > follow published standards when such exist. I’ve made a number of changes > since release to be more compliant and that is the path that will continue. > > > > I agree that setting a grandfathering data for making this either an > error or a weak warning would be a simpler solution to co-existing with > the historical practice. > > That grandfathering date could be based on when the published standards > introduced the requirement for different kinds of cert (there was a > discussion if the rule in one of the RFCs applied to the root cert > itself, so that one might have a different cut-off date corresponding > to when the current interpretation took effect). > > > Thanks, > > Peter > > > >> On Feb 15, 2016, at 6:27 AM, Medin, Steven <steve.me...@verizon.com> > wrote: > >> > >> If I grant the 1% probability (which I can't), that leads to maybe > 10-15 attempts to get bingo. In my past practice, our guard would be > raised for the third set of requests from an external party. The manual > processes, even with a bribe/plant inside the CA, do work. One person > cannot act alone at any part of the process. No matter how persuasive, > they can't force 10:19:36 AM Friday. Granted, signing subordinate CAs does > get procedural, but it doesn't get time-precise. > >> > >> About the 1%, we're talking about an air gapped process. Each > additional request faces logistics before it clears to get near the root > that are influenced by multiple people. During the attack that led to > requiring serial entropy, hundreds of requests were submitted per second to > cause the proper serial number to be received with the proper validity > dates. The process auto-approved requests within a predictable 6 seconds. > To work, it needed to converge the sequential serial number and the > datetime values. > >> > >> I asked about the HSM relevance to the serial number of a CA or OCSP > responder certificate. I agree with the reasons for hardware and that HSMs > have better pRNG than sound cards. > >> > >> Yeah, I saw the 00 serial discussion as well. In my past, we issued > sequential small serial numbers for roots and subordinates, but lately > larger and random. I'm not coming at this defensively, rather to think > about the true value added and whether a small serial number in a root or > subordinate will mandate rebuild of a PKI in the future. If we do encode > it as a rule, then any CA should know better from that point forward, and > problem solved, but I'm talking about the idea that the only thing better > than more is more more more. > >> > >> Kind regards, > >> Steve > >> > >> -----Original Message----- > >> From: dev-security-policy [mailto: > dev-security-policy-bounces+steve.medin= > verizonbusiness....@lists.mozilla.org] On Behalf Of Jakob Bohm > >> Sent: Sunday, February 14, 2016 5:08 PM > >> To: mozilla-dev-security-pol...@lists.mozilla.org > >> Subject: [E] Re: New requirement: certlint testing > >> > >> On 14/02/2016 21:58, Steve wrote: > >>> 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. > >>> > >> > >> I read it as 20 *bytes* (160 bits) corresponding to the minimum > supported serial number size in some of the standards (and the maximum > ditto in too many versions of NSS). > >> > >>> 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. > >>> > >> This would not help against the attacks I was trying to guard against > (more below). > >> > >>> 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. > >>> > >> > >> Let's assume (for purposes of argument) that within the 10+ years > lifetime of a root, a major adversary discovers an unpublished attack which > requires getting the CA to sign a message whose hash matches some pattern, > and that this can be achieved with a reasonable probability (say 1%) by > getting the CA to sign a certificate with certain combinations of the > requestable field values combined with prediction within a small (but not > zero) margin of the CA selected field. > >> > >> Such an adversary could quietly observe the pattern of issued > certificates (which are public and can be observed with no active attack or > active requests), then pay/place someone in the margins of the CA > organization to place a calculated request at a time where the signing > circumstances will be fairly predictable (e.g. it will probably be signed > within a given 2 hour period, beginning 10 days after the request). Repeat > as necessary until the 1% bingo is hit. > >> > >>> - 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. > >> > >> I was trying to emphasize that the private (and thus public) keys > submitted for signature were not generated from a lesser source, such as a > CA operated web server with software key generation, or from a too easily > compromised (i.e. large) part of the CA organization, or transported in a > way subject to interference. > >> > >> This of cause because those public keys contain the largest amount of > entropy in the certificates, and the best place to introduce malicious bits > of non-entropy. > >> > >> The key storage is not as important as the fact it was generated in a > provably secure and uncompromised way. A later compromise of the signed > key is much less a problem as far as attacks on the CA signature process is > concerned. Though it might be used in a much more difficult attack on the > CRL or OCSP signing process, by reporting (possibly > >> uncompromised) chosen certificate serial numbers for revocation. > >> > >>> > >>> 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. > >> > >> This was inspired by reports (in recent weeks, on this list, maybe even > in this thread, I don't recall right now) that some CAs had actually > assigned low (single digit even) serials to some of the initial > certificates of the types I mentioned. > >> > >> Thus the exception was meant to allow current practice in cases where > it is obviously completely safe, but to reign in this to such obviously > safe cases in a way that can be routinely checked in both Mozilla > monitoring and independent official audits. > >> > >> > >>> > >>> On Sun, Feb 14, 2016 at 1:48 PM Jakob Bohm <jb-mozi...@wisemo.com> > 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 > >>>> =verizonbusiness....@lists.mo > >>>>> zilla.org] On Behalf Of Jakob Bohm > >>>>> Sent: Thursday, February 11, 2016 1:23 PM > >>>>> To: mozilla-dev-security-pol...@lists.mozilla.org > >>>>> 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 > >>>> dev-security-policy@lists.mozilla.org > >>>> https://lists.mozilla.org/listinfo/dev-security-policy > >>>> > >> > >> > >> 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 > >> dev-security-policy@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-security-policy > >> _______________________________________________ > >> dev-security-policy mailing list > >> dev-security-policy@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-security-policy > > > > > 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
