Steve, I think this level of public detail is very helpful when it comes to understanding the proposal.
On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 1) December 1, 2017 is the earliest credible date that any RFP > respondent can provide the Managed CA solution proposed by Google, assuming a > start date of August 1, 2017. Only one RFP respondent initially proposed a > schedule targeting August 8, 2017 (assuming a start date of June 12, 2017). > We did not deem this proposal to be credible, however, based on the lack of > specificity around our RFP evaluation criteria, as compared to all other RFP > responses which provided detailed responses to all aspects of the RFP, and we > have received no subsequent information from this bidder to increase our > confidence. You note that this assumes a start date of June 12. A later email from Rick Andrews says "Our proposed dates assume we are able to finalize negotiation of contracts with the selected Managed CA partner(s), [...] by no later than July 31, 2017." Presumably the June 12 date is long gone. However if one assumes the delta of 57 days from start to delivery stands, this would put delivery at September 26, 2017. This is two months sooner than the December 1 date. This seems like a pretty big difference. Given you are asking to delay the timeline based on other RFP respondents being unable to hit earlier dates, it seems prudent to ask whether the you attempted to investigate the proposal from the bidder who proposed August 8. Given that one of the requirements stated by Google is that the SubCA operator had to have roots that have been in the Google trust store for several years, it seems unusual that any eligible respondent would not be "credible" out of the gate. Did you ask them to provide more information and details to help determine if it was a "credible" offer? > 2) We are using several selection criteria for evaluating RFP responses, > including the depth of plan to address key technical integration and > operational requirements, the timeframe to execute, the ability to handle the > scope, volume, language, and customer support requirements both for ongoing > issuance and for one-time replacement of certificates issued prior to June 1, > 2016, compliance program and posture, and the ability to meet uptime, > interface performance, and other SLAs. Certain RFP respondents have > distinguished themselves based on the quality and depth of their integration > planning assumptions, requirements and activities, which have directly > influenced the dates we have proposed for the SubCA proposal. > > 3) The RFP was first released on May 26, 2017. The first round of bidder > responses was first received on June 12, 2017. In the https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ message, it was implied that Symantec was aware of the SubCA plan and dates since at least May 12. Given the plan to sign an agreement by July 31, the August 8 date seems rather impossible. Did Symantec push back on the August 8 date at that point? In the original email that started this subthread, you said, "Some of the prospective Managed CAs have proposed supporting only a portion of our volume (some by customer segment, others by geographic focus), so we are also evaluating options that involve working with multiple Managed CAs." Have you considered a staggered date system for different classes of certificates. For example, I would assume that certificates that don't contain subject identity information would have less work for migration integration than EV certificates. Given that it is common practice to have a different SubCA for different certificates types, could you hit an earlier date for non-EV certificates and then later have the EV SubCA ready? Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
