Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Rick Andrews via dev-security-policy 
On Friday, July 21, 2017 at 12:39:54 PM UTC-7, Peter Bowen wrote:
> 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
> 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.

Please see our response to Alex Gaynor.
 
> 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?

There is a difference between a prospective SubCA being capable of performing 
the activities of a Managed CA under the SubCA proposal and having a realistic 
plan to do so. We concluded the RFP response from the sole respondent who 
proposed a 2-month timeline was not credible because it failed to meet a 
minimum bar of providing us with sufficient information to evaluate the 
bidder’s ability to satisfy RFP requirements or meaningfully compare / contrast 
the bidder’s response with all other RFP respondents.  There were other 
attributes relating to this bidder’s proposal beyond its lack of content in 
addressing RFP evaluation criteria that reinforced our conclusion that the bid 
was not credible.

> > 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?

Yes, Symantec pushed back on the August 8 date in its earliest discussions with 
both Google and Mozilla after the SubCA proposal was made. We pushed back on 
the dates again publicly on June 1st.  We have now done the work of executing a 
robust RFP process that included multiple parties and involved multiple working 
sessions to arrive at dates that are both aggressive and achievable for the 
size and scale of our CA operations. 

> 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

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Rick Andrews via dev-security-policy 
On Friday, July 21, 2017 at 12:07:02 PM UTC-7, Alex Gaynor wrote:
> On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin 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.*
> >
> >
> Hi Steve,
> 
> Given that this represents nearly a 4 month difference in timelines, can
> you give us any more insight here as why you see such a large delta?
> 
> Alex

We have evaluated the rigor of the proposals with regard to integration between 
Symantec and the Managed CA(s) for all certificate lifecycle functions for 
retail, partner, and Enterprise RA models, supporting enrollment, all methods 
of domain verification, organization and extended validation vetting, 
re-authentication, replacement, renewal, cancelation, modification, revocation, 
CAA checking, CT logging, and CRL and OCSP response provisioning; the models 
for cross-team engagement and release planning; identification of any gaps and 
the plans to address; and the plans for end-to-end testing. The most aggressive 
of the RFP responses was the sole outlier in terms of timing (2 months to 
implementation) and offered the least amount of information in response to the 
RFP. There were other attributes relating to this bidder’s proposal beyond its 
lack of content in addressing RFP evaluation criteria that reinforced our 
conclusion that the bid was not realistic.  The difference between the most 
aggressive timing proposal when compared with the other RFP respondent plans 
was only about two months. All other RFP responses independently offered 
project plan timelines that spanned approximately 4-6 months. Symantec’s 
internal planning concluded that a 4 month timeline was aggressive but 
achievable.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Peter Bowen via dev-security-policy 
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
 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

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-21 Thread Alex Gaynor via dev-security-policy 
On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin 
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.*
>
>
Hi Steve,

Given that this represents nearly a 4 month difference in timelines, can
you give us any more insight here as why you see such a large delta?

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy 
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.

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.

4)  It is our longstanding policy not to comment on rumors or market 
speculation.





From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Wednesday, July 19, 2017 10:25 AM
To: Steve Medin <steve_me...@symantec.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal



Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   
(https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal).
   In this mail you wrote that "Last month, we released a Request for Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI). Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy 
We believe our proposed dates reflect an aggressive but achievable period of 
time to implement the SubCA proposal and allow impacted organizations the time 
needed to replace, test and operationalize replacement certificates in their 
infrastructure to mitigate interoperability and compatibility risk associated 
with this premature replacement of certificates, which is consistent with the 
intent of the SubCA proposal. Our proposed dates are informed by the RFP 
responses and follow-up discussions we have had with our prospective Managed CA 
partners.





From: Eric Mill [mailto:e...@konklone.com]
Sent: Wednesday, July 19, 2017 3:43 PM
To: Steve Medin <steve_me...@symantec.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal







On Wed, Jul 19, 2017 at 11:31 AM, Steve Medin via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   > -Original Message-
   > From: dev-security-policy 
