Oops. Does it look like I replied to wrong email? Red-faced. Tim.
> On Sep 4, 2014, at 1:33 PM, "Tim Moses" <tim.mo...@entrust.com> wrote: > > Hi Mark. I think that makes sense. > > Historically, the Development manager for the affected product has been > invited to SARB. He or she has taken on the task of communicating with the > relevant product managers. > > "Relevant" product managers should include those with responsibility for > services. > > The service product managers should ensure that service components are > remediated in an expeditious manner and that (where not already publicly > disclosed) the security bulletin is not released until this has been done. > > I don't think that contradicts anything in the proposed amendment. We just > have to make sure that the Development manager brings ALL the relevant > product managers into the discussion. > > All the best. Tim. > >> On Sep 4, 2014, at 12:41 PM, "Ben Wilson" <ben.wil...@digicert.com> wrote: >> >> Options for trying this out might fit under an exception, if one were >> created, for "test, experimental, temporary, pilot, provisional, etc." >> certificate types. >> >> -----Original Message----- >> From: dev-security-policy >> [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On >> Behalf Of Gervase Markham >> Sent: Thursday, September 4, 2014 4:22 AM >> To: mozilla-dev-security-pol...@lists.mozilla.org >> Subject: Short-lived certs >> >> Short-lived certs are one plank of our future revocation strategy.[0] >> Currently, it is not permitted by the CAB Forum Baseline Requirements to >> revocation pointers out of a cert, ever. However, this is part of the big >> value of short-lived certs, as it's what unlocks their speed-increasing >> potential across all browsers. (The logic is that a 3-day expiry misissued >> cert with no revocation pointers has a similar risk profile to a 1-year >> expiry misissued cert where the attacker has captured a valid 3-day expiry >> OCSP response they can staple to it). >> >> I've just been reviewing discussions from July 2012 on the CAB Forum mailing >> lists about short-lived certs. There was some significant opposition to >> removing revocation information from short-lived certs at the time (although >> things may be different now, I don't know). I personally think much of that >> opposition was mistaken, but the discussion nevertheless did not result in >> consensus. >> >> How should we approach the issue of short-lived certs? It seems to me we can >> do the following: >> >> 0) Try and get a motion passed to change the BRs to allow short-lived certs >> to not have any revocation information. This would probably require us to >> review the original discussion and make a wiki page outlining our proposal >> and rebutting objections. We may still run into heavy weather. We could also >> discuss it at the face-to-face. >> >> 1) Write an exception in Mozilla's policy that short-lived certs don't have >> to have revocation info. This would likely have no effect, because CAs would >> want to continue issuing to the BRs. >> >> 2) Stop checking revocation information for short-lived certs unilaterally. >> This would result in reduced take-up of the idea, because there would be no >> advantage in other browsers, and one would still need to implement all the >> mechanisms, both at the CA and at the site, for frequent cert renewals and >> deployments. >> >> 3) Configure Firefox to not bother checking revocation information for any >> cert newer than N days. This way, you can "emulate" short-lived certs by >> just reissuing an X-year cert every N days or less. It also 'fixes' the >> clock-skew problem in one direction, because the certs will still work for >> users whose clocks are some way in the future (although their browsers would >> check revocation). >> >> 4) Something else? >> >> Gerv >> >> [0] https://wiki.mozilla.org/CA:RevocationPlan >> _______________________________________________ >> 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
