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" <[email protected]> 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:[email protected]] On > Behalf Of Gervase Markham > Sent: Thursday, September 4, 2014 4:22 AM > To: [email protected] > 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 > [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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