[mailto:dev-security-policy-<mailto:dev-security-policy->
   > 
bounces+steve_medin=symantec@lists.mozilla.org<mailto:symantec@lists.mozilla.org>]
 On Behalf Of
   > Jakob Bohm via dev-security-policy
   > Sent: Tuesday, July 18, 2017 4:39 PM
   > To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
   > Subject: Re: [EXT] Symantec Update on SubCA Proposal
   >
   >
   > Just for clarity:
   >
   > (Note: Using ISO date format instead of ambiguous local date format)
   >
   > How many Symantec certs issued prior to 2015-06-01 expire after 2018-
   > 06-01, and how does that mesh with the alternative date proposed
   > below:
   >
   > On 18/07/2017 21:37, Steve Medin wrote:
   > > Correction: Summary item #3 should read:
   > >
   > > 3. May 1, 2018
   > > a. Single date of distrust of certificates issued prior to 6/1/2016.
   > (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
   > from January 18, 2018 for certificates issued prior to 6/1/2016).
   > >

   Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
2018-06-01. This is in addition to almost 200,000 certificates that would also 
need to be replaced under the current SubCA proposal assuming a May 1, 2018 
distrust date. We believe that nine months (from August 1, 2017 to May 1, 2018) 
is aggressive but achievable for this transition — a period minimally necessary 
to allow for site operators to plan and execute an orderly transition and to 
reduce the potential risk of widespread ecosystem disruption. Nevertheless, we 
urge the community to consider moving the proposed May 1, 2018 distrust date 
out even further to February 1, 2019 in order to minimize the risk of end user 
disruption by ensuring that website operators have a reasonable timeframe to 
plan and deploy replacement certificates.



   That's pretty close to saying that nothing should happen, since almost all 
the certificates will have expired by then. That certainly is the least 
disruptive, but it seems contrary to the intent of the proposal.



   -- Eric



   ___
   dev-security-policy mailing list
   
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
   https://lists.mozilla.org/listinfo/dev-security-policy







   --

   
konklone.com<https://clicktime.symantec.com/a/1/AAH-mYCdy7I540ZoJM0XkW-CDP-fn5bw0sk2P0x4Bvw=?d=U4j3hHTn-UxZ1ZOfHXB7r1lDEq3pYTpkBXJxYkQlk96LvJvpQVJPahGolj9IF9urhtYGsaK_9Mffi6158JvklYeFSEsWRIpnJD82JAbPyGBp6h78ufI4ZGIR8UZNoRVvgyVmB_Lq39lujhD-qOpO1y9E3I2BCtUkhiN98DyEsGpFxqp2JqPiLWxpjzBUBE3IqSdY8Pq0ezPKtY4XG0-7KydvGYIUGOlZJnVxW6_xEJseIlanIDcdA28GGtACgaVDc2QZBHhwpJ8TUK0GgpMW2fu3QdoLf2Fq_yOaeJe1F4AMkzBFTjbk9GF9TNfXVA4dVafUoWb5IFaE6uOy6B6cXKXbZIgX-Ya4lJ0dZ2ZjCSdJSLW2NfhVWxc-FScig3WKjyr-PsV_0lY0ODqzD8M1fhjT-XPzPQ%3D%3D=https%3A%2F%2Fkonklone.com>
 | @konklone<https://twitter.com/konklone>

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy 
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> David E. Ross via dev-security-policy
> Sent: Wednesday, July 19, 2017 12:48 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>
> On 7/19/2017 8:31 AM, Steve Medin wrote:
> >> -Original Message-
> >> From: dev-security-policy [mailto:dev-security-policy-
> >> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> >> Jakob Bohm via dev-security-policy
> >> Sent: Tuesday, July 18, 2017 4:39 PM
> >> To: mozilla-dev-security-pol...@lists.mozilla.org
> >> Subject: Re: [EXT] Symantec Update on SubCA Proposal
> >>
> >>
> >> Just for clarity:
> >>
> >> (Note: Using ISO date format instead of ambiguous local date format)
> >>
> >> How many Symantec certs issued prior to 2015-06-01 expire after
> 2018-
> >> 06-01, and how does that mesh with the alternative date proposed
> >> below:
> >>
> >> On 18/07/2017 21:37, Steve Medin wrote:
> >>> Correction: Summary item #3 should read:
> >>>
> >>> 3. May 1, 2018
> >>> a. Single date of distrust of certificates issued prior to 6/1/2016.
> >> (changed from August 31,2017 for certificates issued prior to
> >> 6/1/2015 and from January 18, 2018 for certificates issued prior to
> 6/1/2016).
> >>>
> >
> > Over 34,000 certificates were issued prior to 2015-06-01 and expire after
> 2018-06-01. This is in addition to almost 200,000 certificates that would
> also need to be replaced under the current SubCA proposal assuming a May
> 1, 2018 distrust date. We believe that nine months (from August 1, 2017 to
> May 1, 2018) is aggressive but achievable for this transition - a period
> minimally necessary to allow for site operators to plan and execute an
> orderly transition and to reduce the potential risk of widespread ecosystem
> disruption. Nevertheless, we urge the community to consider moving the
> proposed May 1, 2018 distrust date out even further to February 1, 2019
> in order to minimize the risk of end user disruption by ensuring that website
> operators have a reasonable timeframe to plan and deploy replacement
> certificates.
> >
>
> It appears that Symantec wants to delay distrusting certificates until all
> existing subscriber certificates reach their inherent expiration dates.
>

Our proposed distrust date (May 1, 2018) is based on an aggressive but 
achievable period of time to allow impacted organizations the time needed to 
replace, test and operationalize replacement certificates in their 
infrastructure.  More than 234,000 certificates are required to be replaced 
before their expiration dates assuming a distrust date of May 1, 2018. In fact, 
we urge the community to consider moving this distrust date out even further to 
February 1, 2019 in order to minimize the risk of end user disruption by 
ensuring that website operators have a reasonable timeframe to plan and deploy 
replacement certificates. This recommendation is echoed by our prospective 
Managed CA partners.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-20 Thread Steve Medin via dev-security-policy 
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Jakob Bohm via dev-security-policy
> Sent: Wednesday, July 19, 2017 12:22 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
> 
> On 19/07/2017 17:31, Steve Medin wrote:
> >> -Original Message-
> >> From: dev-security-policy [mailto:dev-security-policy-
> >> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> >> Jakob Bohm via dev-security-policy
> >> Sent: Tuesday, July 18, 2017 4:39 PM
> >> To: mozilla-dev-security-pol...@lists.mozilla.org
> >> Subject: Re: [EXT] Symantec Update on SubCA Proposal
> >>
> >>
> >> Just for clarity:
> >>
> >> (Note: Using ISO date format instead of ambiguous local date format)
> >>
> >> How many Symantec certs issued prior to 2015-06-01 expire after
> 2018-
> >> 06-01, and how does that mesh with the alternative date proposed
> >> below:
> >>
> >> On 18/07/2017 21:37, Steve Medin wrote:
> >>> Correction: Summary item #3 should read:
> >>>
> >>> 3. May 1, 2018
> >>>  a. Single date of distrust of certificates issued prior to 6/1/2016.
> >> (changed from August 31,2017 for certificates issued prior to
> >> 6/1/2015 and from January 18, 2018 for certificates issued prior to
> 6/1/2016).
> >>>
> >
> > Over 34,000 certificates were issued prior to 2015-06-01 and expire after
> 2018-06-01. This is in addition to almost 200,000 certificates that would
> also need to be replaced under the current SubCA proposal assuming a May
> 1, 2018 distrust date. We believe that nine months (from August 1, 2017 to
> May 1, 2018) is aggressive but achievable for this transition — a period
> minimally necessary to allow for site operators to plan and execute an
> orderly transition and to reduce the potential risk of widespread ecosystem
> disruption. Nevertheless, we urge the community to consider moving the
> proposed May 1, 2018 distrust date out even further to February 1, 2019
> in order to minimize the risk of end user disruption by ensuring that website
> operators have a reasonable timeframe to plan and deploy replacement
> certificates.
> >
> 
> So when and why did Symantec issue 34,000 WebPKI certificates valid
> longer than 3 years, that would expire after 2018-06-01 ?
> 
> Are these certificates issued before 2015-04-01 with validity periods longer
> than 39 months?
> 
> Are they certificates issued under "special circumstances" ?
> 
> Are they certificates with validity periods between 36 and 39 months?
> 
> 

The vast majority of these certificates were issued prior to April 1, 2015 and 
were subject to the 60 month rule that was in effect at the time of issuance. 
This population also includes several thousand that are for <39 month validity.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Eric Mill via dev-security-policy 
On Wed, Jul 19, 2017 at 11:31 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Jakob Bohm via dev-security-policy
> > Sent: Tuesday, July 18, 2017 4:39 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: [EXT] Symantec Update on SubCA Proposal
> >
> >
> > Just for clarity:
> >
> > (Note: Using ISO date format instead of ambiguous local date format)
> >
> > How many Symantec certs issued prior to 2015-06-01 expire after 2018-
> > 06-01, and how does that mesh with the alternative date proposed
> > below:
> >
> > On 18/07/2017 21:37, Steve Medin wrote:
> > > Correction: Summary item #3 should read:
> > >
> > > 3. May 1, 2018
> > > a. Single date of distrust of certificates issued prior to
> 6/1/2016.
> > (changed from August 31,2017 for certificates issued prior to 6/1/2015
> and
> > from January 18, 2018 for certificates issued prior to 6/1/2016).
> > >
>
> Over 34,000 certificates were issued prior to 2015-06-01 and expire after
> 2018-06-01. This is in addition to almost 200,000 certificates that would
> also need to be replaced under the current SubCA proposal assuming a May 1,
> 2018 distrust date. We believe that nine months (from August 1, 2017 to May
> 1, 2018) is aggressive but achievable for this transition — a period
> minimally necessary to allow for site operators to plan and execute an
> orderly transition and to reduce the potential risk of widespread ecosystem
> disruption. Nevertheless, we urge the community to consider moving the
> proposed May 1, 2018 distrust date out even further to February 1, 2019 in
> order to minimize the risk of end user disruption by ensuring that website
> operators have a reasonable timeframe to plan and deploy replacement
> certificates.
>

That's pretty close to saying that nothing should happen, since almost all
the certificates will have expired by then. That certainly is the least
disruptive, but it seems contrary to the intent of the proposal.

-- Eric


> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread David E. Ross via dev-security-policy 
On 7/19/2017 8:31 AM, Steve Medin wrote:
>> -Original Message-
>> From: dev-security-policy [mailto:dev-security-policy-
>> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
>> Jakob Bohm via dev-security-policy
>> Sent: Tuesday, July 18, 2017 4:39 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>>
>>
>> Just for clarity:
>>
>> (Note: Using ISO date format instead of ambiguous local date format)
>>
>> How many Symantec certs issued prior to 2015-06-01 expire after 2018-
>> 06-01, and how does that mesh with the alternative date proposed
>> below:
>>
>> On 18/07/2017 21:37, Steve Medin wrote:
>>> Correction: Summary item #3 should read:
>>>
>>> 3. May 1, 2018
>>> a. Single date of distrust of certificates issued prior to 6/1/2016.
>> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
>> from January 18, 2018 for certificates issued prior to 6/1/2016).
>>>
> 
> Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
> 2018-06-01. This is in addition to almost 200,000 certificates that would 
> also need to be replaced under the current SubCA proposal assuming a May 1, 
> 2018 distrust date. We believe that nine months (from August 1, 2017 to May 
> 1, 2018) is aggressive but achievable for this transition — a period 
> minimally necessary to allow for site operators to plan and execute an 
> orderly transition and to reduce the potential risk of widespread ecosystem 
> disruption. Nevertheless, we urge the community to consider moving the 
> proposed May 1, 2018 distrust date out even further to February 1, 2019 in 
> order to minimize the risk of end user disruption by ensuring that website 
> operators have a reasonable timeframe to plan and deploy replacement 
> certificates.
> 

It appears that Symantec wants to delay distrusting certificates until
all existing subscriber certificates reach their inherent expiration
dates.

-- 
David Ross

<http://www.rossde.com/>
President Trump now denies there are any tapes that
recorded his conversations with ex-FBI Director Comey.
Between when Trump hinted there might be such tapes
and his denial, there was sufficient time to destroy
any tapes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Jakob Bohm via dev-security-policy 

On 19/07/2017 17:31, Steve Medin wrote:

-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
Jakob Bohm via dev-security-policy
Sent: Tuesday, July 18, 2017 4:39 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal


Just for clarity:

(Note: Using ISO date format instead of ambiguous local date format)

How many Symantec certs issued prior to 2015-06-01 expire after 2018-
06-01, and how does that mesh with the alternative date proposed
below:

On 18/07/2017 21:37, Steve Medin wrote:

Correction: Summary item #3 should read:

3. May 1, 2018
 a. Single date of distrust of certificates issued prior to 6/1/2016.

(changed from August 31,2017 for certificates issued prior to 6/1/2015 and
from January 18, 2018 for certificates issued prior to 6/1/2016).




Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
2018-06-01. This is in addition to almost 200,000 certificates that would also 
need to be replaced under the current SubCA proposal assuming a May 1, 2018 
distrust date. We believe that nine months (from August 1, 2017 to May 1, 2018) 
is aggressive but achievable for this transition — a period minimally necessary 
to allow for site operators to plan and execute an orderly transition and to 
reduce the potential risk of widespread ecosystem disruption. Nevertheless, we 
urge the community to consider moving the proposed May 1, 2018 distrust date 
out even further to February 1, 2019 in order to minimize the risk of end user 
disruption by ensuring that website operators have a reasonable timeframe to 
plan and deploy replacement certificates.



So when and why did Symantec issue 34,000 WebPKI certificates valid
longer than 3 years, that would expire after 2018-06-01 ?

Are these certificates issued before 2015-04-01 with validity periods
longer than 39 months?

Are they certificates issued under "special circumstances" ?

Are they certificates with validity periods between 36 and 39 months?




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

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Steve Medin via dev-security-policy 
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Jakob Bohm via dev-security-policy
> Sent: Tuesday, July 18, 2017 4:39 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>
>
> Just for clarity:
>
> (Note: Using ISO date format instead of ambiguous local date format)
>
> How many Symantec certs issued prior to 2015-06-01 expire after 2018-
> 06-01, and how does that mesh with the alternative date proposed
> below:
>
> On 18/07/2017 21:37, Steve Medin wrote:
> > Correction: Summary item #3 should read:
> >
> > 3. May 1, 2018
> > a. Single date of distrust of certificates issued prior to 6/1/2016.
> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
> from January 18, 2018 for certificates issued prior to 6/1/2016).
> >

Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
2018-06-01. This is in addition to almost 200,000 certificates that would also 
need to be replaced under the current SubCA proposal assuming a May 1, 2018 
distrust date. We believe that nine months (from August 1, 2017 to May 1, 2018) 
is aggressive but achievable for this transition — a period minimally necessary 
to allow for site operators to plan and execute an orderly transition and to 
reduce the potential risk of widespread ecosystem disruption. Nevertheless, we 
urge the community to consider moving the proposed May 1, 2018 distrust date 
out even further to February 1, 2019 in order to minimize the risk of end user 
disruption by ensuring that website operators have a reasonable timeframe to 
plan and deploy replacement certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Alex Gaynor via dev-security-policy 
Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the
Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   (
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
).
   In this mail you wrote that "Last month, we released a Request for
Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI).
Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex

On Tue, Jul 18, 2017 at 3:37 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Correction: Summary item #3 should read:
>
> 3. May 1, 2018
>a. Single date of distrust of certificates issued prior to 6/1/2016.
> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
> from January 18, 2018 for certificates issued prior to 6/1/2016).
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Steve Medin via dev-security-policy
> > Sent: Tuesday, July 18, 2017 2:23 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec Update on SubCA Proposal
> >
> > *Progress Update on SubCA RFP, Partner Selection, and Execution*
> >
> >
> >
> > Since June 1, Symantec has worked in earnest to operationalize the SubCA
> > proposal outlined by Google and Mozilla and discussed in community
> > forums.  The core of this proposal is to transfer the authentication and
> > issuance of certificates to a set of new SubCAs that are operated by
> > "Managed CAs", with the eventual end state being a move from the existing
> > Symantec PKI to a modernized platform. We are providing this update to
> > share our initial findings of our efforts to implement the SubCA
> proposal,
> > and as previously posted, propose aggressive but achievable dates for
> > certain aspects of the SubCA proposal.
> >
> >
> >
> > Last month, we released a Request for Proposal (RFP) that covered all
> > aspects of the SubCA proposal, including key management, technical
> > integration, staffing, training, compliance, support, and the end-to-end
> > coordination of operations. This RFP was sent to the CAs that we felt
> best
> > met the browser requirements and had the potential to successfully
> fulfill
> > the scope and volume of our CA authentication and issuance activities.
> >
> >
> >
> > After receiving RFP responses, we met with the prospective Managed CAs
> > to discuss and refine their proposed approach, clarify intent and answer
> > questions impacting their proposals, which addressed their approach to
> > and schedule for integration, staffing, compliance, support, and other
> > operational aspects.  Over the last two weeks, we have continued to
> receive
> > detailed responses from RFP respondents and hold meetings with the
> > prospective Managed CAs to review their proposals in order to select the
> > final Managed CA partner(s) that will be able to best execute on the plan
> > proposed by Google and Mozilla. We appreciate the CAs who have replied
> > and recognize that drafting the proposals required a tremendous amount
> > of time and effort as part of this accelerated process.
> >
> >
> >
> > We continue to work through implementation details with our prospective
> > Managed CA partners, to understand the depth of analysis that has gone
> > into their development schedules and staffing plans, and to assess the
> > feasibility of those plans.  We expect to complete the selection process
> > within the next 2 weeks. After selecting the final Managed CA
> partner(s), we
> > will work aggressively towards the execution of an agreement and
> > integration plan.
> >
> >
> >
> > As we finalize the selection process, our development team is actively
> > working towards the transition.  Currently, we are shifting from design
> to
> > implementation of a common set of APIs across platforms to simplify the
> > integration with one or more Managed CAs.
> >
> >
> >
> > Based on the RFP responses, internal planning, and discussions with RFP
> > respondents to date, we are still concerned with the implementation
> > timing. Based on both our own internal scoping and the RFP responses, we
> > see a practical, aggressive transition being achievable between early-
> > December and late-February, depending on the specific Managed CA(s)

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-18 Thread Jakob Bohm via dev-security-policy 


Just for clarity:

(Note: Using ISO date format instead of ambiguous local date format)

How many Symantec certs issued prior to 2015-06-01 expire after
2018-06-01, and how does that mesh with the alternative date proposed
below:

On 18/07/2017 21:37, Steve Medin wrote:

Correction: Summary item #3 should read:

3. May 1, 2018
a. Single date of distrust of certificates issued prior to 6/1/2016. 
(changed from August 31,2017 for certificates issued prior to 6/1/2015 and from 
January 18, 2018 for certificates issued prior to 6/1/2016).


-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
Steve Medin via dev-security-policy
Sent: Tuesday, July 18, 2017 2:23 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: [EXT] Symantec Update on SubCA Proposal

*Progress Update on SubCA RFP, Partner Selection, and Execution*



Since June 1, Symantec has worked in earnest to operationalize the SubCA
proposal outlined by Google and Mozilla and discussed in community
forums.  The core of this proposal is to transfer the authentication and
issuance of certificates to a set of new SubCAs that are operated by
"Managed CAs", with the eventual end state being a move from the existing
Symantec PKI to a modernized platform. We are providing this update to
share our initial findings of our efforts to implement the SubCA proposal,
and as previously posted, propose aggressive but achievable dates for
certain aspects of the SubCA proposal.



Last month, we released a Request for Proposal (RFP) that covered all
aspects of the SubCA proposal, including key management, technical
integration, staffing, training, compliance, support, and the end-to-end
coordination of operations. This RFP was sent to the CAs that we felt best
met the browser requirements and had the potential to successfully fulfill
the scope and volume of our CA authentication and issuance activities.



After receiving RFP responses, we met with the prospective Managed CAs
to discuss and refine their proposed approach, clarify intent and answer
questions impacting their proposals, which addressed their approach to
and schedule for integration, staffing, compliance, support, and other
operational aspects.  Over the last two weeks, we have continued to receive
detailed responses from RFP respondents and hold meetings with the
prospective Managed CAs to review their proposals in order to select the
final Managed CA partner(s) that will be able to best execute on the plan
proposed by Google and Mozilla. We appreciate the CAs who have replied
and recognize that drafting the proposals required a tremendous amount
of time and effort as part of this accelerated process.



We continue to work through implementation details with our prospective
Managed CA partners, to understand the depth of analysis that has gone
into their development schedules and staffing plans, and to assess the
feasibility of those plans.  We expect to complete the selection process
within the next 2 weeks. After selecting the final Managed CA partner(s), we
will work aggressively towards the execution of an agreement and
integration plan.



As we finalize the selection process, our development team is actively
working towards the transition.  Currently, we are shifting from design to
implementation of a common set of APIs across platforms to simplify the
integration with one or more Managed CAs.



Based on the RFP responses, internal planning, and discussions with RFP
respondents to date, we are still concerned with the implementation
timing. Based on both our own internal scoping and the RFP responses, we
see a practical, aggressive transition being achievable between early-
December and late-February, depending on the specific Managed CA(s) and
the unknowns that come with an effort of this magnitude.  This timeframe
is based on the Managed CAs' RFP responses regarding how long it will take
to integrate our existing customer portals (front-ends) with the Managed
CA validation and issuance systems. The transition timeline also
incorporates the effort required for the Managed CAs to build out support
for scalable domain validation (both automated and manual), CAA record
checking, CT logging, and certificate management functions.  The primary
factors we heard from potential Managed CA partners are the need to scale
their operations to the certificate volumes currently sup  ported by
Symantec, the need for integration, and the time required to prepare and
process key ceremonies on both ends.  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.



*Timing Proposal Based on Key Activities*



Based on the key activities and customer dependencies associated with the
transition (additional details provided at the end of this

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-18 Thread Steve Medin via dev-security-policy 
Correction: Summary item #3 should read:

3. May 1, 2018
   a. Single date of distrust of certificates issued prior to 6/1/2016. 
(changed from August 31,2017 for certificates issued prior to 6/1/2015 and from 
January 18, 2018 for certificates issued prior to 6/1/2016).

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Steve Medin via dev-security-policy
> Sent: Tuesday, July 18, 2017 2:23 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec Update on SubCA Proposal
>
> *Progress Update on SubCA RFP, Partner Selection, and Execution*
>
>
>
> Since June 1, Symantec has worked in earnest to operationalize the SubCA
> proposal outlined by Google and Mozilla and discussed in community
> forums.  The core of this proposal is to transfer the authentication and
> issuance of certificates to a set of new SubCAs that are operated by
> "Managed CAs", with the eventual end state being a move from the existing
> Symantec PKI to a modernized platform. We are providing this update to
> share our initial findings of our efforts to implement the SubCA proposal,
> and as previously posted, propose aggressive but achievable dates for
> certain aspects of the SubCA proposal.
>
>
>
> Last month, we released a Request for Proposal (RFP) that covered all
> aspects of the SubCA proposal, including key management, technical
> integration, staffing, training, compliance, support, and the end-to-end
> coordination of operations. This RFP was sent to the CAs that we felt best
> met the browser requirements and had the potential to successfully fulfill
> the scope and volume of our CA authentication and issuance activities.
>
>
>
> After receiving RFP responses, we met with the prospective Managed CAs
> to discuss and refine their proposed approach, clarify intent and answer
> questions impacting their proposals, which addressed their approach to
> and schedule for integration, staffing, compliance, support, and other
> operational aspects.  Over the last two weeks, we have continued to receive
> detailed responses from RFP respondents and hold meetings with the
> prospective Managed CAs to review their proposals in order to select the
> final Managed CA partner(s) that will be able to best execute on the plan
> proposed by Google and Mozilla. We appreciate the CAs who have replied
> and recognize that drafting the proposals required a tremendous amount
> of time and effort as part of this accelerated process.
>
>
>
> We continue to work through implementation details with our prospective
> Managed CA partners, to understand the depth of analysis that has gone
> into their development schedules and staffing plans, and to assess the
> feasibility of those plans.  We expect to complete the selection process
> within the next 2 weeks. After selecting the final Managed CA partner(s), we
> will work aggressively towards the execution of an agreement and
> integration plan.
>
>
>
> As we finalize the selection process, our development team is actively
> working towards the transition.  Currently, we are shifting from design to
> implementation of a common set of APIs across platforms to simplify the
> integration with one or more Managed CAs.
>
>
>
> Based on the RFP responses, internal planning, and discussions with RFP
> respondents to date, we are still concerned with the implementation
> timing. Based on both our own internal scoping and the RFP responses, we
> see a practical, aggressive transition being achievable between early-
> December and late-February, depending on the specific Managed CA(s) and
> the unknowns that come with an effort of this magnitude.  This timeframe
> is based on the Managed CAs' RFP responses regarding how long it will take
> to integrate our existing customer portals (front-ends) with the Managed
> CA validation and issuance systems. The transition timeline also
> incorporates the effort required for the Managed CAs to build out support
> for scalable domain validation (both automated and manual), CAA record
> checking, CT logging, and certificate management functions.  The primary
> factors we heard from potential Managed CA partners are the need to scale
> their operations to the certificate volumes currently sup  ported by
> Symantec, the need for integration, and the time required to prepare and
> process key ceremonies on both ends.  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.
>
>
>
> *Timing Proposal Based on Key Activities*
>
>
>
> Based on the key activities and customer dependencies associated with the
> transition (additional details provided at the end of this post), we believe
> that the following adjustments to the current SubCA proposal timelines are
> appropriate and